linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 6.1-rc1
@ 2022-10-16 23:01 Linus Torvalds
  2022-10-17  1:53 ` linux-next: stats for 6.1-rc1 (was: Linux 6.1-rc1) Stephen Rothwell
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Linus Torvalds @ 2022-10-16 23:01 UTC (permalink / raw)
  To: Linux Kernel Mailing List

You all know the drill: it's Sunday afternoon, the two weeks of merge
window are over, and now we're supposed to start calming things down.

This isn't actually shaping up to be a particularly large release: we
"only" have 11.5k non-merge commits during this merge window, compared
to 13.5k last time around. So not exactly tiny, but smaller than the
last few releases. At least in number of commits.

That said, we've got a few core things that have been brewing for a
long time, most notably the multi-gen LRU VM series, and the initial
Rust scaffolding (no actual real Rust code in the kernel yet, but the
infrastructure is there).

And hey, this merge window was full of surprises for other reasons too
- my main machine was basically out of action for a couple of days
because it suddenly started showing memory problems, and it took me a
couple of days to get that sorted out (to a large degree because it
was unexpected and I started out blaming a kernel bug for the memory
corruption). All sorted out now, but it caused some frustration.

Talking about frustration, let me just say that after I got my machine
sorted out and caught up with the merge window, I wass somewhat
frustrated with various late pull requests. I've mentioned this
before, but it's _really_ quite annoying to get quite a few pull
requests in the last few days of the merge window.

Yes, the merge window is two weeks, but that's very much to allow me
time to look things over, not "two weeks to hurriedly put together a
branch that you send Linus on Friday of the second week". The whole
"do an all-nighter to get the paper in the day before the dealine" is
something that should have gone out the window after highschool. Not
for kernel development.

The rule is that things that get sent to me should be ready *before*
the merge window opens, not be made ready during the merge window.
With some slack for "life happens", of course, but I really get the
feeling that a few people treat the end of the merge window as a
deadline, missing the whole "it was supposed to be ready before the
merge window".

You know who you are.

Anyway, it's not the first time I've said this, I doubt it will be the
last. But maybe more people could take it to heart, ok?

Enough kvetching, let's get this party calmed down. The merge window
may not be the biggest ever, but it's certainly big enough that the
shortlog is much too big to post, and below is just my usual merge
log. For all the gory details, please refer to the git tree.

Please get the testing started,

                   Linus

---

Al Viro (7):
    coredump fix
    vfs inode update
    vfs d_path updates
    vfs file updates
    misc tomoyo changes
    vfs constification updates
    vfs tmpfile updates

Al Vrio (1):
    file_inode() updates

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (2):
    i3c updates
    RTC updates

Andreas Gruenbacher (2):
    gfs2 updates
    gfs2 debugfs updates

Andrew Morton (4):
    MM updates
    non-MM updates
    misc hotfixes
    more MM updates

Anna Schumaker (1):
    NFS client updates

Ard Biesheuvel (1):
    EFI updates

Arnaldo Carvalho de Melo (2):
    perf tools updates
    more perf tools updates

Arnd Bergmann (7):
    ARM defconfig updates
    ARM driver updates
    ARM devicetree updates
    ARM SoC updates
    asm-generic updates
    ARM SoC fixes
    asm-generic fix

Bartosz Golaszewski (1):
    gpio updates

Benjamin Tissoires (1):
    HID updates

Bjorn Andersson (2):
    rpmsg updates
    remoteproc updates

Bjorn Helgaas (2):
    pci updates
    pci fix

Borislav Petkov (14):
    EDAC updates
    x86 platform update
    x86 RTC cleanups
    x86 SGX update
    x86 cpu updates
    x86 RAS updates
    x86 APIC update
    x86 core fixes
    x86 asm update
    misc x86 fixes
    x86 paravirt fix
    x75 microcode loader updates
    x86 cache resource control updates
    x86 cleanups

Casey Schaufler (1):
    smack updates

Catalin Marinas (2):
    arm64 updates
    arm64 fixes

Christian Brauner (2):
    vfs acl updates
    fatfs vfsuid conversion

Christoph Hellwig (1):
    dma-mapping updates

Chuck Lever (2):
    nfsd updates
    more nfsd updates

Corey Minyard (1):
    IPMI updates

Damien Le Moal (1):
    ata updates

Dan Williams (1):
    nvdimm updates

Darrick Wong (1):
    iomap updates

Dave Airlie (3):
    drm updates
    drm fix
    more drm updates

Dave Chinner (1):
    xfs updates

Dave Hansen (1):
    x86 mm updates

David Sterba (2):
    btrfs updates
    affs update

David Teigland (1):
    dlm updates

Dmitry Torokhov (1):
    input updates

Dominik Brodowski (1):
    PCMCIA updates

Dominique Martinet (1):
    9p updates

Eric Biederman (4):
    kthread update
    mqueue fix
    ptrace update
    ucounts update

Eric Biggers (3):
    fscrypt updates
    fsverity updates
    STATX_DIOALIGN support

Gao Xiang (1):
    erofs updates

Geert Uytterhoeven (1):
    m68k updates

Greg KH (5):
    tty/serial driver updates
    USB / Thunderbolt updates
    driver core updates
    char/misc and other driver updates
    staging driver updates

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (1):
    hwmon updates

Hans de Goede (1):
    x86 platform driver updates

Helge Deller (2):
    fbdev updates
    parisc updates

Herbert Xu (1):
    crypto updates

Huacai Chen (1):
    LoongArch updates

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (5):
    scheduler updates
    perf events updates
    locking updates
    objtool updates
    PSI updates

Jaegeuk Kim (1):
    f2fs updates

Jakub Kicinski (2):
    networking updates
    networking fixes

James Bottomley (1):
    SCSI updates

Jan Kara (2):
    fsnotify updates
    ext2, udf, reiserfs, and quota updates

Jarkko Sakkinen (1):
    tpm updates

Jason Donenfeld (2):
    random number generator updates
    more random number generator updates

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jean Delvare (1):
    dmi updates

Jens Axboe (5):
    io_uring updates
    block updates
    passthrough updates
    more io_uring updates
    more block updates

Joerg Roedel (1):
    iommu updates

Jonathan Corbet (2):
    documentation updates
    documentation fixes

Juergen Gross (1):
    xen updates

Kees Cook (4):
    Rust introductory support
    execve updates
    kcfi updates
    kernel hardening updates

Lee Jones (2):
    backlight update
    MFD updates

Linus Walleij (1):
    pin control updates

Luis Chamberlain (2):
    module updates
    sysctl updates

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

Masahiro Yamada (2):
    Kbuild updates
    Kbuild fixes

Mauro Carvalho Chehab (1):
    media updates

Max Filippov (1):
    xtensa updates

Michael Ellerman (2):
    powerpc updates
    powerpc fixes

Michael Tsirkin (2):
    virtio updates
    virtio fixes

Michal Simek (1):
    microblaze updates

Mickaël Salaün (1):
    landlock updates

Mike Marshall (1):
    orangefs update

Mike Rapoport (1):
    memblock updates

Mimi Zohar (1):
    integrity updates

Miquel Raynal (1):
    MTD updates

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

Paolo Bonzini (2):
    kvm updates
    more kvm updates

Paul McKenney (3):
    nolibc updates
    LKMM (Linux Kernel Memory Model) updates
    RCU updates

Paul Moore (3):
    SELinux updates
    LSM updates
    audit updates

Pavel Machek (1):
    LED updates

Petr Mladek (2):
    printk updates
    livepatching updates

Rafael Wysocki (6):
    ACPI updates
    power management updates
    thermal control updates
    more ACPI updates
    more power management updates
    more thermal control updates

Richard Weinberger (2):
    UML updates
    UBI and UBIFS updates

Rob Herring (2):
    devicetree updates
    devicetree fixes

Russell King (2):
    ARM fixes
    ARM updates

Sebastian Reichel (2):
    HSI updates
    power supply and reset updates

Shuah Khan (4):
    Kselftest updates
    KUnit updates
    more Kselftest updates
    more KUnit updates

Stafford Horne (1):
    OpenRISC updates

Stephen Boyd (2):
    clk updates
    more clk updates

Steve French (3):
    ksmbd updates
    cifs updates
    more cifs updates

Steven Rostedt (2):
    tracing updates
    tracing fixes

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (1):
    cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Bogendoerfer (1):
    MIPS updates

Thomas Gleixner (3):
    preempt RT updates
    timer updates
    interrupt updates

Tzung-Bi Shih (1):
    chrome platform updates

Ulf Hansson (2):
    MMC updates
    MMC fixes

Vasily Gorbik (2):
    s390 updates
    more s390 updates

Vinod Koul (3):
    dmaengine updates
    phy updates
    soundwire updates

Vlastimil Babka (2):
    slab fixes
    slab hotfix

Wei Liu (1):
    hyperv updates

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (2):
    i2c updates
    more i2c updates

Yury Norov (1):
    bitmap updates

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

* linux-next: stats for 6.1-rc1 (was: Linux 6.1-rc1)
  2022-10-16 23:01 Linux 6.1-rc1 Linus Torvalds
@ 2022-10-17  1:53 ` Stephen Rothwell
  2022-10-17  2:58 ` 6.1rc1: NFS memcpy warning on mount Dave Jones
  2022-10-17 12:34 ` Linux 6.1-rc1 Guenter Roeck
  2 siblings, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2022-10-17  1:53 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Linus Torvalds, Linux Next Mailing List

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

