LKML Archive on lore.kernel.org
 help / color / Atom feed
* Linux 5.8-rc1
@ 2020-06-14 20:44 Linus Torvalds
  2020-06-15  1:59 ` linux-next: stats (Was: Linux 5.8-rc1) Stephen Rothwell
  2020-06-16 20:11 ` Linux 5.8-rc1 Gabriel C
  0 siblings, 2 replies; 13+ messages in thread
From: Linus Torvalds @ 2020-06-14 20:44 UTC (permalink / raw)
  To: Linux Kernel Mailing List

So I didn't really expect this, but 5.8 looks to be one of our biggest
releases of all time.

As of -rc1, it's right up there with v4.9, which has long been our
biggest release by quite a bit in number of commits. Yes, 5.8-rc1 has
a couple fewer commits than 4.9-rc1 did, but in many ways it's a much
more comprehensive release despite that.

The 4.9 kernel was artificially big partly because of the greybus
subsystem that was merged in that release, but also because v4.8 had
had a longer rc series and thus there was more pent up development. In
5.8, we have no sign of those kinds of issues making the release
bigger - there's just simply a lot of development in there.

And there are other kernel releases that have had more new lines -
v4.12 ends up being the undisputed size champion in that regard,
simply because it had a _huge_ number of new lines due to lots of
register descriptions for the AMD GPU drivers. Other kernels have been
similarly big due to particular subsystems (v4.2 had another AMD GPU
driver line count bump, 2.6.29 had a big staging driver additions,
etc).

But again, 5.8 is up there with the best, despite not really having
any single thing that stands out. Yes, there's a couple of big driver
changes (habanalabs and atomisp) that are certainly part of it, but
it's not nearly as one-sided as some of the other historical big
releases have been.

The development is really all over the place: there's tons of fairly
fundamental core work and cleanups, but there is also lots of
filesystem work and obviously all the usual driver updates too. Plus
documentation and archiecture work.

In fact, while 5.8-rc1 is "up there with the best" when it comes to
both number of commits and number of new lines, it's actually the
outstanding champion when it comes to number of files changed.  And
again, that's not because of some single tree-wide simple scripting
thing (the kernels with lots of SPDX license line changes have a lot
of files changed), but simply because of lots and lots of development
work.

So in the 5.8 merge window we have modified about 20% of all the files
in the kernel source repository. That's really a fairly big
percentage, and while some of it _is_ scripted, on the whole it's
really just the same pattern: 5.8 has simply seen a lot of
development.

IOW, 5.8 looks big. Really big.

In pure numbers: over 14k non-merge commits (over 15k counting
merges),  ~800k new lines, and over 14 thousand files changed.

It's worth noting that despite the size, it doesn't necessarily look
like a particularly troublesome release at least so far. Yes, the pure
size made this merge window a bit more stressful than I like, because
I _really_ like to have a few days of calm at the end to look at some
of the pull requests in more detail. This time around that never
really happened. But I only really had two pull requests I ended up
wanting to go through in more detail, so it all worked out fine.

So the pure size of this merge window did make me (once again)
consider making it more of a hard rule that pull requests with new
features (as opposed to the second wave of pull requests with just
fixes) absolutely _have_ to come in during the first week of the merge
window, but honestly, _most_ of the pull requests did in fact do that.
No, not all, and it could have been a bit more organized, and maybe I
got snippy with somebody, but on the whole things were pretty smooth
despite the large size.

Famous last words. Let's see what happens during the rest of this release.

But at least right now, while 5.8 looks like a very large release, I
don't get the feeling that it's particularly troublesome.

Knock wood.

