From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Marcel Holtmann To: Satyam Sharma In-Reply-To: References: <462D1B09.9050005@goop.org> Date: Wed, 16 May 2007 13:45:04 +0200 Message-Id: <1179315904.10069.67.camel@violet> Mime-Version: 1.0 Cc: Jeremy Fitzhardinge , netdev@vger.kernel.org, Greg KH , Linux Kernel Mailing List , Jiri Kosina , Cedric Le Goater , bluez-devel@lists.sourceforge.net, maxk@qualcomm.com Subject: Re: [Bluez-devel] 2.6.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523 Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net Hi Satayam, > > > (later) > > > I Googled a bit to see if this problem was faced elsewhere in the kernel > > > too. Saw the following commit by Ingo Molnar > > > (9883a13c72dbf8c518814b6091019643cdb34429): > > > - lock_sock(sock->sk); > > > + local_bh_disable(); > > > + bh_lock_sock_nested(sock->sk); > > > rc = selinux_netlbl_socket_setsid(sock, sksec->sid); > > > - release_sock(sock->sk); > > > + bh_unlock_sock(sock->sk); > > > + local_bh_enable(); > > > Is it _really_ *this* simple? > > [...] > > actually this *seems* to be proper solution also for our case, thanks for > > pointing this out. I will think about it once again, do some more tests > > with this locking scheme, and will let you know. > > Yes, I can almost confirm that this (open-coding of spin_lock_bh, > effectively) is the proper solution (Rusty's unreliable guide to > kernel-locking needs to be next to every developer's keyboard :-) > I also came across this idiom in other places in the networking code > so it seems to be pretty much the standard way. I wish I owned > bluetooth hardware, could've tested this for you myself. does this mean we should revert previous changes to the locking or only apply this on top of it? Regards Marcel ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760601AbXEPLqV (ORCPT ); Wed, 16 May 2007 07:46:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757079AbXEPLqL (ORCPT ); Wed, 16 May 2007 07:46:11 -0400 Received: from coyote.holtmann.net ([217.160.111.169]:53153 "EHLO mail.holtmann.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756321AbXEPLqK (ORCPT ); Wed, 16 May 2007 07:46:10 -0400 Subject: Re: 2.6.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523 From: Marcel Holtmann To: Satyam Sharma Cc: Jiri Kosina , Greg KH , Jeremy Fitzhardinge , maxk@qualcomm.com, bluez-devel@lists.sourceforge.net, Cedric Le Goater , Linux Kernel Mailing List , netdev@vger.kernel.org In-Reply-To: References: <462D1B09.9050005@goop.org> Content-Type: text/plain Date: Wed, 16 May 2007 13:45:04 +0200 Message-Id: <1179315904.10069.67.camel@violet> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Satayam, > > > (later) > > > I Googled a bit to see if this problem was faced elsewhere in the kernel > > > too. Saw the following commit by Ingo Molnar > > > (9883a13c72dbf8c518814b6091019643cdb34429): > > > - lock_sock(sock->sk); > > > + local_bh_disable(); > > > + bh_lock_sock_nested(sock->sk); > > > rc = selinux_netlbl_socket_setsid(sock, sksec->sid); > > > - release_sock(sock->sk); > > > + bh_unlock_sock(sock->sk); > > > + local_bh_enable(); > > > Is it _really_ *this* simple? > > [...] > > actually this *seems* to be proper solution also for our case, thanks for > > pointing this out. I will think about it once again, do some more tests > > with this locking scheme, and will let you know. > > Yes, I can almost confirm that this (open-coding of spin_lock_bh, > effectively) is the proper solution (Rusty's unreliable guide to > kernel-locking needs to be next to every developer's keyboard :-) > I also came across this idiom in other places in the networking code > so it seems to be pretty much the standard way. I wish I owned > bluetooth hardware, could've tested this for you myself. does this mean we should revert previous changes to the locking or only apply this on top of it? Regards Marcel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcel Holtmann Subject: Re: 2.6.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523 Date: Wed, 16 May 2007 13:45:04 +0200 Message-ID: <1179315904.10069.67.camel@violet> References: <462D1B09.9050005@goop.org> Reply-To: BlueZ development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , netdev@vger.kernel.org, Greg KH , Linux Kernel Mailing List , Jiri Kosina , Cedric Le Goater , bluez-devel@lists.sourceforge.net, maxk@qualcomm.com To: Satyam Sharma Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net List-Id: netdev.vger.kernel.org Hi Satayam, > > > (later) > > > I Googled a bit to see if this problem was faced elsewhere in the kernel > > > too. Saw the following commit by Ingo Molnar > > > (9883a13c72dbf8c518814b6091019643cdb34429): > > > - lock_sock(sock->sk); > > > + local_bh_disable(); > > > + bh_lock_sock_nested(sock->sk); > > > rc = selinux_netlbl_socket_setsid(sock, sksec->sid); > > > - release_sock(sock->sk); > > > + bh_unlock_sock(sock->sk); > > > + local_bh_enable(); > > > Is it _really_ *this* simple? > > [...] > > actually this *seems* to be proper solution also for our case, thanks for > > pointing this out. I will think about it once again, do some more tests > > with this locking scheme, and will let you know. > > Yes, I can almost confirm that this (open-coding of spin_lock_bh, > effectively) is the proper solution (Rusty's unreliable guide to > kernel-locking needs to be next to every developer's keyboard :-) > I also came across this idiom in other places in the networking code > so it seems to be pretty much the standard way. I wish I owned > bluetooth hardware, could've tested this for you myself. does this mean we should revert previous changes to the locking or only apply this on top of it? Regards Marcel ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/