Hi all,

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

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

Commits in v6.1-rc1 (relative to v6.0):            11537
Commits in next-20221004:                          11354
Commits with the same SHA1:                        10436
Commits with the same patch_id:                      342 (1)
Commits with the same subject line:                   20 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20221004:     10798 93%

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

Top ten first word of commit summary:

    122 perf
     98 drm
     23 wifi
     21 pci
     21 dt-bindings
     20 net
     18 tracing
     16 rtc
     16 clk
     16 alsa

Top ten authors:

     28 namhyung@kernel.org
     23 irogers@google.com
     21 adrian.hunter@intel.com
     16 rostedt@goodmis.org
     14 rodrigo.siqueira@amd.com
     13 carsten.haitzler@arm.com
     12 mani@kernel.org
     11 conor.dooley@microchip.com
      9 johannes.berg@intel.com
      9 jason@zx2c4.com

Top ten commiters:

    124 acme@redhat.com
     96 alexander.deucher@amd.com
     33 stfrench@microsoft.com
     32 palmer@rivosinc.com
     30 kuba@kernel.org
     29 rostedt@goodmis.org
     22 davem@davemloft.net
     20 akpm@linux-foundation.org
     18 johannes.berg@intel.com
     18 alexandre.belloni@bootlin.com

There are also 556 commits in next-20221004 that didn't make it into
v6.1-rc1.

Top ten first word of commit summary:

    163 media
     47 apparmor
     42 arm
     30 thermal
     28 fs
     17 dt-bindings
     16 scsi
     15 drm
     13 mm
     11 soc

Top ten authors:

     41 hdegoede@redhat.com
     40 john.johansen@canonical.com
     36 willy@infradead.org
     30 daniel.lezcano@linaro.org
     22 paul.kocialkowski@bootlin.com
     22 laurent.pinchart@ideasonboard.com
     15 krzysztof.kozlowski@linaro.org
     12 joel@jms.id.au
     11 william.gray@linaro.org
     11 tomi.valkeinen@ideasonboard.com

