netdev - Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 21 Jan 2015 11:59:25 +0000
From:	Patrick McHardy <kaber@...sh.net>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>, davem@...emloft.net,
	paulmck@...ux.vnet.ibm.com, ying.xue@...driver.com,
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH 3/3] netlink: Lock out table resizes while dumping
 Netlink sockets

On 21.01, Thomas Graf wrote:
> On 01/21/15 at 10:40am, Patrick McHardy wrote:
> > On the danger of repeating myself, every (converted) user requires
> > that we at least keep the existing semantics since it is exposed to
> > userspace. My opinion is that NLM_F_DUMP_INTR is fine if userspace
> > indicates support, but without that, we have to take care of that
> > in the kernel.
> 
> Absolutely agreed. I think this is an excellent low cost path for
> future users where dumps are rare.
> 
> > An automatic restart handles this well. Userspace always had to
> > expect duplicates.
> 
> Maybe I don't understand the restart yet. How do you restart if the
> dump was already started and the user has read part of the dump?

You use the mutex to prevent concurrent resizes and dumps, for dumps
that have left the kernel you simply reset the iterator state after
a resize operation.
--
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