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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2017-06-14 at 19:16 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell <sfr@xxxxxxxxxxxxx.a
> u> wrote:
> > Hi Kees,
> > 
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@xxxxxxxxxxxx>
> > wrote:
> > > 
> > > I sent a series for -mm (or maintainers) to merge that should
> > > catch
> > > everything. Do you want me to carry it in my kspp tree instead?
> > > (My
> > > original intention was to carry all the fixes and the fortify
> > > patch in
> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> > > complaining.)
> > 
> > Andrew is currently not responding to stuff (he warned us last
> > week),
> > so if you do put the series in your tree, I will remove it from my
> > copy
> > of Andrew's quilt series.  All the fixes necessary to make this
> > usable
> > should really be in the same tree if possible.
> > 
> > (I am assuming that the fix patches have been reviewed and acked by
> > appropriate people.)
> 
> Mostly, yes. But they're usually trivial. All have been sent out for
> review (some a few times).
> 
> Given that the fixes are already scattered between various trees and
> you merge -mm last in -next, I'll just carry the remaining fixes and
> you can leave akpm's fortify patch in -mm.
> 
> -Kees

I think compile-time fixes should be totally done for 32-bit x86,
x86_64, arm64 and powerpc but the patches just aren't all queued up in
-mm/-next.

The arch mailing list was pinged about this which is how the powerpc
folks got involved and fixed the issues there, including at least one
runtime one. Not sure where (if anywhere) those are queued up, but Kees
could pick those up too.

For other archs, these might end up being issues requiring #ifndef
CONFIG_FORTIFY_SOURCE wrapped around them as was done for 32-bit x86, or
just removal because it's obsolete with GCC from the past 6+ years:

arch/alpha/include/asm/string.h:21:#define memcpy __builtin_memcpy
arch/m68k/include/asm/string.h:63:#define memcmp(d, s, n) __builtin_memcmp(d, s, n)
arch/m68k/include/asm/string.h:67:#define memset(d, c, n) __builtin_memset(d, c, n)
arch/m68k/include/asm/string.h:71:#define memcpy(d, s, n) __builtin_memcpy(d, s, n)

I didn't do anything about those because I can't compile it or test it
right now, but maybe someone can be pinged about it. Might be a one or
two other archs with the same issue. An -mm build bot complained about
alpha (probably that) and xtensa (seems to define inline functions in
arch/xtensa/include/asm/string.h).
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux