Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Guenter Roeck <groeck7@gmail.com>
Date:   Mon, 28 Dec 2020 07:51:49 -0800
From:   Guenter Roeck <linux@roeck-us.net>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 5.11-rc1
Message-ID: <20201228155149.GA197954@roeck-us.net>
References: <CAHk-=wg1+kf1AVzXA-RQX0zjM6t9J2Kay9xyuNqcFHWV-y5ZYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wg1+kf1AVzXA-RQX0zjM6t9J2Kay9xyuNqcFHWV-y5ZYw@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Sun, Dec 27, 2020 at 04:04:11PM -0800, Linus Torvalds wrote:
> Two weeks have passed, Christmas is over, and so is the merge window.
> 
> I want to thank all the maintainers who sent in their pull requests
> early: we all wanted to get things done before the holidays really
> hit, and mostly it seemed to work quite well.
> 
> In fact, it was rather nice to handle the big bulk of all the merge
> window pull requests in the first three or four days of the merge
> window.  I wouldn't want to do it that way every time - it would
> stress me out - but as an occasional "let's get it over with so that
> the second week is calm" it really wasn't bad at all.
> 
> It probably helped that 5.11 isn't going to be an LTS release and
> isn't as big as 5.10 was, but it's not small either. Solidly average.
> 
> Well, it's average, unless you look at the actual diffs, and notice
> another huge dump of AMD GPU descriptor header files, which completely
> dwarfs all the "real" changes here. The AMD "Van Gogh" include file
> additions are in fact about two thirds of the whole patch, even if it
> comes from basically one single commit that just adds the register
> definitions. We've had it before, I'm sure we'll see it in the future
> too: header files probably generated from the hardware description for
> all the possible bit masks etc get very very big.
> 
> Oh well. If you ignore that area, everything else looks normal. Driver
> updates dominate, but all the usual other suspects are there: arch
> updates, filesystems, networking, docs and tooling.
> 
> And while it doesn't look like a huge release, it's certainly still
> big enough that what's appended below is just my "merge log". As
> always, my merge logs credit only the people I pull from, which is a
> much smaller set than all the people involved in actually writing the
> patches. As usual we had more than 1500 actual developers, and roughly
> 12,500 changes merged. That's pretty much our average these days.
> 
> Please go kick the tires,
> 

Build results:
	total: 153 pass: 151 fail: 2
Failed builds:
	arm64:allmodconfig
	ia64:defconfig
Qemu test results:
	total: 430 pass: 412 fail: 18
Failed tests:
	arm:raspi2:multi_v7_defconfig:bcm2836-rpi-2-b:initrd
	arm:raspi2:multi_v7_defconfig:sd:bcm2836-rpi-2-b:rootfs
	<all parisc>

Build errors:

arm64:allmodconfig:

ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] undefined!

Caused by: fdd029630434 ("genirq: Move status flag checks to core")

ia64:defconfig:

include/linux/mmzone.h:1156:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE

and various related warnings.

Caused by: 214496cb1870 ("ia64: make SPARSEMEM default and disable DISCONTIGMEM")

Fix submitted ("ia64: fix build failure caused by memory model changes").

qemu boot tests:

arm:raspi2:

Hangs during boot.

Caused by: ffdad793d579 ("irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq()")

Fix submitted ("irqchip/bcm2836: Fix IPI acknowledgement after conversion to
handle_percpu_devid_irq").

parisc:

Failed to execute /sbin/init (error -12)

Caused by: c49dd3401802 ("mm: speedup mremap on 1GB or larger regions")

More details are in responses to the offending patches.

Guenter