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 \
    --subject='Re: [PATCH 03/20] staging/usbip: convert to kthread' \
    /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

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.