Appended is the merge-log as usual. If you didn't get the idea yet
(IT'S BIG!) the shortlog would be much too unwieldly, even more so
than usual.

              Linus

---

Al Viro (16):
    uaccess/csum updates
    uaccess/access_ok updates
    uaccess/readdir updates
    uaccess/__put-user updates
    uaccess/__copy_from_user updates
    uaccess/__copy_to_user updates
    uaccess/coredump updates
    vfs updates
    ia64 build regression fix
    splice updates
    comedi uaccess cleanups
    misc uaccess updates
    i915 uaccess updates
    sysctl fixes
    vfs fixes
    epoll update

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andreas Gruenbacher (1):
    gfs2 updates

Andrew Morton (7):
    updates
    more updates
    yet more updates
    still more updates
    even more updates
    some more updates
    updates

Andy Shevchenko (1):
    x86 platform driver updates

Anna Schumaker (1):
    NFS client updates

Arnaldo Carvalho de Melo (1):
    perf tooling updates

Arnd Bergmann (4):
    ARM SoC updates
    ARM defconfig updates
    ARM/SoC driver updates
    ARM devicetree updates

Benson Leung (1):
    chrome platform updates

Bjorn Andersson (2):
    rpmsg updates
    remoteproc updates

Bjorn Helgaas (1):
    PCI updates

Boris Brezillon (1):
    i3c update

Borislav Petkov (4):
    EDAC updates
    x86 microcode update
    x86 cache resource control updates
    READ_IMPLIES_EXEC changes

Bruce Fields (1):
    nfsd updates

Casey Schaufler (1):
    smack updates

Christian Brauner (1):
    thread updates

Christoph Hellwig (2):
    dma-mapping updates
    dma-mapping helpers

Corey Minyard (1):
    IPMI updates

Damien Le Moal (1):
    zonefs update

Dan Williams (1):
    libnvdimm updates

Daniel Lezcano (1):
    thermal updates

Daniel Thompson (1):
    kgdb updates

Darrick Wong (6):
    xfs updates
    DAX updates part one
    DAX updates part two
    DAX updates part three
    xfs fix
    iomap fix

Dave Airlie (4):
    drm updates
    drm fixes
    drm msm updates
    drm fixes

David Howells (4):
    keyring updates
    AFS updates
    AFS fixes
    notification queue

David Kleikamp (1):
    JFS update

David Miller (4):
    networking updates
    sparc updates
    networking fixes
    networking fixes

David Sterba (2):
    btrfs updates
    btrfs updates

David Teigland (1):
    dlm updates

Dmitry Torokhov (1):
    input updates

Dominik Brodowski (1):
    pcmcia updates

Dominique Martinet (1):
    9p update

Eric Biederman (4):
    proc updates
    execve updates
    proc fix
    proc fix

Eric Biggers (2):
    fscrypt updates
    fsverity updates

Gao Xiang (1):
    erofs updates

Geert Uytterhoeven (1):
    m68k updates

Greg KH (5):
    USB/PHY driver updates
    tty/serial driver updates
    staging/IIO driver updates
    driver core updates
    char/misc driver updates

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (1):
    hwmon updates

Helge Deller (1):
    parsic updates

Herbert Xu (2):
    crypto updates
    crypto fixes

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (16):
    kprobes updates
    RCU updates
    locking updates
    objtool updates
    perf updates
    EFI updates
    SMP updates
    x86 boot updates
    x86 build updates
    x86 cleanups
    x86 cpu updates
    x86 FPU updates
    x86 platform updates
    x86 vdso updates
    scheduler updates
    x86 mm updates

Jaegeuk Kim (1):
    f2fs updates

James Bottomley (2):
    SCSI updates
    more SCSI updates

James Morris (1):
    lockdown update

Jan Kara (2):
    fsnotify updates
    ext2 and reiserfs cleanups

Jarkko Sakkinen (1):
    tpm updates

Jason Gunthorpe (2):
    hmm updates
    rdma updates

Jassi Brar (1):
    mailbox updates

Jean Delvare (1):
    dmi update

Jens Axboe (5):
    block updates
    block driver updates
    io_uring updates
    block fixes
    io_uring fixes

Jessica Yu (1):
    module updates

Jiri Kosina (2):
    HID updates
    livepatching updates

Joerg Roedel (2):
    iommu updates
    iommu driver directory structure cleanup

John Johansen (1):
    apparmor updates

Jon Mason (1):
    NTB updates

Jonathan Corbet (2):
    documentation updates
    more documentation updates

Juergen Gross (1):
    xen updates

Kees Cook (1):
    pstore updates

Lee Jones (2):
    MFD updates
    backlight updates

Ley Foon Tan (1):
    nios2 update

Linus Walleij (2):
    GPIO updates
    pin control updates

Mark Brown (3):
    regmap updates
    spi updates
    regulator updates

Masahiro Yamada (3):
    Kbuild updates
    Kconfig updates
    more Kbuild updates

Matt Turner (1):
    alpha updates

Mauro Carvalho Chehab (2):
    media updates
    more media updates

Max Filippov (1):
    Xtensa updates

Micah Morton (1):
    SafeSetID update

Michael Ellerman (2):
    powerpc updates
    powerpc fix

Michael Tsirkin (1):
    virtio updates

Mike Marshall (1):
    orangefs updates

Mike Snitzer (1):
    device mapper updates

Miklos Szeredi (2):
    overlayfs updates
    fuse updates

Mimi Zohar (2):
    integrity updates
    integrity fix

Namjae Jeon (1):
    exfat update

Palmer Dabbelt (2):
    RISC-V updates
    more RISC-V updates

Paolo Bonzini (2):
    kvm updates
    more KVM updates

Paul Moore (2):
    audit updates
    SELinux updates

Pavel Machek (1):
    LED updates

Petr Mladek (2):
    printk updates
    printk fix

Rafael Wysocki (5):
    power management updates
    ACPI updates
    PNP update
    more power management updates
    more ACPI updates

Rich Felker (1):
    arch/sh updates

Richard Weinberger (3):
    MTD updates
    UBI update
    UML updates

Rob Herring (2):
    devicetree updates
    Devicetree fixes

Russell King (2):
    ARM updates
    ARM fixes

Sebastian Reichel (1):
    power supply and reset updates

Shuah Khan (2):
    kselftest updates
    Kunit updates

Stafford Horne (1):
    OpenRISC update

Stephen Boyd (1):
    clk updates

Steve French (2):
    cifs updates
    more cifs updates

Steven Rostedt (1):
    tracing updates

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (2):
    cgroup updates
    workqueue updates

Tetsuo Handa (1):
    tomoyo update

Thierry Reding (1):
    pwm updates

Thomas Bogendoerfer (1):
    MIPS updates

Thomas Gleixner (10):
    irq updates
    timer updates
    x86 timer updates
    x86 srbds fixes
    timer fix
    more x86 updates
    atomics rework
    the Kernel Concurrency Sanitizer
    x86 entry updates
    x86 RAS updates

Ulf Hansson (1):
    MMC updates

Vasily Gorbik (1):
    s390 updates

Vinod Koul (1):
    dmaengine updates

Wei Liu (1):
    hyper-v updates

Will Deacon (3):
    arm64 updates
    READ/WRITE_ONCE rework
    arm64 fixes

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

^ permalink raw reply	[flat|nested] 13+ messages in thread

* linux-next: stats (Was: Linux 5.8-rc1)
  2020-06-14 20:44 Linux 5.8-rc1 Linus Torvalds
@ 2020-06-15  1:59 ` Stephen Rothwell
  2020-06-16 20:11 ` Linux 5.8-rc1 Gabriel C
  1 sibling, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2020-06-15  1:59 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List


[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]

Hi all,

On Sun, 14 Jun 2020 13:44:07 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> So I didn't really expect this, but 5.8 looks to be one of our biggest
> releases of all time.

This was the second largest linux-next (and may have been the largest
if June 1 had not been a pubic holiday here).

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20200602 was the first linux-next after
the merge window opened.)

