linux-kernel - Re: linux-next: build failure after merge of the akpm-current tree

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:	Mon, 27 Jul 2015 13:20:02 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Josh Triplett <josh@...htriplett.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the akpm-current tree

On Mon, 2015-07-27 at 13:03 -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett <josh@...htriplett.org> wrote:
> 
> > > Some mm functionality might very possibly rely on srcu in the future if
> > > we expect any chances of scaling, ie: faults. So I'd rather not take a
> > > short term solution here, as we'll probably be discussing this again
> > > otherwise.
> > 
> > What other mm functionality plans to use SRCU?

Right now I have (unpublished) patches that use srcu as a way to avoid
mmap_sem when faulting across the entire path. Previous alternatives
also use it, as ie, can involve IO and lots of other sleeping
operations. Yes, you can argue that they're not published all you want,
but I'm talking beyond my specific use case. Linux VM is known to scale,
why should we hide a core scalability tool from it?

> > Among other things, no-mmu builds might still be able to omit it.
> 
> Yup.

Makes sense.

> 
> It's pretty trivial to make the shrinker srcuification be a
> Kconfigurable thing.  A few little helper functions and we're done. 
> That way, non-SMP kernels can use the plain old rwsem if so desired.
> 
> otoh it's better to use the same mechanism on all kernels for reasons
> of testing coverage, maintenance cost, etc.
> 
> The mm-srcu-ify-shrinkers.patch changelog is suspiciously lacking in
> evidence-of-benefit.  We could just drop it?

That's up to you, but I feel we should have srcu available in mm.
Dropping this particular patch is only a band-aid, imo.

Thanks,
Davidlohr

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