netdev - Re: [PATCHv7 1/5] Remove unnecessary locks from rtnetlink (in do

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]

Date:	Mon, 03 Dec 2007 12:59:31 +0100
From:	Laszlo Attila Toth <panther@...abit.hu>
To:	Jarek Poplawski <jarkao2@...pl>
CC:	David Miller <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: [PATCHv7 1/5] Remove unnecessary locks from rtnetlink (in do_setlink)

Jarek Poplawski írta:
> Laszlo Attila Toth wrote, On 11/29/2007 05:11 PM:
> 
>> The do_setlink function is protected by rtnl, additional locks are unnecessary,
>> and the set_operstate() function is called from protected parts. Locks removed
>> from both functions.
> 
> It doesn't look like in accordance with a comment to dev_base_lock in dev.c.
> And it makes eg. rfc2863_policy() locking from link_watch.c looking strange.
> Isn't there needed some additional comment to this?

I modified do_setlink(), but set_operstate() is also called from
rtnl_create_link() and from no other places.  In rtnl_create_link() none 
of the changes is protected by set_lock_bh() except inside 
set_operstate(), different locking scheme is not necessary for the 
operstate.

Also two solution can be made, one is locking everything and one is 
locking nothing (to unify the changes made by these parts). The second 
one is better if it is protected.

I tried to figure out how it is protected but I couldn't. But Patrick 
said it is protected by rtnl. And he suggested this patch.

Attila
--
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