Top ten commiters:

    163 mchehab@kernel.org
     47 john.johansen@canonical.com
     42 willy@infradead.org
     30 daniel.lezcano@linaro.org
     23 joel@jms.id.au
     22 almaz.alexandrovich@paragon-software.com
     18 srinivas.kandagatla@linaro.org
     18 akpm@linux-foundation.org
     16 martin.petersen@oracle.com
     15 william.gray@linaro.org

-- 
Cheers,
Stephen Rothwell

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

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

* 6.1rc1: NFS memcpy warning on mount
  2022-10-16 23:01 Linux 6.1-rc1 Linus Torvalds
  2022-10-17  1:53 ` linux-next: stats for 6.1-rc1 (was: Linux 6.1-rc1) Stephen Rothwell
@ 2022-10-17  2:58 ` Dave Jones
  2022-10-17  3:58   ` Bagas Sanjaya
  2022-10-17  4:57   ` Kees Cook
  2022-10-17 12:34 ` Linux 6.1-rc1 Guenter Roeck
  2 siblings, 2 replies; 12+ messages in thread
From: Dave Jones @ 2022-10-17  2:58 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Trond Myklebust, Anna Schumaker, Linus Torvalds

Started getting this during mount on a 6.1rc1 kernel..
not sure which mount it's complaining about, but they're all v3 tcp
mounts on that machine.

[   19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
[   19.617504] WARNING: CPU: 3 PID: 1300 at fs/nfs/super.c:857 nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
[   19.617528] CPU: 3 PID: 1300 Comm: mount.nfs Not tainted 6.1.0-rc1-backup+ #1
[   19.617553] RIP: 0010:nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
[   19.617566] Code: 16 81 01 00 75 9b 48 c7 c1 ff ff ff ff 48 c7 c2 a8 a8 82 ab 4c 89 e6 c6 05 36 16 81 01 01 48 c7 c7 a8 3a 81 ab e8 61 1d 9a 00 <0f> 0b 48 8b 3c 24 e9 6c ff ff ff c7 83 20 01 00 00 01 00 00 00 b8
[   19.617593] RSP: 0018:ffffc900027fbd48 EFLAGS: 00010286
[   19.617604] RAX: 0000000000000000 RBX: ffff8881208d5000 RCX: ffff88842fadb7a8
[   19.617617] RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff88842fadb7a0
[   19.617629] RBP: ffff8881208d5130 R08: 0000000000000000 R09: ffffffffaba5c540
[   19.617641] R10: 0000000000000001 R11: 0000000000000001 R12: 000000000000001c
[   19.617653] R13: 0000000000000001 R14: ffffc900027fbef0 R15: ffff888100b3bea0
[   19.617665] FS:  00007ff793dd6840(0000) GS:ffff88842fac0000(0000) knlGS:0000000000000000
[   19.617679] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   19.617690] CR2: 0000564a1a747468 CR3: 00000001106fb003 CR4: 00000000001706e0
[   19.617703] Call Trace:
[   19.617709]  <TASK>
[   19.617716]  nfs_try_get_tree+0xa1/0x220
[   19.617725]  ? get_nfs_version+0x63/0x130
[   19.617736]  vfs_get_tree+0x1d/0x90
[   19.617746]  ? capable+0x2f/0x50
[   19.617755]  path_mount+0x75c/0xb00
[   19.617766]  __x64_sys_mount+0x19a/0x200
[   19.617775]  do_syscall_64+0x35/0x80
[   19.617785]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[   19.617796] RIP: 0033:0x7ff7941ac6ea
[   19.617805] Code: 48 8b 0d a9 17 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 17 0d 00 f7 d8 64 89 01 48
[   19.617832] RSP: 002b:00007ffd02ae4ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
[   19.617846] RAX: ffffffffffffffda RBX: 00007ffd02ae4e70 RCX: 00007ff7941ac6ea
[   19.617858] RDX: 0000564a1a73fb60 RSI: 0000564a1a73fb80 RDI: 0000564a1a741890
[   19.617870] RBP: 00007ff793dd67b8 R08: 0000564a1a73f480 R09: 0000564a1a73f480
[   19.617882] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[   19.617894] R13: 00007ffd02ae4dd0 R14: 0000564a1a7474e0 R15: 0000564a1a7436b0
[   19.617907]  </TASK>
[   19.617913] irq event stamp: 8757
[   19.617920] hardirqs last  enabled at (8769): [<ffffffffaa1397c2>] __up_console_sem+0x52/0x60
[   19.617937] hardirqs last disabled at (8780): [<ffffffffaa1397a7>] __up_console_sem+0x37/0x60
[   19.617952] softirqs last  enabled at (8180): [<ffffffffaabf547a>] sk_common_release+0x5a/0xe0
[   19.617969] softirqs last disabled at (8178): [<ffffffffaabf5456>] sk_common_release+0x36/0xe0
[   19.617984] ---[ end trace 0000000000000000 ]---

	Dave

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

* Re: 6.1rc1: NFS memcpy warning on mount
  2022-10-17  2:58 ` 6.1rc1: NFS memcpy warning on mount Dave Jones
