linux-kernel - Re: 2.6.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 13 May 2007 02:20:52 -0700
From:	Greg KH <gregkh@...e.de>
To:	Satyam Sharma <satyam.sharma@...il.com>
Cc:	Jiri Kosina <jikos@...os.cz>,
	Marcel Holtmann <marcel@...tmann.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>, maxk@...lcomm.com,
	bluez-devel@...ts.sourceforge.net,
	Cedric Le Goater <clg@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org
Subject: Re: 2.6.21-rc7: BUG: sleeping function called from invalid context
	at net/core/sock.c:1523

On Fri, May 11, 2007 at 06:59:31PM +0530, Satyam Sharma wrote:
>  [1] This is the first problem point. However, I didn't find any reason
>  why this particular driver's .disconnect() couldn't sleep. In fact, a
>  comment in include/linux/usb.h:811 says:
> 
>  "The probe() and disconnect() methods are called in a context where
>  they can sleep, but they should avoid abusing the privilege. Most
>  work to connect to a device should be done when the device is opened,
>  and undone at the last close. The disconnect code needs to address
>  concurrency issues with respect to open() and close() methods, as
>  well as forcing all pending I/O requests to complete (by unlinking
>  them as necessary, and blocking until the unlinks complete)."
> 
>  I'm assuming the comment is not obsolete, of course, but although the
>  first sentence says .disconnect() shouldn't abuse the privilege to
>  sleep, the last sentence makes it quite evident that we are _allowed_
>  to do so anyway, and that is how things are (with the hci_usb driver,
>  at least, I didn't check the .remove() or .disconnect() functions of other
>  USB drivers, however).

Yes, this is true, you are running in thread context for .disconnect of
usb drivers, so you can sleep if you need to, but you will block all
other device's disconnect and probe functions while you do.  So, it's
good to try to not abuse this if possible.

thanks,

greg k-h
-
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/