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  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, 22 May 2020 17:12:23 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Will Deacon <will@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        elver@...gle.com, bp@...en8.de
Subject: Re: linux-next: build failure after merge of the tip tree

On Fri, May 22, 2020 at 05:49:44PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 22 May 2020 17:17:08 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > On Thu, 21 May 2020 18:35:22 +0100 Will Deacon <will@...nel.org> wrote:
> > >
> > > [+Marco and Boris]
> > > 
> > > On Fri, May 22, 2020 at 03:31:19AM +1000, Stephen Rothwell wrote:  
> > > > After merging the tip tree, all my linux-next builds took signficantly
> > > > longer and used much more memory.  In some cases, builds would seg fault
> > > > due to running out of memory :-(
> > > > 
> > > > I have eventaully bisected it to commit
> > > > 
> > > >   cdd28ad2d811 ("READ_ONCE: Use data_race() to avoid KCSAN instrumentation")
> > > > 
> > > > For my (e.g.) x86_64 allmodconfig builds (cross compiled on PowerPC le,
> > > > -j80) the elapsed time went from around 9 minutes to over 17 minutes
> > > > and the maximum resident size (as reported by /usr/bin/time) from around
> > > > 500M to around 2G (I saw lots of cc1 processes over 2G in size).
> > > > 
> > > > For tomorrow's linux-next (well, later today :-() I will revert that
> > > > commit (and its child) when I merge the tip tree.    
> > > 
> > > Sorry about that, seems we can't avoid running into compiler problems with
> > > this lot. The good news is that there's a series to fix this here:
> > > 
> > > https://lore.kernel.org/r/20200521142047.169334-1-elver@google.com
> > > 
> > > so hopefully this be fixed in -tip soon (but I agree that reverting the
> > > thing in -next in the meantime makes sense).  
> > 
> > Unfortunately, the revert didn't work, so instead I have used the tip
> > tree from next-20200518 for today (hopefully this will all be sorted
> > out by Monday).
> 
> And the rcu tree has merged part of the tip tree that contains the
> offending commits, so I have used the version fo the rcu tree from
> next-20200519 for today.

Please accept my apologies for my part of this problem!  I don't see
the slowdowns on my normal test system (possibly due to gcc 4.8.5),
but I do see them on my laptop.

Marco, Thomas, is there any better setup I can provide Stephen?  Or
is the next-20200519 -rcu tree the best we have right now?

							Thanx, Paul

Powered by blists - more mailing lists