So two weeks have passed, and the merge window for 4.19 is over.
This was a fairly frustrating merge window, partly because 4.19 looks
to be a pretty big release (no single reason), and partly just due to
random noise. We had the L1TF hw vulnerability disclosure early in the
merge window, which just added the usual frustration due to having
patches that weren't public. That just shows just how good all our
infrastructure for linux-next and various automated testing systems
have become, in how painful it is when it's lacking.
At least we didn't actually have a lot of problems on that front in
the mainline kernel, there seemed to be many more pain points in the
backports.
We also had a report of a TLB shootdown bug come in during this merge
window, and while the patches for ended up not being a huge problem,
TLB invalidation issues is actually one of the things that stresses me
out. They're really nasty to debug (thanks to Jann Horn for
pinpointing this one), and our interfaces to the architecture specific
routines are subtle and pretty complicated. And messy. I think the
discussion will result in a few cleanups later, but timing could have
been so much better for this.
Oh well. I guess I can partly just blame myself for having delayed
4.18 by a week, which just made everything happen during that first
and busiest week of the merge window. Bad luck. Although even the
second week - when things usually calm down - was also pretty busy
this time around.
Anyway, on to the actual changes. And there' a lot of them. There's
just a lot of things going on, and while this isn't the biggest
release we've had (4.9 still keeps that crown), this does join 4.12
and 4.15 as one of the bigger kernel releases, at least just judging
by number of commits in the merge window.
As usual, there's way too many patches to list even in shortlog
format, but appended is my usual "mergelog" of people I merged from
and a one-liner overview of the merge. There's actually a couple of
pull requests that I might still look at after the merge window, but
that are probably in the "there's always the next one" pile.
The "big picture" of the merge window looks pretty normal: just under
two thirds of the changes are to drivers (gpu and network drivers
being the bulk - as usual), with the rest being architecture updates
(all the usual suspects), filesystems, core kernel and networking.
There's a fair chunk of documentation and tooling updates too
(selftests, tracing, perf..).
Anyway, go forth and test,
Linus
---
Al Viro (5):
vfs open-related updates
vfs icache updates
vfs lookup() updates
vfs aio updates
misc vfs updates
Alex Williamson (1):
VFIO updates
Alexandre Belloni (1):
RTC updates
Andreas Gruenbacher (1):
gfs2 updates
Andrew Morton (3):
updates
more updates
yet more updates
Andy Shevchenko (1):
x86 platform driver updates
Anna Schumaker (1):
NFS client updates
Bartlomiej Zolnierkiewicz (1):
fbdev updates
Benson Leung (1):
chrome platform updates
Bjorn Andersson (3):
remoteproc updates
rpmsg updates
hwspinlock updates
Bjorn Helgaas (1):
pci updates
Boris Brezillon (1):
mtd updates
Borislav Petkov (2):
EDAC updates
EDAC fix
Bruce Fields (1):
nfsd updates
Christoph Hellwig (2):
dma-mapping updates
configfs updates
Darrick Wong (3):
fs iomap refactoring
xfs updates
xfs fixes
Dave Airlie (4):
drm updates
drm fixes
drm msm support for adreno a6xx
drm fixes
Dave Jiang (2):
libnvdimm updates
libnvdimm memory-failure update
David Kleikamp (1):
jfs update
David Miller (4):
networking updates
networking fixes
sparc updates
IDE updates
David Sterba (1):
btrfs updates
Dmitry Torokhov (1):
input updates
Dominique Martinet (1):
9p updates
Eduardo Valentin (1):
thermal management updates
Eric Biederman (2):
core signal handling updates
namespace fixes
Geert Uytterhoeven (1):
m68k updates
Greg KH (6):
USB/PHY updates
tty/serial driver updates
staging and IIO updates
char/misc driver updates
driver core updates
UIO fix
Greg Ungerer (1):
m68knommu updates
Guenter Roeck (1):
hwmon updates
Heiko Carstens (1):
s390 updates
Helge Deller (2):
parisc updates
more parisc updates
Herbert Xu (1):
crypto updates
Ilya Dryomov (1):
ceph updates
Jacek Anaszewski (1):
LED updates
Jaegeuk Kim (1):
f2fs updates
James Bottomley (1):
SCSI updates
James Morris (4):
security subsystem updates
smack updates
TPM updates
integrity updates
Jan Kara (2):
UDF and ext2 update
fsnotify updates
Jason Gunthorpe (2):
rdma updates
more rdma updates
Jassi Brar (1):
mailbox updates
Jeff Layton (1):
file locking updates
Jens Axboe (3):
block updates
more block updates
block fixes
Jessica Yu (1):
modules updates
Jiri Kosina (2):
HID updates
livepatching updates
Joerg Roedel (1):
IOMMU updates
John Johansen (1):
apparmor updates
Jonathan Corbet (1):
documentation update
Juergen Gross (2):
xen updates
xen fixes and cleanups
Kees Cook (5):
hardened usercopy updates
pstore update
gcc plugin cleanups
VLA removal leftovers
gcc plugin fix
Lee Jones (2):
MFD updates
backlight updates
Linus Walleij (2):
pin control updates
GPIO updates
Mark Brown (3):
regmap updates
spi updates
regulator updates
Martin Schwidefsky (1):
s390 updates
Masahiro Yamada (4):
Kbuild updates
Kconfig updates
Kconfig consolidation
more Kbuild updates
Matthew Wilcox (1):
IDA updates
Mauro Carvalho Chehab (1):
media updates
Max Filippov (1):
Xtensa updates
Michael Ellerman (2):
powerpc updates
powerpc fixes
Michael Tsirkin (1):
virtio updates
Michal Simek (1):
arch/microblaze updates
Miguel Ojeda (2):
auxdisplay updates
clang-format updates
Mike Marshall (1):
orangefs updates
Mike Snitzer (1):
device mapper updates
Miklos Szeredi (2):
overlayfs updates
fuse update
Olof Johansson (5):
ARM 32-bit SoC platform updates
ARM SoC driver updates
ARM SoC defconfig updates
ARM device-tree updates
ARM SoC late updates
Palmer Dabbelt (2):
RISC-V updates
RISC-V fixes
Paolo Bonzini (2):
first set of KVM updates
second set of KVM updates
Paul Burton (2):
MIPS updates
MIPS fixes
Paul Moore (2):
SELinux updates
audit patches
Petr Mladek (1):
printk updates
Rafael Wysocki (5):
power management updates
ACPI updates
more power management updates
more ACPI updates
ACPI Kconfig fix
Richard Weinberger (2):
UBI/UBIFS updates
UBIFS fix
Rob Herring (1):
Devicetree updates
Russell King (2):
ARM updates
ARM clkdev updates
Sebastian Reichel (1):
power supply and reset updates
Shaohua Li (1):
MD updates
Shuah Khan (1):
Kselftest update
Stafford Horne (1):
OpenRISC update
Stephen Boyd (1):
clk updates
Steve French (2):
cifs updates
cifs fixes
Steven Rostedt (2):
tracing updates
tracing fixes
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (2):
ext4 updates
random updates
Tejun Heo (3):
workqueue updates
cgroup updates
libata updates
Thierry Reding (1):
pwm updates
Thomas Gleixner (32):
debugobjects update
EFI updates
genirq updates
RCU updates
x86 RAS updates
scheduler fix
scheduler updates
CPU hotplug update
locking/atomics update
perf update
timer updates
x86 apic update
x86 boot updates
x86 asm updates
x86 build cleanup
x86 cleanups
x86 cpu updates
x86 dump printing cleanup
x86/hyper-v update
x86 cache QoS (RDT/CAR) updates
x86 platform updates
x86 mm updates
misc x86 fixes
x86 vdso update
x86 PTI updates
x86 timer updates
L1 Terminal Fault fixes
licking update
irq update
x86 fixes
perf updates
timer update
Tony Luck (1):
ia64 NO_BOOTMEM conversion
Ulf Hansson (1):
MMC updates
Vinod Koul (1):
DMAengine updates
Will Deacon (2):
arm64 updates
arm64 fixes
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (2):
i2c updates
second i2c update
Yoshinori Sato (1):
arch/h8300 updates
Zhang Rui (1):
thermal management updates
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20180813 was the first linux-next after
the merge window opened.)
Commits in v4.19-rc1 (relative to v4.18): 12317
Commits in next-20180813: 11958
Commits with the same SHA1: 10973
Commits with the same patch_id: 526 (1)
Commits with the same subject line: 64 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20180813: 11563 93%
Some breakdown of the list of extra commits (relative to next-20180813)
in -rc1:
Top ten first word of commit summary:
81 x86
70 perf
52 net
40 drm
32 powerpc
30 tools
22 ib
18 ubifs
14 s390
14 kvm
Top ten authors:
37 [email protected]
26 [email protected]
24 [email protected]
21 [email protected]
19 [email protected]
17 [email protected]
16 [email protected]
16 [email protected]
13 [email protected]
10 [email protected]
Top ten commiters:
100 [email protected]
81 [email protected]
80 [email protected]
38 [email protected]
37 [email protected]
29 [email protected]
27 [email protected]
24 [email protected]
22 [email protected]
22 [email protected]
There are also 395 commits in next-20180813 that didn't make it into
v4.19-rc1.
Top ten first word of commit summary:
34 mm
26 vfs
22 arm
21 coresight
18 leaking_addresses
17 xarray
15 page
12 btrfs
12 arm64
11 nfc
Top ten authors:
76 [email protected]
37 [email protected]
25 [email protected]
22 [email protected]
18 [email protected]
13 [email protected]
11 [email protected]
9 [email protected]
7 [email protected]
7 [email protected]
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
90 [email protected]
76 [email protected]
39 [email protected]
23 [email protected]
18 [email protected]
14 [email protected]
14 [email protected]
14 [email protected]
13 [email protected]
12 [email protected]
Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).
--
Cheers,
Stephen Rothwell
On Sun, Aug 26, 2018 at 02:49:14PM -0700, Linus Torvalds wrote:
> So two weeks have passed, and the merge window for 4.19 is over.
>
[ ... ]
>
> Anyway, go forth and test,
>
Build results:
total: 132 pass: 129 fail: 3
Failed builds:
riscv:defconfig
riscv:allnoconfig
sparc32:allmodconfig
Qemu test results:
total: 299 pass: 297 fail: 2
Failed tests:
riscv:virt:defconfig:initrd
riscv:virt:defconfig:virtio-blk:rootfs
---
riscv:
In file included from arch/riscv/include/asm/tlb.h:17:0,
from arch/riscv/include/asm/pgalloc.h:19,
from arch/riscv/mm/fault.c:30:
include/asm-generic/tlb.h: In function 'tlb_flush_mmu_tlbonly':
include/asm-generic/tlb.h:147:2: error: implicit declaration of function 'tlb_flush'
Known problem, patch submitted.
---
sparc32:allmodconfig:
arch/sparc/kernel/head_32.o: In function `current_pc':
arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5040): relocation truncated to fit: R_SPARC_WDISP22 against `.init.text'
arch/sparc/kernel/head_32.o: In function `halt_notsup':
arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5100): relocation truncated to fit: R_SPARC_WDISP22 against `.init.text'
arch/sparc/kernel/head_32.o: In function `leon_init':
arch/sparc/kernel/.tmp_head_32.o:(.init.text+0xa4): relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section
in arch/sparc/kernel/trampoline_32.o
arch/sparc/kernel/process_32.o:(.fixup+0x4): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/process_32.o:(.fixup+0xc): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x0): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x8): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x10): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x18): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x20): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x28): additional relocation overflows omitted from the output
For the most part this is due to calls / short jumps between .head.text,
.text, and .init.text. Probably old, now seen because the image is now
too large.
---
On top of that, there are various runtime warnings.
sh:
WARNING: CPU: 0 PID: 932 at mm/slab.c:2666 cache_alloc_refill+0x8a/0x594
Known problem. Fix was under discussion. I don't know if it was accepted.
https://marc.info/?t=153301426900002&r=1&w=2
https://www.spinics.net/lists/linux-sh/msg53298.html
---
sparc:
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 esp_sbus_probe+0x408/0x6e8
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 sparc_lance_probe_one+0x428/0x4f
Missing initialization of coherent_dma_mask in the respective drivers.
---
Each platform driver instantiated through a devicetree node now generates
the following warning:
esp ffd38e00: DMA mask not set
It isn't a traceback so it may fly under the radar. There is nothing the
drivers can do about it; the message is generated by the core before the
driver probe function is called. No idea what a correct fix might be.
Guenter
> sparc:
>
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 esp_sbus_probe+0x408/0x6e8
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 sparc_lance_probe_one+0x428/0x4f
>
> Missing initialization of coherent_dma_mask in the respective drivers.
>
> ---
> Each platform driver instantiated through a devicetree node now generates
> the following warning:
>
> esp ffd38e00: DMA mask not set
>
> It isn't a traceback so it may fly under the radar. There is nothing the
> drivers can do about it; the message is generated by the core before the
> driver probe function is called. No idea what a correct fix might be.
Both of these should probably be fixed by something like the patch
below:
---
From 6294e0e330851ee06e66ab85b348f1d92d375d7a Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <[email protected]>
Date: Mon, 27 Aug 2018 17:23:24 +0200
Subject: driver core: initialize a default DMA mask for platform device
We still treat devices without a DMA mask as defaulting to 32-bits for
both mask, but a few releases ago we've started warning about such
cases, as they require special cases to work around this sloppyness.
Add a dma_mask field to struct platform_object so that we can initialize
the dma_mask pointer in struct device and initialize both masks to
32-bits by default. Architectures can still override this in
arch_setup_pdev_archdata if needed.
Note that the code looks a little odd with the various conditionals
because we have to support platform_device structures that are
statically allocated.
Signed-off-by: Christoph Hellwig <[email protected]>
---
drivers/base/platform.c | 15 +++++++++++++--
include/linux/platform_device.h | 1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index dff82a3c2caa..baf4b06cf2d9 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -225,6 +225,17 @@ struct platform_object {
char name[];
};
+static void setup_pdev_archdata(struct platform_device *pdev)
+{
+ if (!pdev->dev.coherent_dma_mask)
+ pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!pdev->dma_mask)
+ pdev->dma_mask = DMA_BIT_MASK(32);
+ if (!pdev->dev.dma_mask)
+ pdev->dev.dma_mask = &pdev->dma_mask;
+ arch_setup_pdev_archdata(pdev);
+};
+
/**
* platform_device_put - destroy a platform device
* @pdev: platform device to free
@@ -271,7 +282,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
- arch_setup_pdev_archdata(&pa->pdev);
+ setup_pdev_archdata(&pa->pdev);
}
return pa ? &pa->pdev : NULL;
@@ -472,7 +483,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
int platform_device_register(struct platform_device *pdev)
{
device_initialize(&pdev->dev);
- arch_setup_pdev_archdata(pdev);
+ setup_pdev_archdata(pdev);
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 1a9f38f27f65..d84ec1de6022 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -25,6 +25,7 @@ struct platform_device {
int id;
bool id_auto;
struct device dev;
+ dma_addr_t dma_mask;
u32 num_resources;
struct resource *resource;
--
2.18.0
On Mon, Aug 27, 2018 at 08:46:41AM -0700, Christoph Hellwig wrote:
> > sparc:
> >
> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 esp_sbus_probe+0x408/0x6e8
> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 sparc_lance_probe_one+0x428/0x4f
> >
> > Missing initialization of coherent_dma_mask in the respective drivers.
> >
> > ---
> > Each platform driver instantiated through a devicetree node now generates
> > the following warning:
> >
> > esp ffd38e00: DMA mask not set
> >
> > It isn't a traceback so it may fly under the radar. There is nothing the
> > drivers can do about it; the message is generated by the core before the
> > driver probe function is called. No idea what a correct fix might be.
>
> Both of these should probably be fixed by something like the patch
> below:
>
> ---
> From 6294e0e330851ee06e66ab85b348f1d92d375d7a Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <[email protected]>
> Date: Mon, 27 Aug 2018 17:23:24 +0200
> Subject: driver core: initialize a default DMA mask for platform device
>
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_object so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default. Architectures can still override this in
> arch_setup_pdev_archdata if needed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> drivers/base/platform.c | 15 +++++++++++++--
> include/linux/platform_device.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index dff82a3c2caa..baf4b06cf2d9 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -225,6 +225,17 @@ struct platform_object {
> char name[];
> };
>
> +static void setup_pdev_archdata(struct platform_device *pdev)
> +{
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dma_mask)
> + pdev->dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &pdev->dma_mask;
When building sparc32 images, this results in the following
error.
drivers/base/platform.c: In function 'setup_pdev_archdata':
drivers/base/platform.c:235:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
pdev->dev.dma_mask = &pdev->dma_mask;
pdev->dev.dma_mask is u64 *, pdev->dma_mask is dma_addr_t which in turn
is either u32 or u64 depending on the architecture.
> +++ b/include/linux/platform_device.h
> @@ -25,6 +25,7 @@ struct platform_device {
> int id;
> bool id_auto;
> struct device dev;
> + dma_addr_t dma_mask;
... so this will have to be u64, or the pointer in struct device would
have to be fixed.
However, even changing the definition to u64 does not help: The warnings
are still reported. This is because setup_pdev_archdata() is not called
for any of the affected devices. That is kind of interesting since it
means that arch_setup_pdev_archdata() won't be called for those devices
either.
Guenter
On Mon, Aug 27, 2018 at 10:11:52AM -0700, Guenter Roeck wrote:
> When building sparc32 images, this results in the following
> error.
>
> drivers/base/platform.c: In function 'setup_pdev_archdata':
> drivers/base/platform.c:235:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
> pdev->dev.dma_mask = &pdev->dma_mask;
>
> pdev->dev.dma_mask is u64 *, pdev->dma_mask is dma_addr_t which in turn
> is either u32 or u64 depending on the architecture.
Yes, I've fixed this up to be a u64.
>
> > +++ b/include/linux/platform_device.h
> > @@ -25,6 +25,7 @@ struct platform_device {
> > int id;
> > bool id_auto;
> > struct device dev;
> > + dma_addr_t dma_mask;
>
> ... so this will have to be u64, or the pointer in struct device would
> have to be fixed.
>
> However, even changing the definition to u64 does not help: The warnings
> are still reported. This is because setup_pdev_archdata() is not called
> for any of the affected devices. That is kind of interesting since it
> means that arch_setup_pdev_archdata() won't be called for those devices
> either.
Yeah, this is odd. I'll need some more time to figure out where
the platform devices for sbus are allocated.
On Sun, Aug 26, 2018 at 3:51 PM Linus Torvalds
<[email protected]> wrote:
>
> So two weeks have passed, and the merge window for 4.19 is over.
>
> Anyway, go forth and test,
>
I am seeing the errors use-after-free errors in mei_cl_write. dmesg as follows.
Adding Tomas Winkler to the thread.
[ 12.602912] PM: Adding info for
mei:mei::309dcde8-ccb1-4062-8f78-600115a34327:01
[ 12.603126] ==================================================================
[ 12.603205] BUG: KASAN: use-after-free in mei_cl_write+0x481/0x860
[ 12.603248] Read of size 8 at addr ffff880416d3a320 by task kworker/2:1/68
[ 12.603311] CPU: 2 PID: 68 Comm: kworker/2:1 Tainted: G W
4.19.0-rc1 #1
[ 12.603363] Hardware name: System76, Inc. Wild Dog
Performance/H87-PLUS, BIOS 0705 12/05/2013
[ 12.603420] Workqueue: events mei_cl_bus_rescan_work
[ 12.603459] Call Trace:
[ 12.603486] dump_stack+0x7c/0xbb
[ 12.603520] print_address_description+0x73/0x280
[ 12.603560] kasan_report+0x258/0x380
[ 12.603589] ? mei_cl_write+0x481/0x860
[ 12.603625] mei_cl_write+0x481/0x860
[ 12.603664] ? mei_cl_irq_write+0x570/0x570
[ 12.603699] ? kasan_unpoison_shadow+0x30/0x40
[ 12.603735] ? kasan_kmalloc+0xa0/0xd0
[ 12.603770] ? wait_woken+0x140/0x140
[ 12.603803] ? mei_cl_alloc_cb+0xa9/0xf0
[ 12.603847] __mei_cl_send+0x371/0x3e0
[ 12.603888] ? wait_for_completion+0x1d0/0x1d0
[ 12.603923] ? mei_cldev_driver_unregister+0x40/0x40
[ 12.603961] ? find_first_zero_bit+0x19/0x70
[ 12.604014] mei_mkhi_fix+0x12d/0x480
[ 12.604045] ? worker_thread+0x69/0x690
[ 12.604075] ? kthread+0x1ae/0x1d0
[ 12.604103] ? ret_from_fork+0x3a/0x50
[ 12.604135] ? check_chain_key+0x139/0x1f0
[ 12.604173] ? mei_wd+0xa0/0xa0
[ 12.604203] ? mark_lock+0xc7/0x7c0
[ 12.604234] ? mark_lock+0xc7/0x7c0
[ 12.604285] mei_cl_bus_dev_fixup+0x196/0x1b0
[ 12.604322] ? mei_nfc+0x4d0/0x4d0
[ 12.604354] ? lockdep_hardirqs_on+0x18c/0x280
[ 12.604400] ? __kasan_slab_free+0x143/0x180
[ 12.604441] ? mei_cl_bus_rescan_work+0x2f1/0x500
[ 12.604477] mei_cl_bus_rescan_work+0x2f1/0x500
[ 12.604527] process_one_work+0x5e5/0xb00
[ 12.604573] ? wq_pool_ids_show+0x1e0/0x1e0
[ 12.604628] worker_thread+0x69/0x690
[ 12.604675] ? process_one_work+0xb00/0xb00
[ 12.604706] kthread+0x1ae/0x1d0
[ 12.604734] ? kthread_create_worker_on_cpu+0xc0/0xc0
[ 12.604776] ret_from_fork+0x3a/0x50
[ 12.604845] Allocated by task 68:
[ 12.604872] kasan_kmalloc+0xa0/0xd0
[ 12.604900] kmem_cache_alloc_trace+0x118/0x250
[ 12.604933] mei_cl_alloc_cb+0x3b/0xf0
[ 12.604962] __mei_cl_send+0x312/0x3e0
[ 12.604991] mei_mkhi_fix+0x12d/0x480
[ 12.605020] mei_cl_bus_dev_fixup+0x196/0x1b0
[ 12.605052] mei_cl_bus_rescan_work+0x2f1/0x500
[ 12.605085] process_one_work+0x5e5/0xb00
[ 12.605116] worker_thread+0x69/0x690
[ 12.605144] kthread+0x1ae/0x1d0
[ 12.605170] ret_from_fork+0x3a/0x50
[ 12.605213] Freed by task 104:
[ 12.605238] __kasan_slab_free+0x12e/0x180
[ 12.605269] kfree+0xd4/0x250
[ 12.605294] mei_cl_complete+0xc1/0x230
[ 12.605324] mei_irq_compl_handler+0x95/0xf0
[ 12.605356] mei_me_irq_thread_handler+0x7e5/0xc90
[ 12.605391] irq_thread_fn+0x3f/0x80
[ 12.605418] irq_thread+0x175/0x250
[ 12.605446] kthread+0x1ae/0x1d0
[ 12.605472] ret_from_fork+0x3a/0x50
[ 12.605515] The buggy address belongs to the object at ffff880416d3a300
which belongs to the cache kmalloc-96 of size 96
[ 12.605591] The buggy address is located 32 bytes inside of
96-byte region [ffff880416d3a300, ffff880416d3a360)
[ 12.605662] The buggy address belongs to the page:
[ 12.605697] page:ffffea00105b4e80 count:1 mapcount:0
mapping:ffff8800b580f400 index:0x0
[ 12.605753] flags: 0xa00000000000100(slab)
[ 12.605785] raw: 0a00000000000100 dead000000000100 dead000000000200
ffff8800b580f400
[ 12.605838] raw: 0000000000000000 0000000080200020 00000001ffffffff
0000000000000000
[ 12.605888] page dumped because: kasan: bad access detected
[ 12.605941] Memory state around the buggy address:
[ 12.605976] ffff880416d3a200: fb fb fb fb fb fb fb fb fb fb fb fb
fc fc fc fc
[ 12.606024] ffff880416d3a280: fb fb fb fb fb fb fb fb fb fb fb fb
fc fc fc fc
[ 12.606073] >ffff880416d3a300: fb fb fb fb fb fb fb fb fb fb fb fb
fc fc fc fc
[ 12.606121] ^
[ 12.606152] ffff880416d3a380: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[ 12.606201] ffff880416d3a400: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[ 12.606249] =================================================================
thanks,
-- Shuah
On Mon, Aug 27, 2018 at 11:13:11AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 27, 2018 at 10:11:52AM -0700, Guenter Roeck wrote:
> > When building sparc32 images, this results in the following
> > error.
> >
> > drivers/base/platform.c: In function 'setup_pdev_archdata':
> > drivers/base/platform.c:235:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
> > pdev->dev.dma_mask = &pdev->dma_mask;
> >
> > pdev->dev.dma_mask is u64 *, pdev->dma_mask is dma_addr_t which in turn
> > is either u32 or u64 depending on the architecture.
>
> Yes, I've fixed this up to be a u64.
>
> >
> > > +++ b/include/linux/platform_device.h
> > > @@ -25,6 +25,7 @@ struct platform_device {
> > > int id;
> > > bool id_auto;
> > > struct device dev;
> > > + dma_addr_t dma_mask;
> >
> > ... so this will have to be u64, or the pointer in struct device would
> > have to be fixed.
> >
> > However, even changing the definition to u64 does not help: The warnings
> > are still reported. This is because setup_pdev_archdata() is not called
> > for any of the affected devices. That is kind of interesting since it
> > means that arch_setup_pdev_archdata() won't be called for those devices
> > either.
>
> Yeah, this is odd. I'll need some more time to figure out where
> the platform devices for sbus are allocated.
I think it is scan_one_device() in arch/sparc/kernel/of_device_32.c
and arch/sparc/kernel/of_device_64.c.
Guenter
>
> On Sun, Aug 26, 2018 at 3:51 PM Linus Torvalds <torvalds@linux-
> foundation.org> wrote:
> >
> > So two weeks have passed, and the merge window for 4.19 is over.
> >
>
>
> > Anyway, go forth and test,
> >
>
> I am seeing the errors use-after-free errors in mei_cl_write. dmesg as follows.
> Adding Tomas Winkler to the thread.
>
https://lkml.org/lkml/2018/8/23/83
Thanks for the report, the fix was already sent out a week ago, hope it will make it into 4.19-rc2
Thanks
Tomas
> [ 12.602912] PM: Adding info for
> mei:mei::309dcde8-ccb1-4062-8f78-600115a34327:01
> [ 12.603126]
> ================================================================
> ==
> [ 12.603205] BUG: KASAN: use-after-free in mei_cl_write+0x481/0x860
> [ 12.603248] Read of size 8 at addr ffff880416d3a320 by task kworker/2:1/68
>
> [ 12.603311] CPU: 2 PID: 68 Comm: kworker/2:1 Tainted: G W
> 4.19.0-rc1 #1
> [ 12.603363] Hardware name: System76, Inc. Wild Dog
> Performance/H87-PLUS, BIOS 0705 12/05/2013
> [ 12.603420] Workqueue: events mei_cl_bus_rescan_work
> [ 12.603459] Call Trace:
> [ 12.603486] dump_stack+0x7c/0xbb
> [ 12.603520] print_address_description+0x73/0x280
> [ 12.603560] kasan_report+0x258/0x380
> [ 12.603589] ? mei_cl_write+0x481/0x860
> [ 12.603625] mei_cl_write+0x481/0x860
> [ 12.603664] ? mei_cl_irq_write+0x570/0x570
> [ 12.603699] ? kasan_unpoison_shadow+0x30/0x40
> [ 12.603735] ? kasan_kmalloc+0xa0/0xd0
> [ 12.603770] ? wait_woken+0x140/0x140
> [ 12.603803] ? mei_cl_alloc_cb+0xa9/0xf0
> [ 12.603847] __mei_cl_send+0x371/0x3e0
> [ 12.603888] ? wait_for_completion+0x1d0/0x1d0
> [ 12.603923] ? mei_cldev_driver_unregister+0x40/0x40
> [ 12.603961] ? find_first_zero_bit+0x19/0x70
> [ 12.604014] mei_mkhi_fix+0x12d/0x480
> [ 12.604045] ? worker_thread+0x69/0x690
> [ 12.604075] ? kthread+0x1ae/0x1d0
> [ 12.604103] ? ret_from_fork+0x3a/0x50
> [ 12.604135] ? check_chain_key+0x139/0x1f0
> [ 12.604173] ? mei_wd+0xa0/0xa0
> [ 12.604203] ? mark_lock+0xc7/0x7c0
> [ 12.604234] ? mark_lock+0xc7/0x7c0
> [ 12.604285] mei_cl_bus_dev_fixup+0x196/0x1b0
> [ 12.604322] ? mei_nfc+0x4d0/0x4d0
> [ 12.604354] ? lockdep_hardirqs_on+0x18c/0x280
> [ 12.604400] ? __kasan_slab_free+0x143/0x180
> [ 12.604441] ? mei_cl_bus_rescan_work+0x2f1/0x500
> [ 12.604477] mei_cl_bus_rescan_work+0x2f1/0x500
> [ 12.604527] process_one_work+0x5e5/0xb00
> [ 12.604573] ? wq_pool_ids_show+0x1e0/0x1e0
> [ 12.604628] worker_thread+0x69/0x690
> [ 12.604675] ? process_one_work+0xb00/0xb00
> [ 12.604706] kthread+0x1ae/0x1d0
> [ 12.604734] ? kthread_create_worker_on_cpu+0xc0/0xc0
> [ 12.604776] ret_from_fork+0x3a/0x50
>
> [ 12.604845] Allocated by task 68:
> [ 12.604872] kasan_kmalloc+0xa0/0xd0
> [ 12.604900] kmem_cache_alloc_trace+0x118/0x250
> [ 12.604933] mei_cl_alloc_cb+0x3b/0xf0
> [ 12.604962] __mei_cl_send+0x312/0x3e0
> [ 12.604991] mei_mkhi_fix+0x12d/0x480
> [ 12.605020] mei_cl_bus_dev_fixup+0x196/0x1b0
> [ 12.605052] mei_cl_bus_rescan_work+0x2f1/0x500
> [ 12.605085] process_one_work+0x5e5/0xb00
> [ 12.605116] worker_thread+0x69/0x690
> [ 12.605144] kthread+0x1ae/0x1d0
> [ 12.605170] ret_from_fork+0x3a/0x50
>
> [ 12.605213] Freed by task 104:
> [ 12.605238] __kasan_slab_free+0x12e/0x180
> [ 12.605269] kfree+0xd4/0x250
> [ 12.605294] mei_cl_complete+0xc1/0x230
> [ 12.605324] mei_irq_compl_handler+0x95/0xf0
> [ 12.605356] mei_me_irq_thread_handler+0x7e5/0xc90
> [ 12.605391] irq_thread_fn+0x3f/0x80
> [ 12.605418] irq_thread+0x175/0x250
> [ 12.605446] kthread+0x1ae/0x1d0
> [ 12.605472] ret_from_fork+0x3a/0x50
>
> [ 12.605515] The buggy address belongs to the object at ffff880416d3a300
> which belongs to the cache kmalloc-96 of size 96
> [ 12.605591] The buggy address is located 32 bytes inside of
> 96-byte region [ffff880416d3a300, ffff880416d3a360)
> [ 12.605662] The buggy address belongs to the page:
> [ 12.605697] page:ffffea00105b4e80 count:1 mapcount:0
> mapping:ffff8800b580f400 index:0x0
> [ 12.605753] flags: 0xa00000000000100(slab)
> [ 12.605785] raw: 0a00000000000100 dead000000000100
> dead000000000200
> ffff8800b580f400
> [ 12.605838] raw: 0000000000000000 0000000080200020 00000001ffffffff
> 0000000000000000
> [ 12.605888] page dumped because: kasan: bad access detected
>
> [ 12.605941] Memory state around the buggy address:
> [ 12.605976] ffff880416d3a200: fb fb fb fb fb fb fb fb fb fb fb fb
> fc fc fc fc
> [ 12.606024] ffff880416d3a280: fb fb fb fb fb fb fb fb fb fb fb fb
> fc fc fc fc
> [ 12.606073] >ffff880416d3a300: fb fb fb fb fb fb fb fb fb fb fb fb
> fc fc fc fc
> [ 12.606121] ^
> [ 12.606152] ffff880416d3a380: fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc fc fc
> [ 12.606201] ffff880416d3a400: fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc fc fc
> [ 12.606249]
> ================================================================
> =
>
> thanks,
> -- Shuah
On Mon, 27 Aug 2018 06:44:59 PDT (-0700), [email protected] wrote:
> On Sun, Aug 26, 2018 at 02:49:14PM -0700, Linus Torvalds wrote:
>> So two weeks have passed, and the merge window for 4.19 is over.
>>
> [ ... ]
>>
>> Anyway, go forth and test,
>>
>
> Build results:
> total: 132 pass: 129 fail: 3
> Failed builds:
> riscv:defconfig
> riscv:allnoconfig
> sparc32:allmodconfig
> Qemu test results:
> total: 299 pass: 297 fail: 2
> Failed tests:
> riscv:virt:defconfig:initrd
> riscv:virt:defconfig:virtio-blk:rootfs
>
> ---
> riscv:
>
> In file included from arch/riscv/include/asm/tlb.h:17:0,
> from arch/riscv/include/asm/pgalloc.h:19,
> from arch/riscv/mm/fault.c:30:
> include/asm-generic/tlb.h: In function 'tlb_flush_mmu_tlbonly':
> include/asm-generic/tlb.h:147:2: error: implicit declaration of function 'tlb_flush'
>
> Known problem, patch submitted.
Thanks for the patch (as well as running the build farm)! It should be in the
PR I submit today, assuming I can get through my email...
>
> ---
> sparc32:allmodconfig:
>
> arch/sparc/kernel/head_32.o: In function `current_pc':
> arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5040): relocation truncated to fit: R_SPARC_WDISP22 against `.init.text'
> arch/sparc/kernel/head_32.o: In function `halt_notsup':
> arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5100): relocation truncated to fit: R_SPARC_WDISP22 against `.init.text'
> arch/sparc/kernel/head_32.o: In function `leon_init':
> arch/sparc/kernel/.tmp_head_32.o:(.init.text+0xa4): relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section
> in arch/sparc/kernel/trampoline_32.o
> arch/sparc/kernel/process_32.o:(.fixup+0x4): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
> arch/sparc/kernel/process_32.o:(.fixup+0xc): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
> arch/sparc/kernel/signal_32.o:(.fixup+0x0): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
> arch/sparc/kernel/signal_32.o:(.fixup+0x8): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
> arch/sparc/kernel/signal_32.o:(.fixup+0x10): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
> arch/sparc/kernel/signal_32.o:(.fixup+0x18): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
> arch/sparc/kernel/signal_32.o:(.fixup+0x20): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
> arch/sparc/kernel/signal_32.o:(.fixup+0x28): additional relocation overflows omitted from the output
>
> For the most part this is due to calls / short jumps between .head.text,
> .text, and .init.text. Probably old, now seen because the image is now
> too large.
>
> ---
> On top of that, there are various runtime warnings.
>
> sh:
>
> WARNING: CPU: 0 PID: 932 at mm/slab.c:2666 cache_alloc_refill+0x8a/0x594
>
> Known problem. Fix was under discussion. I don't know if it was accepted.
>
> https://marc.info/?t=153301426900002&r=1&w=2
> https://www.spinics.net/lists/linux-sh/msg53298.html
>
> ---
> sparc:
>
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 esp_sbus_probe+0x408/0x6e8
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 sparc_lance_probe_one+0x428/0x4f
>
> Missing initialization of coherent_dma_mask in the respective drivers.
>
> ---
> Each platform driver instantiated through a devicetree node now generates
> the following warning:
>
> esp ffd38e00: DMA mask not set
>
> It isn't a traceback so it may fly under the radar. There is nothing the
> drivers can do about it; the message is generated by the core before the
> driver probe function is called. No idea what a correct fix might be.
>
> Guenter
On Mon, Aug 27, 2018 at 6:45 AM Guenter Roeck <[email protected]> wrote:
>
> Build results:
> total: 132 pass: 129 fail: 3
Thanks for running these. Looks like everything but the sparc thing is
under control, and the sparc thing might be one of those "big builds
don't work on sparc" ;(
Linus
On Mon, Aug 27, 2018 at 02:56:32PM -0700, Linus Torvalds wrote:
> On Mon, Aug 27, 2018 at 6:45 AM Guenter Roeck <[email protected]> wrote:
> >
> > Build results:
> > total: 132 pass: 129 fail: 3
>
> Thanks for running these. Looks like everything but the sparc thing is
> under control, and the sparc thing might be one of those "big builds
> don't work on sparc" ;(
>
In general I would agree. On the other side, someone who knows sparc
assembler should be able to fix the problem. sparc is notorious for
failing allmodconfig builds, mostly due to its separate devicetree
implementation. On top of that, many allmodconfig builds already fail,
often for minor reasons such as duplicate symbols or missing exports.
Dropping sparc:allmodconfig will cause sparc builds to deteriorate,
and we'll lose valuable build feedback. On the plus side,
sparc64:allmodconfig still builds, but that doesn't cover 32/64 bit
differences.
I'll monitor the situation for a while and stop building sparc:allmodconfig
if the problem isn't fixed around -rc7.
Guenter
From: Linus Torvalds
> Sent: 26 August 2018 22:49
>
> So two weeks have passed, and the merge window for 4.19 is over.
>
> This was a fairly frustrating merge window, partly because 4.19 looks
> to be a pretty big release (no single reason), and partly just due to
> random noise.
...
Time for 5.0 ??
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)