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: <4753EFA3.9020309@balabit.hu>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