netdev - Re: netlink locking warnings in 2.6.21-rc7-mm1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <462F54F3.9050306@trash.net>
Date:	Wed, 25 Apr 2007 15:17:39 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	netdev@...r.kernel.org
Subject: Re: netlink locking warnings in 2.6.21-rc7-mm1

Herbert Xu wrote:
> David Miller <davem@...emloft.net> wrote:
> 
>>I think I see what might be the problem, nlk->cb_mutex is set
>>to "rtnl_mutex" and this is used for other purposes in various
>>code paths here, maybe there is a double mutex_unlock() or
>>similar due to that?
> 
> 
> Indeed, the RTNL is held during the processing of all RTNETLINK
> messages so we'd be trying to lock it recursively here which is
> not allowed.


No, it is released before calling netlink_dump_start().

> Actually I'm not quite sure what the benefit is for allowing an
> override CB mutex.  Since we still have to take it and we always
> allocate memory for a mutex anyway this would seem to be strictly
> worse than just using our own mutex.


The idea was that netlink families that don't want to consistently
hold the same mutex used for queue processing during the entire
dump operation can still have per-socket mutexes just to protect
the callback data and have concurrent dump continuations.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html