| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <201101281948.36678.arnd@arndb.de>
Date: Fri, 28 Jan 2011 19:48:36 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Max Vozeler <max@...eler.com>
Cc: linux-kernel@...r.kernel.org,
"Greg Kroah-Hartman" <gregkh@...e.de>,
Takahiro Hirofuchi <hirofuchi@...rs.sourceforge.net>
Subject: Re: [PATCH 03/20] staging/usbip: convert to kthread
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists