All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Max Vozeler <max@vozeler.com>
Cc: linux-kernel@vger.kernel.org,
	"Greg Kroah-Hartman" <gregkh@suse.de>,
	Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
Subject: Re: [PATCH 03/20] staging/usbip: convert to kthread
Date: Fri, 28 Jan 2011 19:48:36 +0100	[thread overview]
Message-ID: <201101281948.36678.arnd@arndb.de> (raw)
In-Reply-To: <4D4302AC.3050903@vozeler.com>

On Friday 28 January 2011 18:53:48 Max Vozeler wrote:
> Hi Arnd,
> 
> On 26.01.2011 00:17, Arnd Bergmann wrote:
> > usbip has its own infrastructure for managing kernel
> > threads, similar to kthread. By changing it to use
> > the standard functions, we can simplify the code
> > and get rid of one of the last BKL users at the
> > same time.
> > 
> > Compile-tested only, please verify.
> 
> I started reviewing and testing, but need to 
> postpone proper testing until mid next week. I did 
> notice a few problems (see below)

Ok, thanks for the review!

> > diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
> > index b186b5f..4ee70d4 100644
> > --- a/drivers/staging/usbip/stub_dev.c
> > +++ b/drivers/staging/usbip/stub_dev.c
> > @@ -18,6 +18,7 @@
> >   */
> >  
> >  #include <linux/slab.h>
> > +#include <linux/kthread.h>
> >  
> >  #include "usbip_common.h"
> >  #include "stub.h"
> > @@ -138,7 +139,8 @@ static ssize_t store_sockfd(struct device *dev, struct device_attribute *attr,
> >  
> >  		spin_unlock(&sdev->ud.lock);
> >  
> > -		usbip_start_threads(&sdev->ud);
> > +		wake_up_process(sdev->ud.tcp_rx);
> > +		wake_up_process(sdev->ud.tcp_tx);
> 
> The threads may have exited already if the
> device was in use then then shut down.
> 
> Can we create or kthread_run() the threads 
> here as I think happened before?

Certainly. I just tried to find the semantics that match the previous
behaviour the closest, but I could not find a reason why the threads
were started in a different place from where they get created.
 
> This is what I saw from a quick test:
> 
> [  405.674068] usbip 1-1:1.0: stub up
> [  405.674110] general protection fault: 0000 [#1] SMP 
> [  405.674876] last sysfs file: /sys/devices/pci0000:00/0000:00:01.2/usb1/1-1/1-1:1.0/usbip_sockfd
> [  405.676045] CPU 0 
> [  405.676045] Modules linked in: usbip(C) usbip_common_mod(C) snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 af_packet mperf microcode configfs fuse loop dm_mod snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer tpm_tis tpm snd soundcore tpm_bios rtc_cmos rtc_core i2c_piix4 i2c_core virtio_net snd_page_alloc pcspkr rtc_lib floppy virtio_balloon button uhci_hcd ehci_hcd usbcore ext3 mbcache jbd fan processor virtio_blk virtio_pci virtio_ring virtio ide_pci_generic piix ide_core ata_generic ata_piix libata scsi_mod thermal thermal_sys hwmon
> [  405.676045] 
> [  405.676045] Pid: 3360, comm: usbipd Tainted: G         C  2.6.38-rc2-0.5-default+ #1 /Bochs
> [  405.676045] RIP: 0010:[<ffffffff8104c41f>]  [<ffffffff8104c41f>] task_rq_lock+0x4f/0xb0

Right, that would fit the problem you described. It could also happen if
tcp_rx is NULL at this point.

> > -void stub_tx_loop(struct usbip_task *ut)
> > +int stub_tx_loop(void *data)
> >  {
> > -	struct usbip_device *ud = container_of(ut, struct usbip_device, tcp_tx);
> > +	struct usbip_device *ud = data;
> >  	struct stub_device *sdev = container_of(ud, struct stub_device, ud);
> >  
> > -	while (1) {
> > -		if (signal_pending(current)) {
> > -			usbip_dbg_stub_tx("signal catched\n");
> > -			break;
> > -		}
> > -
> > +	while (!kthread_should_stop()) {
> >  		if (usbip_event_happened(ud))
> >  			break;
> >  
> > @@ -371,4 +367,6 @@ void stub_tx_loop(struct usbip_task *ut)
> >  				(!list_empty(&sdev->priv_tx) ||
> >  				 !list_empty(&sdev->unlink_tx)));
> >  	}
> 
> I think this needs kthread_should_stop() as 
> condition for the wait_event_interruptible() or
> the thread may not actually stop.

Yes, good point. 

> --- a/drivers/staging/usbip/stub_tx.c
> +++ b/drivers/staging/usbip/stub_tx.c
> @@ -365,7 +365,8 @@ int stub_tx_loop(void *data)
>  
>                 wait_event_interruptible(sdev->tx_waitq,
>                                 (!list_empty(&sdev->priv_tx) ||
> -                                !list_empty(&sdev->unlink_tx)));
> +                                !list_empty(&sdev->unlink_tx)) ||
> +                               kthread_should_stop());
>         }
>  
>         return 0;

