netdev - Re: [Patch net-next] bridge: fix seq check in br_mdb

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>] [day] [month] [year] [list]

Message-Id: <20121211.134512.1155163977355007483.davem@davemloft.net>
Date:	Tue, 11 Dec 2012 13:45:12 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	amwang@...hat.com
Cc:	netdev@...r.kernel.org, herbert@...dor.hengli.com.au,
	shemminger@...tta.com, tgraf@...g.ch, brouer@...hat.com
Subject: Re: [Patch net-next] bridge: fix seq check in br_mdb_dump()

From: Cong Wang <amwang@...hat.com>
Date: Tue, 11 Dec 2012 11:49:32 +0800

> On Mon, 2012-12-10 at 13:46 -0500, David Miller wrote:
>> From: Cong Wang <amwang@...hat.com>
>> Date: Mon, 10 Dec 2012 20:15:35 +0800
>> 
>> > From: Cong Wang <amwang@...hat.com>
>> > 
>> > In case of rehashing, introduce a global variable 'br_mdb_rehash_seq'
>> > which gets increased every time when rehashing, and assign
>> > net->dev_base_seq + br_mdb_rehash_seq to cb->seq.
>> > 
>> > In theory cb->seq could be wrapped to zero, but this is not
>> > easy to fix, as net->dev_base_seq is not visible inside
>> > br_mdb_rehash(). In practice, this is rare.
>> > 
>> > Cc: Herbert Xu <herbert@...dor.apana.org.au>
>> > Cc: Stephen Hemminger <shemminger@...tta.com>
>> > Cc: "David S. Miller" <davem@...emloft.net>
>> > Cc: Thomas Graf <tgraf@...g.ch>
>> > Cc: Jesper Dangaard Brouer <brouer@...hat.com>
>> > Signed-off-by: Cong Wang <amwang@...hat.com>
>> 
>> No synchronization at all is applied to this variable, I can't
>> see how this is OK.
> 
> br_mdb_rehash() is protected by the multicast spinlock, so increasing
> this variable is protected by it, and reading the variable doesn't need
> locking. Am I missing anything? Or should we use atomic_t?

I missed that locking, ok, looks good.

Applied, thanks.
--
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