Commits in v5.8-rc1 (relative to v5.7):            14206
Commits in next-20200602:                          13631
Commits with the same SHA1:                        12174
Commits with the same patch_id:                      843 (1)
Commits with the same subject line:                  130 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20200602:     13147 92%

Some breakdown of the list of extra commits (relative to next-20200602)
in -rc1:

Top ten first word of commit summary:

    140 powerpc
    117 perf
     49 kvm
     46 net
     32 media
     23 drm
     22 dm
     21 thermal
     21 scsi
     19 x86

Top ten authors:

     45 christophe.leroy@csgroup.eu
     38 irogers@google.com
     32 christophe.leroy@c-s.fr
     21 acme@redhat.com
     20 mchehab+huawei@kernel.org
     20 masahiroy@kernel.org
     18 amit.kucheria@linaro.org
     16 david@redhat.com
     15 hare@suse.de
     14 viro@zeniv.linux.org.uk

Top ten commiters:

    148 mpe@ellerman.id.au
    120 acme@redhat.com
     80 davem@davemloft.net
     49 torvalds@linux-foundation.org
     39 pbonzini@redhat.com
     35 mst@redhat.com
     34 axboe@kernel.dk
     32 mchehab+huawei@kernel.org
     28 daniel.lezcano@linaro.org
     23 tglx@linutronix.de

There are also 485 commits in next-20200602 that didn't make it into
v5.8-rc1.

Top ten first word of commit summary:

     90 drm
     51 mm
     20 bus
     14 i2c
     13 fsinfo
     13 fs
     10 memory
     10 media
      8 soc
      8 fsi

Top ten authors:

     42 akpm@linux-foundation.org
     20 alexander.deucher@amd.com
     19 dhowells@redhat.com
     18 cai@lca.pw
     15 axboe@kernel.dk
     15 arnd@arndb.de
     12 minchan@kernel.org
     11 ysato@users.sourceforge.jp
     10 rppt@linux.ibm.com
     10 ira.weiny@intel.com

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

    164 sfr@canb.auug.org.au
     84 alexander.deucher@amd.com
     19 dhowells@redhat.com
     18 ysato@users.sourceforge.jp
     15 tglx@linutronix.de
     15 axboe@kernel.dk
     14 wsa@kernel.org
     14 manivannan.sadhasivam@linaro.org
     13 treding@nvidia.com
     11 tytso@mit.edu

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-14 20:44 Linux 5.8-rc1 Linus Torvalds
  2020-06-15  1:59 ` linux-next: stats (Was: Linux 5.8-rc1) Stephen Rothwell
@ 2020-06-16 20:11 ` Gabriel C
  2020-06-16 20:33   ` Arvind Sankar
  2020-06-16 20:37   ` Linux 5.8-rc1 Borislav Petkov
  1 sibling, 2 replies; 13+ messages in thread
From: Gabriel C @ 2020-06-16 20:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Hans de Goede

* Am So., 14. Juni 2020 um 22:44 Uhr schrieb Linus Torvalds
<torvalds@linux-foundation.org>:

Hello,

> So I didn't really expect this, but 5.8 looks to be one of our biggest
> releases of all time.
>

I hit a compiler error caused by e4160b2e4b02377c67f8ecd05786811598f39acd.

x86/purgatory: Fail the build if purgatory.ro has missing symbols

Having CONFIG_STACKPROTECTOR* & CONFIG_KEXEC_FILE enabled always
results in a linking error like this:

LD      arch/x86/purgatory/purgatory.chk
ld: arch/x86/purgatory/purgatory.ro: in function `verify_sha256_digest':
purgatory.c:(.text+0x108): undefined reference to `__stack_chk_fail'
ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform':
sha256.c:(.text+0x1c74): undefined reference to `__stack_chk_fail'
ld: arch/x86/purgatory/purgatory.ro: in function `__sha256_final':
sha256.c:(.text+0x1e65): undefined reference to `__stack_chk_fail'
ld: arch/x86/purgatory/purgatory.ro: in function `_kstrtoull':
string.c:(.text+0x2107): undefined reference to `__stack_chk_fail'

I didn't look closer at that but from the error, it seems to be,
some missing -fstack-protector* vs -fno-stack-protector* checks
somewhere.


Best Regards,

Gabriel C

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 20:11 ` Linux 5.8-rc1 Gabriel C
@ 2020-06-16 20:33   ` Arvind Sankar
  2020-06-16 21:17     ` Gabriel C
  2020-06-16 20:37   ` Linux 5.8-rc1 Borislav Petkov
  1 sibling, 1 reply; 13+ messages in thread
From: Arvind Sankar @ 2020-06-16 20:33 UTC (permalink / raw)
  To: Gabriel C; +Cc: Linus Torvalds, Linux Kernel Mailing List, Hans de Goede

On Tue, Jun 16, 2020 at 10:11:46PM +0200, Gabriel C wrote:
> * Am So., 14. Juni 2020 um 22:44 Uhr schrieb Linus Torvalds
> <torvalds@linux-foundation.org>:
> 
> Hello,
> 
> > So I didn't really expect this, but 5.8 looks to be one of our biggest
> > releases of all time.
> >
> 
> I hit a compiler error caused by e4160b2e4b02377c67f8ecd05786811598f39acd.
> 
> x86/purgatory: Fail the build if purgatory.ro has missing symbols
> 
> Having CONFIG_STACKPROTECTOR* & CONFIG_KEXEC_FILE enabled always
> results in a linking error like this:
> 
> LD      arch/x86/purgatory/purgatory.chk
> ld: arch/x86/purgatory/purgatory.ro: in function `verify_sha256_digest':
> purgatory.c:(.text+0x108): undefined reference to `__stack_chk_fail'
> ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform':
> sha256.c:(.text+0x1c74): undefined reference to `__stack_chk_fail'
> ld: arch/x86/purgatory/purgatory.ro: in function `__sha256_final':
> sha256.c:(.text+0x1e65): undefined reference to `__stack_chk_fail'
> ld: arch/x86/purgatory/purgatory.ro: in function `_kstrtoull':
> string.c:(.text+0x2107): undefined reference to `__stack_chk_fail'
> 
> I didn't look closer at that but from the error, it seems to be,
> some missing -fstack-protector* vs -fno-stack-protector* checks
> somewhere.
> 
> 
> Best Regards,
> 
> Gabriel C