Looks good, same for the others you found.
 
> > diff --git a/drivers/staging/usbip/vhci_sysfs.c b/drivers/staging/usbip/vhci_sysfs.c
> > index f6e34e0..3f2459f 100644
> > --- a/drivers/staging/usbip/vhci_sysfs.c
> > +++ b/drivers/staging/usbip/vhci_sysfs.c
> > @@ -220,16 +220,13 @@ static ssize_t store_attach(struct device *dev, struct device_attribute *attr,
> >  	vdev->ud.tcp_socket = socket;
> >  	vdev->ud.status     = VDEV_ST_NOTASSIGNED;
> >  
> > +	wake_up_process(vdev->ud.tcp_rx);
> > +	wake_up_process(vdev->ud.tcp_tx);
> > +
> >  	spin_unlock(&vdev->ud.lock);
> >  	spin_unlock(&the_controller->lock);
> >  	/* end the lock */
> 
> Is it ok to call wake_up_process() while holding
> the spinlocks? (I don't know - just noticed the
> comment which used to be there)

I'm pretty sure you can call it almost everywhere, yes.

> > @@ -238,4 +234,6 @@ void vhci_tx_loop(struct usbip_task *ut)
> >  
> >  		usbip_dbg_vhci_tx("pending urbs ?, now wake up\n");
> >  	}
> > +
> > +	return 0;
> >  }
> 
> I need to leave now for the next couple of days,
> so this is a bit rushed.
> 
> I can take a closer look and do tests in different
> setups during the next week.

That would be great!

