On Fri, 29 Nov 2013, Sebastian Andrzej Siewior wrote:
> * Nicholas Mc Guire | 2013-11-23 00:39:25 [+0100]:
>
> >hmmm. am I looking at the wrong code path ?
> No, it was me, sorry for the confusion.
> So this patch should work. What I am concerned is what Peter mentioned.
> It seems that we have no user of this "alternative" unlock path right
> now but it could become a ticking time bomb.
>
yes that is a concern. I scaned the kernel source tree with some cocci scripts
to find these problems. And actually I only found 3 (1 with write_lock_bh, 2
with spin_lock_bh ), all 3 in net/core/*, but the maintainer does not seem
willing to include these cleanups so those cleanups do not seem doable.
the found locations are:
file:linux-stable-rt4/net/core/sock.c lock split at lines 2382 2392 2397
file:linux-stable-rt4/net/ipv4/inet_hashtables.c lock split at lines 571 577 581
file:linux-stable-rt4/net/core/neighbour.c lock split at lines 969 1024 1025
The basic model of the scanner is like below, might be useful for other
problems as well. you need a whole set of the possible variations and
then simply brute force iterate over the kernel with
find . -name "*.c" -exec spatch -sp_file read_lock.cocci {} \;
@r1@
identifier f;
expression E;
position p1,p2,p3;
@@
f(...) {
<...
(
read_lock_bh(E)@p1;
...
read_unlock(E)@p2;
...
local_bh_enable()@p3;
|
local_bh_disable()@p1;
...
read_lock(E)@p2;
...
read_unlock_bh(E)@p3;
)
...>
}
@script:python@
p1 << r1.p1;
p2 << r1.p2;
p3 << r1.p3;
@@
print "file:%s lock split at lines %s %s %s" % (p1[0].file,p1[0].line, p2[0].line, p3[0].line)
so there are ways to defuse these timebombs
the problem is more the reluctance of net/core to accept such patches
as David Miller considers the lock splitting to be a valid locking idiom
so its probably not woth pushing this further.
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
