Messages in this thread | | | Date | Sun, 16 Dec 2007 13:59:39 -0800 (PST) | Subject | Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage. | From | David Miller <> |
| |
From: Andrew Morton <akpm@linux-foundation.org> Date: Fri, 14 Dec 2007 15:36:33 -0800
> The networking bug looks to be around sock_i_ino()'s taking of > sk_callback_lock with softirq's enabled. Perhaps this will fix it.
One should be suspicious of any case where write_lock is performed on sk->sk_callback_lock in softint context. And that's the only way this can trigger, so this patch is wrong.
Generally, sock_orphan() and sock_graft() are the only primary places where sk->sk_callback_lock is acquired as a writer. And these should be invoked only from process context.
Perhaps there is some exception to this in some specialized layer such as SUNRPC, which are the only other spots I see potentially doing sk->sk_callback_lock write acquires in softint context, which as stated should not be done.
OCFS2 and ISCSI seem to be following the rules in it's write lock calls on this lock.
| |