Thanks,

	Arnd

  reply	other threads:[~2011-01-28 18:48 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-25 22:17 [RFC 00/20] Proposal for remaining BKL users Arnd Bergmann
2011-01-25 22:17 ` Arnd Bergmann
2011-01-25 22:17 ` [PATCH 01/20] drm/i810: remove the BKL Arnd Bergmann
2011-01-25 22:17 ` [PATCH 02/20] drm: remove i830 driver Arnd Bergmann
2011-01-25 22:17 ` [PATCH 03/20] staging/usbip: convert to kthread Arnd Bergmann
2011-01-28 17:53   ` Max Vozeler
2011-01-28 18:48     ` Arnd Bergmann [this message]
2011-03-01 22:15     ` Arnd Bergmann
2011-01-25 22:17 ` [PATCH 04/20] staging/cx25721: serialize access to devlist Arnd Bergmann
2011-01-26 16:23   ` Palash Bandyopadhyay
2011-01-31 21:37   ` Greg KH
2011-01-25 22:17 ` [PATCH 05/20] staging/go7007: remove the BKL Arnd Bergmann
2011-01-25 22:17 ` [PATCH 06/20] staging: Remove autofs3 Arnd Bergmann
2011-01-26  7:41   ` H. Peter Anvin
2011-01-25 22:17 ` [PATCH 07/20] staging: remove smbfs Arnd Bergmann
2011-01-25 22:17 ` [PATCH 08/20] adfs: remove the big kernel lock Arnd Bergmann
2011-01-25 22:20   ` Russell King
2011-01-25 22:17 ` [PATCH 09/20] hpfs: rename big kernel lock to hpfs_lock Arnd Bergmann
2011-01-25 22:17 ` [PATCH 10/20] hpfs: replace BKL with a global mutex Arnd Bergmann
2011-01-26  0:15   ` Andi Kleen
2011-01-26  0:19   ` Andi Kleen
2011-01-26 12:48     ` [PATCH v2] hpfs: remove the BKL Arnd Bergmann
2011-01-26 12:50     ` [PATCH 10/20] hpfs: replace BKL with a global mutex Arnd Bergmann
2011-01-26 16:52       ` Andi Kleen
2011-01-27  5:01         ` Nick Piggin
2011-01-27 10:57           ` Miklos Szeredi
2011-01-25 22:17 ` [PATCH 11/20] hpfs: move to drivers/staging Arnd Bergmann
2011-02-07 16:17   ` Mikulas Patocka
2011-02-07 19:31     ` Arnd Bergmann
2011-01-25 22:17 ` [PATCH 12/20] x25: remove the BKL Arnd Bergmann
2011-01-27 10:07   ` Andrew Hendry
2011-01-27 12:17     ` Arnd Bergmann
2011-01-27 12:38       ` [PATCH v2] " Arnd Bergmann
2011-01-27 13:20         ` Eric Dumazet
2011-01-27 13:43           ` Arnd Bergmann
2011-01-25 22:17 ` [PATCH 13/20] appletalk: move to staging Arnd Bergmann
2011-01-25 22:17 ` [PATCH 14/20] staging/appletalk: remove the BKL Arnd Bergmann
2011-01-25 22:29   ` David Miller
2011-01-26 12:57     ` Arnd Bergmann
2011-01-25 22:17 ` [PATCH 15/20] ufs: " Arnd Bergmann
2011-01-26  2:30   ` Nick Bowler
2011-01-26 12:53     ` Arnd Bergmann
2011-01-27  5:47   ` Nick Piggin
2011-01-27 13:13     ` Arnd Bergmann
2011-01-25 22:17 ` [PATCH 16/20] ipx: " Arnd Bergmann
2011-01-25 22:17 ` [PATCH 17/20] tracing: don't trace " Arnd Bergmann
2011-01-25 22:28   ` Frederic Weisbecker
2011-01-25 22:17 ` [PATCH 18/20] rtmutex-tester: remove BKL tests Arnd Bergmann
2011-01-26 15:00   ` [tip:core/locking] rtmutex-tester: Remove " tip-bot for Arnd Bergmann
2011-02-22 20:57   ` [tip:irq/core] rtmutex: tester: " tip-bot for Arnd Bergmann
2011-01-25 22:17 ` [PATCH 19/20] drivers: remove extraneous includes of smp_lock.h Arnd Bergmann
2011-01-25 22:17 ` [PATCH 20/20] BKL: That's all, folks Arnd Bergmann
2011-01-26  6:19   ` Ingo Molnar
2011-01-26  8:47     ` Alan Cox
2011-01-26 11:01       ` Ingo Molnar
2011-01-26 11:22   ` Thomas Gleixner
2011-01-26  2:22 ` [RFC 00/20] Proposal for remaining BKL users Greg KH
2011-01-26  2:22   ` Greg KH
2011-01-26 11:31   ` Arnd Bergmann
2011-01-26 11:31     ` Arnd Bergmann
2011-01-26 11:58     ` Mauro Carvalho Chehab
2011-01-26 13:45       ` Arnd Bergmann
2011-01-26 13:45         ` Arnd Bergmann
2011-01-26 16:24         ` Palash Bandyopadhyay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201101281948.36678.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=gregkh@suse.de \
    --cc=hirofuchi@users.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max@vozeler.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.