Can you attach the output of gcc -dumpspecs and gcc -v? I suspect your
compiler enables stack protector by default. My distro compiler does
that too, but not if -ffreestanding is enabled (which it is for the
purgatory).

Does this patch help?

diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index b04e6e72a592..088bd764e0b7 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -34,6 +34,7 @@ KCOV_INSTRUMENT := n
 PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
 PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
 PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
+PURGATORY_CFLAGS += $(call cc-option,-fno-stack-protector)
 
 # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
 # in turn leaves some undefined symbols like __fentry__ in purgatory and not

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 20:11 ` Linux 5.8-rc1 Gabriel C
  2020-06-16 20:33   ` Arvind Sankar
@ 2020-06-16 20:37   ` Borislav Petkov
  2020-06-16 21:19     ` Gabriel C
  1 sibling, 1 reply; 13+ messages in thread
From: Borislav Petkov @ 2020-06-16 20:37 UTC (permalink / raw)
  To: Gabriel C; +Cc: Linus Torvalds, Linux Kernel Mailing List, Hans de Goede

On Tue, Jun 16, 2020 at 10:11:46PM +0200, Gabriel C wrote:
> I didn't look closer at that but from the error, it seems to be,
> some missing -fstack-protector* vs -fno-stack-protector* checks
> somewhere.

Can you give exact .config?

Also, what compiler exactly?

I have

CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
CONFIG_KEXEC_FILE=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y

here and gcc9 builds it fine.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 20:33   ` Arvind Sankar
@ 2020-06-16 21:17     ` Gabriel C
  2020-06-16 21:25       ` Arvind Sankar
  2020-06-16 21:35       ` Gabriel C
  0 siblings, 2 replies; 13+ messages in thread
