linux-kernel - Re: [PATCH] make hci_notifier a blocking notifier (was Re: 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]

Message-ID: <Pine.LNX.4.44L0.0705061801330.21407-100000@netrider.rowland.org>
Date:	Sun, 6 May 2007 18:06:39 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Satyam Sharma <satyam.sharma@...il.com>
cc:	Ray Lee <ray-lk@...rabbit.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@...e.cz>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Max Krasnyansky <maxk@...lcomm.com>, <marcel@...tmann.org>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [PATCH] make hci_notifier a blocking notifier (was Re: BUG:
 sleeping function called from invalid context at net/core/sock.c:1523)

On Sun, 6 May 2007, Satyam Sharma wrote:

> Anyway, the hci_notifier is called from the following six call sites:
> 
> hci_dev_open() and hci_dev_close() -> both called from
> hci_sock_ioctl() => both can sleep
> hci_register_dev() and hci_unregister_dev() => again both are capable
> of sleeping
> hci_suspend_dev() and hci_resume_dev() -> called from the .suspend()
> and .resume() of the hci_usb_driver, and again both of these can sleep
> 
> Is there any other reason why hci_notifier must be an atomic notifier?
> 
> (CC'ing Alan Stern just in case, apparently hci_notifier became atomic
> when notifier chains were classified into atomic / blocking)

I don't remember exactly why this particular choice was made.  Perhaps we 
found that the notifier callout routines didn't use any blocking 
primitives (we may have been mistaken about this -- there was a lot of 
code to check) and so therefore the choice didn't matter.  In that case we 
probably just decided to make it an atomic notifier to keep things simple.

As you found, changing it to a blocking notifier is very easy.  Provided 
all the callers are non-atomic it should work just fine.

Alan Stern

-
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/