Very Computer

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

                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)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

   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 :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

     > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/