[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180104.102204.2173725641982775376.davem@davemloft.net>
Date: Thu, 04 Jan 2018 10:22:04 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: ying.xue@...driver.com
Cc: netdev@...r.kernel.org, jon.maloy@...csson.com,
syzkaller-bugs@...glegroups.com,
tipc-discussion@...ts.sourceforge.net
Subject: Re: [PATCH net] tipc: fix missing rtnl lock protection during
setting link properties
From: Ying Xue <ying.xue@...driver.com>
Date: Thu, 4 Jan 2018 15:30:52 +0800
> On 01/03/2018 11:48 PM, David Miller wrote:
>> As soon as you drop the RTNL lock, the media or bearer entry can be
>> removed from the tables.
>>
>
> Thanks for the review. Yes, you are right. But even if we temporarily
> release RTNL lock, it's still safe for us because when we set
> media/bearer properties in __tipc_nl_compat_doit(), tipc_nl_media_set()
> and tipc_nl_bearer_set() will probe media or bearer again within RTNL
> lock protection.
>
>> This invalidates what you do next, whether it's
>> tipc_nl_compat_media_set(), tipc_nl_compat_bearer_set(), etc.
>
> In fact tipc_nl_compat_media_set() and tipc_nl_compat_bearer_set() don't
> really change media or bearer's properties, instead they only format the
> contents pointed by their "msg" parameter.
However, those values are only valid to place into the netlink message if
in fact we successfully found a media or bearer entry.
You have to hold RTNL across this whole construct, from the discovery of
the media or bearer entry all the way to the completion of filling in
the netlink message, one way or another.
Powered by blists - more mailing lists