From: Gabriel C @ 2020-06-16 21:17 UTC (permalink / raw)
  To: Arvind Sankar; +Cc: Linus Torvalds, Linux Kernel Mailing List, Hans de Goede

Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar
<nivedita@alum.mit.edu>:
>
> On Tue, Jun 16, 2020 at 10:11:46PM +0200, Gabriel C wrote:
> > * Am So., 14. Juni 2020 um 22:44 Uhr schrieb Linus Torvalds
> > <torvalds@linux-foundation.org>:
> >
> > Hello,
> >
> > > So I didn't really expect this, but 5.8 looks to be one of our biggest
> > > releases of all time.
> > >
> >
> > I hit a compiler error caused by e4160b2e4b02377c67f8ecd05786811598f39acd.
> >
> > x86/purgatory: Fail the build if purgatory.ro has missing symbols
> >
> > Having CONFIG_STACKPROTECTOR* & CONFIG_KEXEC_FILE enabled always
> > results in a linking error like this:
> >
> > LD      arch/x86/purgatory/purgatory.chk
> > ld: arch/x86/purgatory/purgatory.ro: in function `verify_sha256_digest':
> > purgatory.c:(.text+0x108): undefined reference to `__stack_chk_fail'
> > ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform':
> > sha256.c:(.text+0x1c74): undefined reference to `__stack_chk_fail'
> > ld: arch/x86/purgatory/purgatory.ro: in function `__sha256_final':
> > sha256.c:(.text+0x1e65): undefined reference to `__stack_chk_fail'
> > ld: arch/x86/purgatory/purgatory.ro: in function `_kstrtoull':
> > string.c:(.text+0x2107): undefined reference to `__stack_chk_fail'
> >
> > I didn't look closer at that but from the error, it seems to be,
> > some missing -fstack-protector* vs -fno-stack-protector* checks
> > somewhere.
> >
> >
> > Best Regards,
> >
> > Gabriel C
>
> Can you attach the output of gcc -dumpspecs and gcc -v? I suspect your
> compiler enables stack protector by default. My distro compiler does
> that too, but not if -ffreestanding is enabled (which it is for the
> purgatory).
>

Files including config uploaded to there:

http://crazy.dev.frugalware.org/kernel/

> Does this patch help?
>

I'll test in a bit and let you know.

> diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> index b04e6e72a592..088bd764e0b7 100644
> --- a/arch/x86/purgatory/Makefile
> +++ b/arch/x86/purgatory/Makefile
> @@ -34,6 +34,7 @@ KCOV_INSTRUMENT := n
>  PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
>  PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
>  PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
> +PURGATORY_CFLAGS += $(call cc-option,-fno-stack-protector)
>
>  # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
>  # in turn leaves some undefined symbols like __fentry__ in purgatory and not

Thx.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 20:37   ` Linux 5.8-rc1 Borislav Petkov
@ 2020-06-16 21:19     ` Gabriel C
  0 siblings, 0 replies; 13+ messages in thread
From: Gabriel C @ 2020-06-16 21:19 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: Linus Torvalds, Linux Kernel Mailing List, Hans de Goede

Am Di., 16. Juni 2020 um 22:37 Uhr schrieb Borislav Petkov <bp@alien8.de>:
>
> On Tue, Jun 16, 2020 at 10:11:46PM +0200, Gabriel C wrote:
> > I didn't look closer at that but from the error, it seems to be,
> > some missing -fstack-protector* vs -fno-stack-protector* checks
> > somewhere.
>
> Can you give exact .config?
>
> Also, what compiler exactly?

Sure, config and compiler information uploaded to there:

http://crazy.dev.frugalware.org/kernel/


>
> I have
>
> CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
> CONFIG_KEXEC_FILE=y
> CONFIG_HAVE_STACKPROTECTOR=y
> CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
> CONFIG_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR_STRONG=y
>
> here and gcc9 builds it fine.

I have gcc 9.2.1 20200215.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 21:17     ` Gabriel C
@ 2020-06-16 21:25       ` Arvind Sankar
  2020-06-16 22:00         ` Gabriel C
  2020-06-16 21:35       ` Gabriel C
  1 sibling, 1 reply; 13+ messages in thread
From: Arvind Sankar @ 2020-06-16 21:25 UTC (permalink / raw)
  To: Gabriel C
  Cc: Arvind Sankar, Linus Torvalds, Linux Kernel Mailing List,
	Hans de Goede, Borislav Petkov

On Tue, Jun 16, 2020 at 11:17:08PM +0200, Gabriel C wrote:
> Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar
> <nivedita@alum.mit.edu>:
> >
> > Can you attach the output of gcc -dumpspecs and gcc -v? I suspect your
> > compiler enables stack protector by default. My distro compiler does
> > that too, but not if -ffreestanding is enabled (which it is for the
> > purgatory).
> >
> 
> Files including config uploaded to there:
> 
> http://crazy.dev.frugalware.org/kernel/
> 

Yeah, your gcc doesn't have the -ffreestanding handling. Mine (from
gentoo) has this in the -dumpspecs output:

*cc1_options:
... %{nostdlib|nodefaultlibs|ffreestanding:-fno-stack-protector} ...

to switch off the default ssp when the standard libraries aren't available.

> > Does this patch help?
> >
> 
> I'll test in a bit and let you know.
> 
> > diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> > index b04e6e72a592..088bd764e0b7 100644
> > --- a/arch/x86/purgatory/Makefile
> > +++ b/arch/x86/purgatory/Makefile
> > @@ -34,6 +34,7 @@ KCOV_INSTRUMENT := n
> >  PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
> >  PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
> >  PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
> > +PURGATORY_CFLAGS += $(call cc-option,-fno-stack-protector)
> >
> >  # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
> >  # in turn leaves some undefined symbols like __fentry__ in purgatory and not
> 
> Thx.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 21:17     ` Gabriel C
  2020-06-16 21:25       ` Arvind Sankar
@ 2020-06-16 21:35       ` Gabriel C
  2020-06-16 22:25         ` [PATCH] x86/purgatory: Add -fno-stack-protector Arvind Sankar
  1 sibling, 1 reply; 13+ messages in thread
From: Gabriel C @ 2020-06-16 21:35 UTC (permalink / raw)
  To: Arvind Sankar; +Cc: Linus Torvalds, Linux Kernel Mailing List, Hans de Goede

Am Di., 16. Juni 2020 um 23:17 Uhr schrieb Gabriel C
<nix.or.die@googlemail.com>:
>
> Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar
> <nivedita@alum.mit.edu>:
> > Does this patch help?
> >
>
> I'll test in a bit and let you know.


With the patch the kernel compiles fine.

> > diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> > index b04e6e72a592..088bd764e0b7 100644
> > --- a/arch/x86/purgatory/Makefile
> > +++ b/arch/x86/purgatory/Makefile
> > @@ -34,6 +34,7 @@ KCOV_INSTRUMENT := n
> >  PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
> >  PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
> >  PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
> > +PURGATORY_CFLAGS += $(call cc-option,-fno-stack-protector)
> >
> >  # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
> >  # in turn leaves some undefined symbols like __fentry__ in purgatory and not
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 21:25       ` Arvind Sankar
@ 2020-06-16 22:00         ` Gabriel C
  2020-06-16 22:28           ` Arvind Sankar
  0 siblings, 1 reply; 13+ messages in thread
