linux-kernel - Re: Linux 5.12-rc7

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210412051445.GA47322@roeck-us.net>
Date:   Sun, 11 Apr 2021 22:14:45 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: Linux 5.12-rc7

On Sun, Apr 11, 2021 at 03:41:18PM -0700, Linus Torvalds wrote:
> Oh well. rc5 was big. rc6 was small. And now rc7 is big again. In
> fact, it's the biggest rc7 (at least in number of commits) we've had
> in the 5.x series.
> 
> It's mostly due to networking fixes (of which rc6 had none), and none
> of them should be all that scary, but it's never great when we have
> such a big rc. It's particularly annoying at the end of the release
> window like this.
> 
> End result: I'm still waffling about the final 5.12 release.  The fact
> that we have a big rc7 does make me think that I'll probably do an rc8
> this time around. But it ends up depending a bit on how the upcoming
> week goes, and if things are deathly quiet, I may end up deciding that
> an rc8 doesn't really make sense.
> 
> So we'll see.
> 
> Anyway, networking (both core and drivers) is over half of the rc7
> patch, with the rest being a fairly random collection of fixes all
> over. We've got other driver updates (sound, rdma, scsi, usb..) some
> fs fixes (io_uring, umount, btrfs, cifs, ocfs), minor arch fixes (arc,
> arm, parisc, powerpc, s390, x86), and other misc fixes.
> 
> The shortlog is appended, although it's obviously not as nice and
> small and readable as I'd have liked at this point in the release..
> 
> Please do test,
> 

Build results:
	total: 151 pass: 151 fail: 0
Qemu test results:
	total: 460 pass: 459 fail: 1
Failed tests:
	sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs

The failure bisects to commit 0f6925b3e8da ("virtio_net: Do not pull payload in
skb->head"). It is a spurious problem - the test passes roughly every other
time. When the failure is seen, udhcpc fails to get an IP address and aborts
with SIGTERM. So far I have only seen this with the "sh" architecture.

Guenter