From patchwork Wed Sep 10 06:49:38 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amos Kong X-Patchwork-Id: 4874711 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 77202C0338 for ; Wed, 10 Sep 2014 06:52:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7E372201BF for ; Wed, 10 Sep 2014 06:52:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 66129201BC for ; Wed, 10 Sep 2014 06:52:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751675AbaIJGwO (ORCPT ); Wed, 10 Sep 2014 02:52:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63708 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751659AbaIJGwM (ORCPT ); Wed, 10 Sep 2014 02:52:12 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8A6ngWN026890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 10 Sep 2014 02:49:43 -0400 Received: from localhost (vpn1-115-185.nay.redhat.com [10.66.115.185]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8A6ndO1011217; Wed, 10 Sep 2014 02:49:40 -0400 Date: Wed, 10 Sep 2014 14:49:38 +0800 From: Amos Kong To: Amit Shah Cc: virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, Rusty Russell , herbert@gondor.apana.org.au Subject: Re: RFC virtio-rng: fail to read sysfs of a busy device Message-ID: <20140910064938.GB30285@zen.redhat.com> References: <20140909151844.GA17178@zen.redhat.com> <20140909152307.GB17178@zen.redhat.com> <20140910055212.GB29832@grmbl.mre> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140910055212.GB29832@grmbl.mre> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Sep 10, 2014 at 11:22:12AM +0530, Amit Shah wrote: > On (Tue) 09 Sep 2014 [23:23:07], Amos Kong wrote: > > (Resend to fix the subject) > > > > Hi Amit, Rusty > > > > RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062 > > steps: > > - Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest > > - check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*' > > > > Result: cat process will get stuck, it will return if we kill dd process. > > How common is it going to be to have a long-running 'dd' process on > /dev/hwrng? Not a common usage, but we have this strict testing. > Also, with the new khwrng thread, reading from /dev/hwrng isn't > required -- just use /dev/random? Yes. > (This doesn't mean we shouldn't fix the issue here...) Completely agree :-) > > We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c, > > they are protected by rng_mutex. I try to workaround this issue by undelay(100) > > after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show() > > to get mutex. > > > > This patch also contains some cleanup, moving some code out of mutex > > protection. > > > > Do you have some suggestion? Thanks. > > > > > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > > index aa30a25..fa69020 100644 > > --- a/drivers/char/hw_random/core.c > > +++ b/drivers/char/hw_random/core.c > > @@ -194,6 +194,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > > } > > > > mutex_unlock(&rng_mutex); > > + udelay(100); > > We have a need_resched() right below. Why doesn't that work? need_resched() is giving chance for userspace to > > if (need_resched()) It never success in my debugging. If we remove this check and always call schedule_timeout_interruptible(1), problem also disappears. err = -ERESTARTSYS; > > schedule_timeout_interruptible(1); > > @@ -233,10 +234,10 @@ static ssize_t hwrng_attr_current_store(struct device *dev, > > int err; > > struct hwrng *rng; > The following hunk doesn't work: > > > + err = -ENODEV; > > err = mutex_lock_interruptible(&rng_mutex); > > err is being set to another value in the next line! > > > if (err) > > return -ERESTARTSYS; > > - err = -ENODEV; > > And all usage of err below now won't have -ENODEV but some other value. Oops! > > list_for_each_entry(rng, &rng_list, list) { > > if (strcmp(rng->name, buf) == 0) { > > if (rng == current_rng) { > > @@ -270,8 +271,8 @@ static ssize_t hwrng_attr_current_show(struct device *dev, > > return -ERESTARTSYS; > > if (current_rng) > > name = current_rng->name; > > - ret = snprintf(buf, PAGE_SIZE, "%s\n", name); > > mutex_unlock(&rng_mutex); > > + ret = snprintf(buf, PAGE_SIZE, "%s\n", name); > > This looks OK... > > > > > return ret; > > } > > @@ -284,19 +285,19 @@ static ssize_t hwrng_attr_available_show(struct device *dev, > > ssize_t ret = 0; > > struct hwrng *rng; > > > > + buf[0] = '\0'; > > err = mutex_lock_interruptible(&rng_mutex); > > if (err) > > return -ERESTARTSYS; > > > > - buf[0] = '\0'; > > list_for_each_entry(rng, &rng_list, list) { > > strncat(buf, rng->name, PAGE_SIZE - ret - 1); > > ret += strlen(rng->name); > > strncat(buf, " ", PAGE_SIZE - ret - 1); > > ret++; > > } > > + mutex_unlock(&rng_mutex); > > strncat(buf, "\n", PAGE_SIZE - ret - 1); > > ret++; > > - mutex_unlock(&rng_mutex); > > But this isn't resulting in savings; the majority of the time is being > spent in the for loop, and that writes to the buffer. Right > BTW I don't expect strcat'ing to the buf in each of these scenarios is > a long operation, so this reworking doesn't strike to me as something > we should pursue. > > Amit diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index aa30a25..263a370 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@ -195,8 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, mutex_unlock(&rng_mutex); - if (need_resched()) - schedule_timeout_interruptible(1); + schedule_timeout_interruptible(1); if (signal_pending(current)) {