@ 2022-10-17  3:58   ` Bagas Sanjaya
  2022-10-17  4:17     ` Kees Cook
  2022-10-17  4:57   ` Kees Cook
  1 sibling, 1 reply; 12+ messages in thread
From: Bagas Sanjaya @ 2022-10-17  3:58 UTC (permalink / raw)
  To: Dave Jones, Linux Kernel Mailing List, linux-nfs,
	linux-hardening, Trond Myklebust, Scott Mayhew, Anna Schumaker,
	Kees Cook, Linus Torvalds

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

On Sun, Oct 16, 2022 at 10:58:21PM -0400, Dave Jones wrote:
> Started getting this during mount on a 6.1rc1 kernel..
> not sure which mount it's complaining about, but they're all v3 tcp
> mounts on that machine.
> 
> [   19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
> [   19.617504] WARNING: CPU: 3 PID: 1300 at fs/nfs/super.c:857 nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
> [   19.617528] CPU: 3 PID: 1300 Comm: mount.nfs Not tainted 6.1.0-rc1-backup+ #1
> [   19.617553] RIP: 0010:nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
> [   19.617566] Code: 16 81 01 00 75 9b 48 c7 c1 ff ff ff ff 48 c7 c2 a8 a8 82 ab 4c 89 e6 c6 05 36 16 81 01 01 48 c7 c7 a8 3a 81 ab e8 61 1d 9a 00 <0f> 0b 48 8b 3c 24 e9 6c ff ff ff c7 83 20 01 00 00 01 00 00 00 b8
> [   19.617593] RSP: 0018:ffffc900027fbd48 EFLAGS: 00010286
> [   19.617604] RAX: 0000000000000000 RBX: ffff8881208d5000 RCX: ffff88842fadb7a8
> [   19.617617] RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff88842fadb7a0
> [   19.617629] RBP: ffff8881208d5130 R08: 0000000000000000 R09: ffffffffaba5c540
> [   19.617641] R10: 0000000000000001 R11: 0000000000000001 R12: 000000000000001c
> [   19.617653] R13: 0000000000000001 R14: ffffc900027fbef0 R15: ffff888100b3bea0
> [   19.617665] FS:  00007ff793dd6840(0000) GS:ffff88842fac0000(0000) knlGS:0000000000000000
> [   19.617679] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   19.617690] CR2: 0000564a1a747468 CR3: 00000001106fb003 CR4: 00000000001706e0
> [   19.617703] Call Trace:
> [   19.617709]  <TASK>
> [   19.617716]  nfs_try_get_tree+0xa1/0x220
> [   19.617725]  ? get_nfs_version+0x63/0x130
> [   19.617736]  vfs_get_tree+0x1d/0x90
> [   19.617746]  ? capable+0x2f/0x50
> [   19.617755]  path_mount+0x75c/0xb00
> [   19.617766]  __x64_sys_mount+0x19a/0x200
> [   19.617775]  do_syscall_64+0x35/0x80
> [   19.617785]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
> [   19.617796] RIP: 0033:0x7ff7941ac6ea
> [   19.617805] Code: 48 8b 0d a9 17 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 17 0d 00 f7 d8 64 89 01 48
> [   19.617832] RSP: 002b:00007ffd02ae4ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> [   19.617846] RAX: ffffffffffffffda RBX: 00007ffd02ae4e70 RCX: 00007ff7941ac6ea
> [   19.617858] RDX: 0000564a1a73fb60 RSI: 0000564a1a73fb80 RDI: 0000564a1a741890
> [   19.617870] RBP: 00007ff793dd67b8 R08: 0000564a1a73f480 R09: 0000564a1a73f480
> [   19.617882] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> [   19.617894] R13: 00007ffd02ae4dd0 R14: 0000564a1a7474e0 R15: 0000564a1a7436b0
> [   19.617907]  </TASK>
> [   19.617913] irq event stamp: 8757
> [   19.617920] hardirqs last  enabled at (8769): [<ffffffffaa1397c2>] __up_console_sem+0x52/0x60
> [   19.617937] hardirqs last disabled at (8780): [<ffffffffaa1397a7>] __up_console_sem+0x37/0x60
> [   19.617952] softirqs last  enabled at (8180): [<ffffffffaabf547a>] sk_common_release+0x5a/0xe0
> [   19.617969] softirqs last disabled at (8178): [<ffffffffaabf5456>] sk_common_release+0x36/0xe0
> [   19.617984] ---[ end trace 0000000000000000 ]---
> 

Hmm, the blamed line in the warning is introduced by 38465f5d1af932 ("NFS:
rename nfs_fs_context pointer arg in a few functions"). Cc: the commit
author. Also Cc: Kees for authoring the patch [1] that have fixed
similar warning.

Also, does v6.0 have this warning? If so, you need to bisect in the range
of v6.0..v6.1-rc1.

Thanks.

[1]: https://lore.kernel.org/lkml/20221011065243.583650-1-keescook@chromium.org/

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

* Re: 6.1rc1: NFS memcpy warning on mount
  2022-10-17  3:58   ` Bagas Sanjaya
@ 2022-10-17  4:17     ` Kees Cook
  2022-10-17  4:20       ` Bagas Sanjaya
  0 siblings, 1 reply; 12+ messages in thread
From: Kees Cook @ 2022-10-17  4:17 UTC (permalink / raw)
  To: Bagas Sanjaya
  Cc: Dave Jones, Linux Kernel Mailing List, linux-nfs,
	linux-hardening, Trond Myklebust, Scott Mayhew, Anna Schumaker,
	Linus Torvalds