From: Gabriel C @ 2020-06-16 22:00 UTC (permalink / raw)
  To: Arvind Sankar
  Cc: Linus Torvalds, Linux Kernel Mailing List, Hans de Goede,
	Borislav Petkov

Am Di., 16. Juni 2020 um 23:25 Uhr schrieb Arvind Sankar
<nivedita@alum.mit.edu>:
>
> On Tue, Jun 16, 2020 at 11:17:08PM +0200, Gabriel C wrote:
> > Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar
> > <nivedita@alum.mit.edu>:
> > >
> > > Can you attach the output of gcc -dumpspecs and gcc -v? I suspect your
> > > compiler enables stack protector by default. My distro compiler does
> > > that too, but not if -ffreestanding is enabled (which it is for the
> > > purgatory).
> > >
> >
> > Files including config uploaded to there:
> >
> > http://crazy.dev.frugalware.org/kernel/
> >
>
> Yeah, your gcc doesn't have the -ffreestanding handling. Mine (from
> gentoo) has this in the -dumpspecs output:
>
> *cc1_options:
> ... %{nostdlib|nodefaultlibs|ffreestanding:-fno-stack-protector} ...
>
> to switch off the default ssp when the standard libraries aren't available.

I wondered what they enable to do that. it turns out it is a custom patch.
While I think having that is not bad, such patches lead to bugs like this one.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH] x86/purgatory: Add -fno-stack-protector
  2020-06-16 21:35       ` Gabriel C
@ 2020-06-16 22:25         ` Arvind Sankar
  2020-06-17  0:06           ` Linus Torvalds
  0 siblings, 1 reply; 13+ messages in thread
From: Arvind Sankar @ 2020-06-16 22:25 UTC (permalink / raw)
  To: x86, kexec
  Cc: linux-kernel, Gabriel C, Linus Torvalds, Hans de Goede, Borislav Petkov

The purgatory Makefile removes -fstack-protector options if they were
configured in, but does not currently add -fno-stack-protector.

If gcc was configured with the --enable-default-ssp configure option,
this results in the stack protector still being enabled for the
purgatory (absent distro-specific specs files that might disable it
again for freestanding compilations), if the main kernel is being
compiled with stack protection enabled (if it's disabled for the main
kernel, the top-level Makefile will add -fno-stack-protector).

This will break the build since commit
  e4160b2e4b02 ("x86/purgatory: Fail the build if purgatory.ro has missing symbols")
and prior to that would have caused runtime failure when trying to use
kexec.

Explicitly add -fno-stack-protector to avoid this, as done in other
Makefiles that need to disable the stack protector.

Reported-by: Gabriel C <nix.or.die@googlemail.com>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
---
 arch/x86/purgatory/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index b04e6e72a592..088bd764e0b7 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -34,6 +34,7 @@ KCOV_INSTRUMENT := n
 PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
 PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
 PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
+PURGATORY_CFLAGS += $(call cc-option,-fno-stack-protector)
 
 # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
 # in turn leaves some undefined symbols like __fentry__ in purgatory and not
-- 
2.26.2


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Linux 5.8-rc1
  2020-06-16 22:00         ` Gabriel C
