[PATCH] 2.5.27 fix potential spinlocking race.

[PATCH] 2.5.27 fix potential spinlocking race.

[Trond Myklebust]

In case of socket transmission errors etc. kfree_skb(), and hence
xprt_write_space() can potentially get called outside of a bh-safe
context.

Cheers,
  Trond

diff -u --recursive --new-file linux-2.5.27/net/sunrpc/xprt.c linux-2.5.27-fix_wspace/net/sunrpc/xprt.c
--- linux-2.5.27/net/sunrpc/xprt.c	Sat Jul 20 21:11:08 2002
+++ linux-2.5.27-fix_wspace/net/sunrpc/xprt.c	Tue Jul 23 22:20:48 2002
@@ -966,10 +966,10 @@
 		return;
 
 	if (!xprt_test_and_set_wspace(xprt)) {
-		spin_lock(&xprt->sock_lock);
+		spin_lock_bh(&xprt->sock_lock);
 		if (xprt->snd_task && xprt->snd_task->tk_rpcwait == &xprt->pending)
 			rpc_wake_up_task(xprt->snd_task);
-		spin_unlock(&xprt->sock_lock);
+		spin_unlock_bh(&xprt->sock_lock);
 	}
 
 	if (test_bit(SOCK_NOSPACE, &sock->flags)) {

Re: [PATCH] 2.5.27 fix potential spinlocking race.

[David S. Miller]

   In case of socket transmission errors etc. kfree_skb(), and hence
   xprt_write_space() can potentially get called outside of a bh-safe
   context.

kfree_skb must occur within a BH context or better context.

When HW interrupt handlers free packets they use kfree_skb_irq() which
schedules a software interrupt to really perform the kfree_skb work.

Therefore kfree_skb must always be invoked in BH or better context.

I think we need to reevaluate this situation before we apply this
patch :-)

Re: [PATCH] 2.5.27 fix potential spinlocking race.

[Linus Torvalds]

On Tue, 23 Jul 2002, David S. Miller wrote:
>
>    In case of socket transmission errors etc. kfree_skb(), and hence
>    xprt_write_space() can potentially get called outside of a bh-safe
>    context.
>
> kfree_skb must occur within a BH context or better context.

I think you're talking past each other.

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.

		Linus

Re: [PATCH] 2.5.27 fix potential spinlocking race.

[Trond Myklebust]

>>>>> " " == Linus Torvalds <torvalds@transmeta.com> 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