From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 24 Jul 2002 09:03:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 24 Jul 2002 09:03:01 -0400 Received: from mons.uio.no ([129.240.130.14]:48060 "EHLO mons.uio.no") by vger.kernel.org with ESMTP id ; Wed, 24 Jul 2002 09:03:01 -0400 To: Linus Torvalds Cc: "David S. Miller" , trond.myklebust@fys.uio.no, Subject: Re: [PATCH] 2.5.27 fix potential spinlocking race. References: From: Trond Myklebust Date: 24 Jul 2002 15:05:59 +0200 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >>>>> " " == Linus Torvalds writes: > Trond noticed that kfree_skb() can be called from a _non_ bh > context, ie process context. So it needs to protect itself > against other bh's on this CPU (which it wouldn't need to do if > it was only called from a bh context). > So it's exactly your "better context" that is at stake here. Precisely. Not coming from a computer science background, the jargon sometimes gets the better of me ;-) I was playing around with ip_build_xmit_slow() looking at alternatives for fixing the MSG_DONTWAIT fragmentation bug mentioned on this list a couple of weeks ago, when I noticed that it can call kfree_skb() from a process context. This again means that write_space() can get called without being wrapped in a local_bh_disable()/local_bh_enable() - style protection against softirqs. Cheers, Trond