linux-kernel - Re: [PATCH] netfilter: use per-CPU r**ursive lock {XV}

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: <20090428124033.GA1655@elte.hu>
Date:	Tue, 28 Apr 2009 14:40:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	dada1@...mosbay.com, torvalds@...ux-foundation.org,
	shemminger@...tta.com, zbr@...emap.net, peterz@...radead.org,
	mathieu.desnoyers@...ymtl.ca, jarkao2@...il.com, paulus@...ba.org,
	paulmck@...ux.vnet.ibm.com, kaber@...sh.net,
	jeff.chua.linux@...il.com, laijs@...fujitsu.com,
	jengelh@...ozas.de, r000n@...0n.net, linux-kernel@...r.kernel.org,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
	benh@...nel.crashing.org
Subject: Re: [PATCH] netfilter: use per-CPU r**ursive lock {XV}

* David Miller <davem@...emloft.net> wrote:

> From: Eric Dumazet <dada1@...mosbay.com>
> Date: Tue, 28 Apr 2009 08:58:05 +0200
> 
> > I am not sure my day job will permit me to polish a patch mixing all
> > the bits and comments. But I am glad we eventually got back spinlocks
> > which are probably better than rwlocks for implementing this stuff.
> > 
> > Instead of submitting a full patch again, we could first submit a new
> >  include file containg all comments and inline functions ?
> > 
> > This include file could be local to netfilter, with a big stick on
> > it to forbids its use on other areas (No changes in Documentation/ )
> > 
> > Then, as soon as we can go back to pure RCU solution, we can 
> > safely delete this controversial-locking-nesting-per-cpu-thing ?
> 
> I say we merge Linus's locking idea into the XV patch, fixup the 
> commit message wording, and move on with life.
> 
> For something that's going to get deleted as soon as the faster 
> grace period RCU stuff is available, it has consumed an inordinate 
> amount of our time :-)

One more reason to factor out this code into general locking code.

The latest code looks a bit similar to the old big-reader-locks hack 
(which got dropped for good many eons ago and with which i deny any 
involvement with, such as having authored it. [oh, did i say that 
out loud? crap.]), implemented cleanly and properly.

IMHO this locking construct should be considered for 
linux/local_lock.h and kernel/local_lock.c. Even if the netfilter 
code drops its use soon afterwards ;-)

[ The _only_ thing i am worried about is the apparent fact that
  there's so much confusion about recursion versus read-access.
  Recursion might be hard to factor out of the netfilter code, and
  maybe it's not even possible realistically (we fought years with
  the BKL and are still fighting it) but if its harms are not even
  _realized_ that difficult task turns into an impossible task ;-) ]

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/