Linux 4.19-rc1

Linux 4.19-rc1

[Linus Torvalds]

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

linux-next: stats (Was: Linux 4.19-rc1)

[Stephen Rothwell]

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

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 jolsa@kernel.org
     26 tglx@linutronix.de
     24 tz.stoyanov@gmail.com
     21 acme@redhat.com
     19 arnd@arndb.de
     17 yamada.masahiro@socionext.com
     16 richard@nod.at
     16 jgg@ziepe.ca
     13 jhs@mojatatu.com
     10 saeedm@mellanox.com

Top ten commiters:

    100 acme@redhat.com
     81 tglx@linutronix.de
     80 davem@davemloft.net
     38 torvalds@linux-foundation.org
     37 mpe@ellerman.id.au
     29 jgg@ziepe.ca
     27 alexander.deucher@amd.com
     24 yamada.masahiro@socionext.com
     22 richard@nod.at
     22 rafael.j.wysocki@intel.com

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 willy@infradead.org
     37 dhowells@redhat.com
     25 akpm@linux-foundation.org
     22 suzuki.poulose@arm.com
     18 me@tobin.cc
     13 olof@lixom.net
     11 peda@axentia.se
      9 ktkhai@virtuozzo.com
      7 dsterba@suse.com
      7 cminyard@mvista.com

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

Top ten commiters:

     90 sfr@canb.auug.org.au
     76 willy@infradead.org
     39 dhowells@redhat.com
     23 mathieu.poirier@linaro.org
     18 me@tobin.cc
     14 paulmck@linux.vnet.ibm.com
     14 olof@lixom.net
     14 cminyard@mvista.com
     13 wsa@the-dreams.de
     12 dsterba@suse.com

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 --]

Re: Linux 4.19-rc1

[Guenter Roeck]

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

Re: Linux 4.19-rc1

[Christoph Hellwig]

> 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 <hch@lst.de>
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 <hch@lst.de>
---
 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

Re: Linux 4.19-rc1

[Guenter Roeck]

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 <hch@lst.de>
> 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 <hch@lst.de>
> ---
>  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

Re: Linux 4.19-rc1

[Christoph Hellwig]

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.

Re: Linux 4.19-rc1

[Shuah Khan]

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.

[   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

Re: Linux 4.19-rc1

[Guenter Roeck]

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

RE: Linux 4.19-rc1

[Winkler, Tomas]

> 
> 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

Re: Linux 4.19-rc1

[Palmer Dabbelt]

On Mon, 27 Aug 2018 06:44:59 PDT (-0700), linux@roeck-us.net 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

Re: Linux 4.19-rc1

[Linus Torvalds]

On Mon, Aug 27, 2018 at 6:45 AM Guenter Roeck <linux@roeck-us.net> 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

Re: Linux 4.19-rc1

[Guenter Roeck]

On Mon, Aug 27, 2018 at 02:56:32PM -0700, Linus Torvalds wrote:
> On Mon, Aug 27, 2018 at 6:45 AM Guenter Roeck <linux@roeck-us.net> 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

RE: Linux 4.19-rc1

[David Laight]

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)