@ 2020-06-16 22:28           ` Arvind Sankar
  0 siblings, 0 replies; 13+ messages in thread
From: Arvind Sankar @ 2020-06-16 22:28 UTC (permalink / raw)
  To: Gabriel C
  Cc: Arvind Sankar, Linus Torvalds, Linux Kernel Mailing List,
	Hans de Goede, Borislav Petkov

On Wed, Jun 17, 2020 at 12:00:14AM +0200, Gabriel C wrote:
> Am Di., 16. Juni 2020 um 23:25 Uhr schrieb Arvind Sankar
> <nivedita@alum.mit.edu>:
> >
> > On Tue, Jun 16, 2020 at 11:17:08PM +0200, Gabriel C wrote:
> > > Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar
> > > <nivedita@alum.mit.edu>:
> > > >
> > > > Can you attach the output of gcc -dumpspecs and gcc -v? I suspect your
> > > > compiler enables stack protector by default. My distro compiler does
> > > > that too, but not if -ffreestanding is enabled (which it is for the
> > > > purgatory).
> > > >
> > >
> > > Files including config uploaded to there:
> > >
> > > http://crazy.dev.frugalware.org/kernel/
> > >
> >
> > Yeah, your gcc doesn't have the -ffreestanding handling. Mine (from
> > gentoo) has this in the -dumpspecs output:
> >
> > *cc1_options:
> > ... %{nostdlib|nodefaultlibs|ffreestanding:-fno-stack-protector} ...
> >
> > to switch off the default ssp when the standard libraries aren't available.
> 
> I wondered what they enable to do that. it turns out it is a custom patch.
> While I think having that is not bad, such patches lead to bugs like this one.

Right. Debian also has a similar custom patch to adjust the specs. It
would probably be better if something were upstreamed :)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] x86/purgatory: Add -fno-stack-protector
  2020-06-16 22:25         ` [PATCH] x86/purgatory: Add -fno-stack-protector Arvind Sankar
@ 2020-06-17  0:06           ` Linus Torvalds
  0 siblings, 0 replies; 13+ messages in thread
From: Linus Torvalds @ 2020-06-17  0:06 UTC (permalink / raw)
  To: Arvind Sankar
  Cc: the arch/x86 maintainers, kexec, Linux Kernel Mailing List,
	Gabriel C, Hans de Goede, Borislav Petkov

On Tue, Jun 16, 2020 at 3:25 PM Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> The purgatory Makefile removes -fstack-protector options if they were
> configured in, but does not currently add -fno-stack-protector.

I took this directly, since the build failure seems so annoying if you
happen to have an affected compiler and config.

Maybe that's not very common, but ..

              Linus

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-14 20:44 Linux 5.8-rc1 Linus Torvalds
2020-06-15  1:59 ` linux-next: stats (Was: Linux 5.8-rc1) Stephen Rothwell
2020-06-16 20:11 ` Linux 5.8-rc1 Gabriel C
2020-06-16 20:33   ` Arvind Sankar
2020-06-16 21:17     ` Gabriel C
2020-06-16 21:25       ` Arvind Sankar
2020-06-16 22:00         ` Gabriel C
2020-06-16 22:28           ` Arvind Sankar
2020-06-16 21:35       ` Gabriel C
2020-06-16 22:25         ` [PATCH] x86/purgatory: Add -fno-stack-protector Arvind Sankar
2020-06-17  0:06           ` Linus Torvalds
2020-06-16 20:37   ` Linux 5.8-rc1 Borislav Petkov
2020-06-16 21:19     ` Gabriel C

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git