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

On Fri, Jul 24, 2015 at 04:09:02PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 24, 2015 at 01:16:05PM -0700, Davidlohr Bueso wrote:
> > On Fri, 2015-07-24 at 15:33 +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > allnoconfig) failed like this:
> > > 
> > > mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
> > > vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
> > > vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
> > > mm/built-in.o: In function `unregister_shrinker':
> > > (.text+0xfa60): undefined reference to `synchronize_srcu'
> > > mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'
> > > 
> > > Caused by commit
> > > 
> > >   dab937da82f9 ("mm: srcu-ify shrinkers")
> > > 
> > > I have reverted that commit for today.
> > 
> > Adding paulmck.
> > 
> > I'm not entirely sure what is the fix here. Paul G also reported it
> > failing for arm. I was able to reproduce with powerpc, and the following
> > fixes the issue, but I doubt it is the correct way to address this. The
> > idea was based on how we do it for x86.
> > 
> > Also, having SRCU in mm is, lets say, more than convenient, beyond
> > MMU_NOTIFIERS which explicitly selects SRCU.
> > 
> > Paul?
> 
> SRCU was made optional as part of the kernel tinification project,
> so adding Josh on CC.  The hope would be that the feature needing SRCU
> could add the "select" rather than having major architectures doing so.
> 
> I guess if SRCU is needed everywhere, it is needed everywhere, but...

I certainly agree that it doesn't make sense to make all architectures
select SRCU, if an unremovable core kernel feature uses SRCU.  If
possible, I'd really like to avoid seeing SRCU become mandatory again,
though.

Is there any chance at all of the shrinker mechanism becoming optional?
At first glance, it seems reasonably separate from the rest of mm, in
that if it didn't exist and shrinking didn't happen, the rest of mm
still works.  If that happened, MM_SHRINKER could select SRCU.

If that's not possible, then for the moment, I'd suggest making a hidden
symbol MM_SHRINKER that's always y and does "select SRCU", to preserve
SRCU's modularity for the moment while not forcing every architecture to
select it.

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