netdev - Re: [PATCH v2] net: fix sleeping while atomic problem in sock mem

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:	Fri, 16 Dec 2011 11:04:46 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Glauber Costa <glommer@...allels.com>
Cc:	davem@...emloft.net, linux-kernel@...r.kernel.org,
	kamezawa.hiroyu@...fujitsu.com, netdev@...r.kernel.org,
	cgroups@...r.kernel.org, Stephen Rothwell <sfr@...b.auug.org.au>,
	Randy Dunlap <rdunlap@...otime.net>
Subject: Re: [PATCH v2] net: fix sleeping while atomic problem in sock
 mem_cgroup.

Le vendredi 16 décembre 2011 à 13:53 +0400, Glauber Costa a écrit :
> On 12/16/2011 01:31 PM, Eric Dumazet wrote:
> > Le vendredi 16 décembre 2011 à 13:09 +0400, Glauber Costa a écrit :
> >> Since we can't scan the proto_list to initialize sock cgroups, as it
> >> holds a rwlock, and we also want to keep the code generic enough to
> >> avoid calling the initialization functions of protocols directly,
> >> I propose we keep the interested parties in a separate list. This list
> >> is protected by a mutex so we can sleep and do the necessary allocations.
> >>
> >> Also fixes a reference problem found by Randy Dunlap's randconfig.
> >>
> >> Signed-off-by: Glauber Costa<glommer@...allels.com>
> >> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@...fujitsu.com>
> >> CC: David S. Miller<davem@...emloft.net>
> >> CC: Eric Dumazet<eric.dumazet@...il.com>
> >> CC: Stephen Rothwell<sfr@...b.auug.org.au>
> >> CC: Randy Dunlap<rdunlap@...otime.net>
> >> ---
> >
> > Sorry to come late, but why dont we convert proto_list_lock to a mutex ?
> 
> I didn't suggest this, as I imagined there could be some performance 
> implications to be drawn from it that may not be obvious to me.
> 
> But if it is okay with you net guys, it is certainly okay with me as well.

This 'lock' is not performance sensitive, its very seldom taken.

If we really wanted to be fast, it would not be a rwlock anymore ;)

"cat /proc/net/protocols" could eventually use RCU locking if we want
parallelism. (I dont think its needed)



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