On Mon, Oct 17, 2022 at 10:58:55AM +0700, Bagas Sanjaya wrote:
> On Sun, Oct 16, 2022 at 10:58:21PM -0400, Dave Jones wrote:
> > Started getting this during mount on a 6.1rc1 kernel..
> > not sure which mount it's complaining about, but they're all v3 tcp
> > mounts on that machine.
> > 
> > [   19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
> [...]
> Hmm, the blamed line in the warning is introduced by 38465f5d1af932 ("NFS:
> rename nfs_fs_context pointer arg in a few functions"). Cc: the commit
> author. Also Cc: Kees for authoring the patch [1] that have fixed
> similar warning.

The warning is from commit 54d9469bc515 ("fortify: Add run-time WARN
for cross-field memcpy()")

> Also, does v6.0 have this warning? If so, you need to bisect in the range
> of v6.0..v6.1-rc1.

No need for bisection -- this is almost certainly a false positive (as
detailed in the above commit: we're working on purging all of these
cases from the kernel).

> [1]: https://lore.kernel.org/lkml/20221011065243.583650-1-keescook@chromium.org/

Yeah, I have a v2 of this patch, which should also fix this request.sap
issue. Sending shortly...

-- 
Kees Cook

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

* Re: 6.1rc1: NFS memcpy warning on mount
  2022-10-17  4:17     ` Kees Cook
@ 2022-10-17  4:20       ` Bagas Sanjaya
  0 siblings, 0 replies; 12+ messages in thread
From: Bagas Sanjaya @ 2022-10-17  4:20 UTC (permalink / raw)
  To: Kees Cook
  Cc: Dave Jones, Linux Kernel Mailing List, linux-nfs,
	linux-hardening, Trond Myklebust, Scott Mayhew, Anna Schumaker,
	Linus Torvalds

On 10/17/22 11:17, Kees Cook wrote:
> On Mon, Oct 17, 2022 at 10:58:55AM +0700, Bagas Sanjaya wrote:
>> On Sun, Oct 16, 2022 at 10:58:21PM -0400, Dave Jones wrote:
>>> Started getting this during mount on a 6.1rc1 kernel..
>>> not sure which mount it's complaining about, but they're all v3 tcp
>>> mounts on that machine.
>>>
>>> [   19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
>> [...]
>> Hmm, the blamed line in the warning is introduced by 38465f5d1af932 ("NFS:
>> rename nfs_fs_context pointer arg in a few functions"). Cc: the commit
>> author. Also Cc: Kees for authoring the patch [1] that have fixed
>> similar warning.
> 
> The warning is from commit 54d9469bc515 ("fortify: Add run-time WARN
> for cross-field memcpy()")
> 
>> Also, does v6.0 have this warning? If so, you need to bisect in the range
>> of v6.0..v6.1-rc1.
> 
> No need for bisection -- this is almost certainly a false positive (as
> detailed in the above commit: we're working on purging all of these
> cases from the kernel).
> 
>> [1]: https://lore.kernel.org/lkml/20221011065243.583650-1-keescook@chromium.org/
> 
> Yeah, I have a v2 of this patch, which should also fix this request.sap
> issue. Sending shortly...
> 

OK, thanks!

-- 
An old man doll... just what I always wanted! - Clara


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

* Re: 6.1rc1: NFS memcpy warning on mount
  2022-10-17  2:58 ` 6.1rc1: NFS memcpy warning on mount Dave Jones
  2022-10-17  3:58   ` Bagas Sanjaya
@ 2022-10-17  4:57   ` Kees Cook
  1 sibling, 0 replies; 12+ messages in thread
From: Kees Cook @ 2022-10-17  4:57 UTC (permalink / raw)
  To: Dave Jones, Linux Kernel Mailing List, Trond Myklebust,
	Anna Schumaker, Linus Torvalds

On Sun, Oct 16, 2022 at 10:58:21PM -0400, Dave Jones wrote:
> [   19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)

I've sent this, which should fix it:
https://lore.kernel.org/lkml/20221017043107.never.457-kees@kernel.org/

However, the -1 size tells me something has gone slightly wrong with the
runtime warning, as it _should_ be ignoring destinations with "unknown"
size -- in this case, struct sockaddr has a trailing array, which is
treated (currently) as a fake flexible array, so __builtin_object_size()
is reporting the "-1". But with the coming -fstrict-flex-arrays, this
will need fixing anyway. I will re-check the runtime warning logic...

-- 
Kees Cook

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

* Re: Linux 6.1-rc1
  2022-10-16 23:01 Linux 6.1-rc1 Linus Torvalds
  2022-10-17  1:53 ` linux-next: stats for 6.1-rc1 (was: Linux 6.1-rc1) Stephen Rothwell
  2022-10-17  2:58 ` 6.1rc1: NFS memcpy warning on mount Dave Jones
@ 2022-10-17 12:34 ` Guenter Roeck
  2022-10-17 17:39   ` Linus Torvalds
  2 siblings, 1 reply; 12+ messages in thread
From: Guenter Roeck @ 2022-10-17 12:34 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Andrew Jones, Conor Dooley,
	Atish Patra, Anup Patel, Hector Martin, Arnd Bergmann, Lee Jones,
	Yury Norov, Andy Shevchenko, Rasmus Villemoes, Guo Ren,
	Jakub Kicinski

On Sun, Oct 16, 2022 at 04:01:33PM -0700, Linus Torvalds wrote:
> You all know the drill: it's Sunday afternoon, the two weeks of merge
> window are over, and now we're supposed to start calming things down.
> 
[ ... ]

> Please get the testing started,
> 

Build results:
	total: 152 pass: 152 fail: 0
Qemu test results:
	total: 490 pass: 420 fail: 70
Failed tests:
	<all big endian mips tests>
	<all riscv tests>

---
The following patches are needed to fix the problems reported below.

Revert "net: fix cpu_max_bits_warn() usage in netif_attrmask_next{,_and}"
Revert "mfd: syscon: Remove repetition of the regmap_get_val_endian()"
RISC-V: KVM: Fix compilation without RISCV_ISA_ZICBOM
powerpc/64s: make linear_map_hash_lock a raw spinlock
powerpc/64s: make HPTE lock and native_tlbie_lock irq-safe
powerpc/64s: Add lockdep for HPTE lock
powerpc: fix reschedule bug in KUAP-unlocked user copy
powerpc/64s: Fix hash__change_memory_range preemption warning
powerpc/64s: Disable preemption in hash lazy mmu mode

---
Build failures

Building riscv:defconfig ... failed
--------------
Error log:
ERROR: modpost: "riscv_cbom_block_size" [arch/riscv/kvm/kvm.ko] undefined!

Caused by commit afd5dde9a186 ("RISC-V: KVM: Provide UAPI for Zicbom block
size"). Suggested fix is at
https://patchwork.kernel.org/project/linux-riscv/patch/20221013134217.1850349-1-ajones@ventanamicro.com/
Last time I checked (10/14) it was still under discussion.

Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Conor Dooley <conor.dooley@microchip.com>
Cc: Atish Patra <atishp@rivosinc.com>
Cc: Anup Patel <anup@brainfault.org>

================

Runtime failures / warnings

powerpc
-------

BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
caller is .__apply_to_page_range+0x734/0xa20
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-12130-g73344a3f6793 #1
Hardware name: PowerMac3,1 PPC970FX 0x3c0301 PowerMac
Call Trace:
[c0000000056075b0] [c000000001085308] .dump_stack_lvl+0xa4/0x100 (unreliable)
[c000000005607640] [c0000000010ba384] .check_preemption_disabled+0x144/0x150
[c0000000056076e0] [c000000000371464] .__apply_to_page_range+0x734/0xa20
[c000000005607820] [c00000000006e21c] .change_memory_attr+0xfc/0x160
[c0000000056078b0] [c0000000002ce778] .bpf_prog_select_runtime+0x78/0x220
[c000000005607950] [c000000000de3a68] .bpf_prepare_filter+0xa18/0xa80
[c000000005607a10] [c000000000de3b6c] .bpf_prog_create+0x9c/0x110
[c000000005607aa0] [c00000000205e0c4] .ptp_classifier_init+0x44/0x78
[c000000005607b30] [c00000000205d260] .sock_init+0xd8/0xf8
[c000000005607bb0] [c000000000010e28] .do_one_initcall+0xa8/0x528
[c000000005607ca0] [c00000000200501c] .kernel_init_freeable+0x3c8/0x478
[c000000005607d90] [c0000000000116bc] .kernel_init+0x2c/0x1c0
[c000000005607e10] [c00000000000ca3c] .ret_from_kernel_thread+0x58/0x60

Not a new problem (seen as far back as v5.15.y), but fixed by:
    "powerpc/64s: Disable preemption in hash lazy mmu mode"
    "powerpc/64s: Fix hash__change_memory_range preemption warning"
    "powerpc: fix reschedule bug in KUAP-unlocked user copy"

at:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221013151647.1857994-1-npiggin@gmail.com/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221013151647.1857994-2-npiggin@gmail.com/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221013151647.1857994-3-npiggin@gmail.com/

================================
WARNING: inconsistent lock state
6.0.0-12130-g73344a3f6793 #1 Tainted: G                 N
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
swapper/0/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
c000000002734de8 (native_tlbie_lock){+.?.}-{2:2}, at: .native_hpte_updateboltedpp+0x1a4/0x600
{IN-SOFTIRQ-W} state was registered at:
  .lock_acquire+0x20c/0x520
  ._raw_spin_lock+0x4c/0x70
  .native_hpte_invalidate+0x62c/0x840

Fixed by:
    "powerpc/64s: Add lockdep for HPTE lock"
    "powerpc/64s: make HPTE lock and native_tlbie_lock irq-safe"
    "powerpc/64s: make linear_map_hash_lock a raw spinlock:

at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221013230710.1987253-1-npiggin@gmail.com/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221013230710.1987253-2-npiggin@gmail.com/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221013230710.1987253-3-npiggin@gmail.com/

mips, sparc64
-------------

All big endian mips tests fail to reset after boot. The problem is
caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
regmap_get_val_endian()").

Cc: Hector Martin <marcan@marcan.st>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Lee Jones <lee.jones@linaro.org>

---
The riscv build failure is hiding a new runtime warning, seen with
32-bit and 64-bit riscv boot tests after the fix for the build problem
was applied.

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:110 __netif_set_xps_queue+0x194/0x976
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-12199-g277163563de8 #1
Hardware name: riscv-virtio,qemu (DT)
epc : __netif_set_xps_queue+0x194/0x976
ra : __netif_set_xps_queue+0x3b0/0x976
epc : c089a664 ra : c089a880 sp : c2515c60
gp : c1d8e760 tp : c2578040 t0 : c364f980
t1 : 00000000 t2 : 00001fff s0 : c2515cd0
s1 : c2515ce4 a0 : c364f940 a1 : 00000000
a2 : c364f940 a3 : 00000000 a4 : c364f950
a5 : c364f890 a6 : 00000003 a7 : 00000000
s2 : 00000001 s3 : c1d382c0 s4 : 00000000
s5 : 00000000 s6 : 00000000 s7 : c364f880
s8 : 00000000 s9 : 00000001 s10: 00000001
s11: 00000000 t3 : 00000018 t4 : 7fd38a0e
t5 : 00000007 t6 : c3639470
status: 00000120 badaddr: 00000000 cause: 00000003
[<c074548a>] virtnet_set_affinity+0x13a/0x1a2
[<c07478de>] virtnet_probe+0x884/0xfdc
[<c063ce9a>] virtio_dev_probe+0x1d6/0x354
[<c0683d6e>] really_probe+0x82/0x214
[<c0683f58>] __driver_probe_device+0x58/0xa2
[<c0683fd2>] driver_probe_device+0x30/0xaa
[<c0684596>] __driver_attach+0x56/0x11c
[<c0681f26>] bus_for_each_dev+0x52/0x90
[<c06837c0>] driver_attach+0x1a/0x22
[<c068331a>] bus_add_driver+0x148/0x1b6
[<c0684d70>] driver_register+0x52/0xea
[<c063c924>] register_virtio_driver+0x1a/0x28
[<c0c2428e>] virtio_net_driver_init+0x7a/0xa6
[<c0002824>] do_one_initcall+0x5e/0x2e2
[<c0c01130>] kernel_init_freeable+0x298/0x306
[<c0aa0ac2>] kernel_init+0x1e/0x10e
[<c0003ad8>] ret_from_exception+0x0/0x10
irq event stamp: 106012
hardirqs last  enabled at (106011): [<c0aa9284>] _raw_spin_unlock_irqrestore+0x54/0x62
hardirqs last disabled at (106012): [<c0007534>] __trace_hardirqs_off+0xc/0x14
softirqs last  enabled at (105764): [<c0886392>] napi_get_frags_check+0x0/0x50
softirqs last disabled at (105758): [<c0886392>] napi_get_frags_check+0x0/0x50
---[ end trace 0000000000000000 ]---

This is is caused (triggered ? exposed ?) by commit 854701ba4c39
("net: fix cpu_max_bits_warn() usage in netif_attrmask_next{,_and}").

A revert for this patch is at:

https://lore.kernel.org/netdev/166582921612.1299.769135677399153914.git-patchwork-notify@kernel.org/T/#m0111a76380626b2f91e072ecdd5827578d5cbf60

This revert has been applied to the net tree.

Cc: Yury Norov <yury.norov@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Guo Ren <guoren@linux.alibaba.com>
Cc: Jakub Kicinski <kuba@kernel.org>

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

* Re: Linux 6.1-rc1
  2022-10-17 12:34 ` Linux 6.1-rc1 Guenter Roeck
@ 2022-10-17 17:39   ` Linus Torvalds
  2022-10-17 18:28     ` Guenter Roeck
  2022-10-18  0:03     ` Jason A. Donenfeld
  0 siblings, 2 replies; 12+ messages in thread
From: Linus Torvalds @ 2022-10-17 17:39 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Linux Kernel Mailing List, Andrew Jones, Conor Dooley,
	Atish Patra, Anup Patel, Hector Martin, Arnd Bergmann, Lee Jones,
	Yury Norov, Andy Shevchenko, Rasmus Villemoes, Guo Ren,
	Jakub Kicinski

On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Build results:
>         total: 152 pass: 152 fail: 0
> Qemu test results:
>         total: 490 pass: 420 fail: 70

Strange. You claim zero build failures, but then:

> Build failures
>
> Building riscv:defconfig ... failed

so I think your stats may be wrong somehow ;)

> mips, sparc64
> -------------
>
> All big endian mips tests fail to reset after boot. The problem is
> caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
> regmap_get_val_endian()").

Bah. I had already archived that whole thread as "sorted out", but
yeah, the revert clearly never made it to me for rc1.

But it should be in the regmap queue (Lee/Andy?), so it is hopefully
just a temporary thing.

In fact, it looks like all the failures have known fixes. So here's
hoping that your list will be a whole lot cleaner by rc2.

Knock wood.

Thanks,
           Linus

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

* Re: Linux 6.1-rc1
  2022-10-17 17:39   ` Linus Torvalds
@ 2022-10-17 18:28     ` Guenter Roeck
  2022-10-17 18:54       ` Conor Dooley
  2022-10-18  0:03     ` Jason A. Donenfeld
  1 sibling, 1 reply; 12+ messages in thread
From: Guenter Roeck @ 2022-10-17 18:28 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Andrew Jones, Conor Dooley,
	Atish Patra, Anup Patel, Hector Martin, Arnd Bergmann, Lee Jones,
	Yury Norov, Andy Shevchenko, Rasmus Villemoes, Guo Ren,
	Jakub Kicinski

On 10/17/22 10:39, Linus Torvalds wrote:
> On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> Build results:
>>          total: 152 pass: 152 fail: 0
>> Qemu test results:
>>          total: 490 pass: 420 fail: 70
> 
> Strange. You claim zero build failures, but then:
> 
>> Build failures
>>
>> Building riscv:defconfig ... failed
> 
> so I think your stats may be wrong somehow ;)
> 

Puzzled ... the logs show that the builds for riscv[32/64] succeeded
with no error, but a manual build test still shows the failure.

Ah .... the build fails with gcc 11.3.0 / binutils 2.38, but passes
with gcc 11.3.0 / binutils 2.39. I had switched my builders to the
latter last night to fix a problem with powerpc builds. At the same time,
the manual test I just ran still used binutils 2.38.

That is interesting; I didn't expect that the binutils version would
make a difference, but apparently it does. Comparing defconfig:

10c10
< CONFIG_AS_VERSION=23900
---
 > CONFIG_AS_VERSION=23800
12c12
< CONFIG_LD_VERSION=23900
---
 > CONFIG_LD_VERSION=23800
260d259
< CONFIG_RISCV_DMA_NONCOHERENT=y
297,298d295
< CONFIG_CC_HAS_ZICBOM=y
< CONFIG_RISCV_ISA_ZICBOM=y
4134,4137d4130
< CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
< CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
< CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
< CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
4140,4142d4132
< CONFIG_DMA_NONCOHERENT_MMAP=y
< CONFIG_DMA_COHERENT_POOL=y
< CONFIG_DMA_DIRECT_REMAP=y

The build failure is only seen with CONFIG_RISCV_ISA_ZICBOM=n,
or in other words with binutils 2.38 or earlier.

>> mips, sparc64
>> -------------
>>
>> All big endian mips tests fail to reset after boot. The problem is
>> caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
>> regmap_get_val_endian()").
> 
> Bah. I had already archived that whole thread as "sorted out", but
> yeah, the revert clearly never made it to me for rc1.
> 

Yes, I saw a note along that line. The original reboot failure affected
sparc64 boot tests as well, which is gone now. Maybe some other fix for
the mips problem is in the works ?

> But it should be in the regmap queue (Lee/Andy?), so it is hopefully
> just a temporary thing.
> 
> In fact, it looks like all the failures have known fixes. So here's
> hoping that your list will be a whole lot cleaner by rc2.
> 
Hopefully yes.

Thanks,
Guenter


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

* Re: Linux 6.1-rc1
  2022-10-17 18:28     ` Guenter Roeck
@ 2022-10-17 18:54       ` Conor Dooley
  0 siblings, 0 replies; 12+ messages in thread
From: Conor Dooley @ 2022-10-17 18:54 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Linus Torvalds, Linux Kernel Mailing List, Andrew Jones,
	Conor Dooley, Atish Patra, Anup Patel, Hector Martin,
	Arnd Bergmann, Lee Jones, Yury Norov, Andy Shevchenko,
	Rasmus Villemoes, Guo Ren, Jakub Kicinski, palmer

On Mon, Oct 17, 2022 at 11:28:53AM -0700, Guenter Roeck wrote:
> On 10/17/22 10:39, Linus Torvalds wrote:
> > On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > > 
> > > Build results:
> > >          total: 152 pass: 152 fail: 0
> > > Qemu test results:
> > >          total: 490 pass: 420 fail: 70
> > 
> > Strange. You claim zero build failures, but then:
> > 
> > > Build failures
> > > 
> > > Building riscv:defconfig ... failed
> > 
> > so I think your stats may be wrong somehow ;)
> > 
> 
> Puzzled ... the logs show that the builds for riscv[32/64] succeeded
> with no error, but a manual build test still shows the failure.
> 
> Ah .... the build fails with gcc 11.3.0 / binutils 2.38, but passes
> with gcc 11.3.0 / binutils 2.39. I had switched my builders to the
> latter last night to fix a problem with powerpc builds. At the same time,
> the manual test I just ran still used binutils 2.38.
> 
> That is interesting; I didn't expect that the binutils version would
> make a difference, but apparently it does. Comparing defconfig:
> 
> 10c10
> < CONFIG_AS_VERSION=23900
> ---
> > CONFIG_AS_VERSION=23800
> 12c12
> < CONFIG_LD_VERSION=23900
> ---
> > CONFIG_LD_VERSION=23800
> 260d259
> < CONFIG_RISCV_DMA_NONCOHERENT=y
> 297,298d295
> < CONFIG_CC_HAS_ZICBOM=y
> < CONFIG_RISCV_ISA_ZICBOM=y
> 4134,4137d4130
> < CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
> < CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
> < CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
> < CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
> 4140,4142d4132
> < CONFIG_DMA_NONCOHERENT_MMAP=y
> < CONFIG_DMA_COHERENT_POOL=y
> < CONFIG_DMA_DIRECT_REMAP=y
> 
> The build failure is only seen with CONFIG_RISCV_ISA_ZICBOM=n,
> or in other words with binutils 2.38 or earlier.

+CC Palmer since he's the maintainer of the code being changed by the
fix.

The Zicbom extension only got support in binutils 2.39, so it's
automatically disabled for your older binutils, along with non-coherent
DMA support. As pointed out, we've already got a reviewed fix for it, so
hopefully that lands soon.

Kinda surprised this didn't trigger complaints from more than just you
and an LKP report, but it may be that having some other options selected
hides the problem.

Palmer, the fix is here if you get a chance to look at it:
https://lore.kernel.org/all/20221013134217.1850349-1-ajones@ventanamicro.com/

Thanks,
Conor.


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

* Re: Linux 6.1-rc1
  2022-10-17 17:39   ` Linus Torvalds
  2022-10-17 18:28     ` Guenter Roeck
@ 2022-10-18  0:03     ` Jason A. Donenfeld
  1 sibling, 0 replies; 12+ messages in thread
From: Jason A. Donenfeld @ 2022-10-18  0:03 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Linux Kernel Mailing List, Andrew Jones,
	Conor Dooley, Atish Patra, Anup Patel, Hector Martin,
	Arnd Bergmann, Lee Jones, Yury Norov, Andy Shevchenko,
	Rasmus Villemoes, Guo Ren, Jakub Kicinski

On Mon, Oct 17, 2022 at 10:39:08AM -0700, Linus Torvalds wrote:
> On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Build results:
> >         total: 152 pass: 152 fail: 0
> > Qemu test results:
> >         total: 490 pass: 420 fail: 70
> 
> Strange. You claim zero build failures, but then:
> 
> > Build failures
> >
> > Building riscv:defconfig ... failed
> 
> so I think your stats may be wrong somehow ;)
> 
> > mips, sparc64
> > -------------
> >
> > All big endian mips tests fail to reset after boot. The problem is
> > caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
> > regmap_get_val_endian()").
> 
> Bah. I had already archived that whole thread as "sorted out", but
> yeah, the revert clearly never made it to me for rc1.
> 
> But it should be in the regmap queue (Lee/Andy?), so it is hopefully
> just a temporary thing.
> 
> In fact, it looks like all the failures have known fixes. So here's
> hoping that your list will be a whole lot cleaner by rc2.
> 
> Knock wood.

I emailed Lee about it 3 days ago, hoping it'd make rc1 too, but never
heard back. Maybe vacation? Dunno.

Jason

> 
> Thanks,
>            Linus

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

end of thread, other threads:[~2022-10-18  0:03 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-16 23:01 Linux 6.1-rc1 Linus Torvalds
2022-10-17  1:53 ` linux-next: stats for 6.1-rc1 (was: Linux 6.1-rc1) Stephen Rothwell
2022-10-17  2:58 ` 6.1rc1: NFS memcpy warning on mount Dave Jones
2022-10-17  3:58   ` Bagas Sanjaya
2022-10-17  4:17     ` Kees Cook
2022-10-17  4:20       ` Bagas Sanjaya
2022-10-17  4:57   ` Kees Cook
2022-10-17 12:34 ` Linux 6.1-rc1 Guenter Roeck
2022-10-17 17:39   ` Linus Torvalds
2022-10-17 18:28     ` Guenter Roeck
2022-10-17 18:54       ` Conor Dooley
2022-10-18  0:03     ` Jason A. Donenfeld

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).