Linux 5.3-rc1

Linux 5.3-rc1

[Linus Torvalds]

It's been two weeks, and the merge window is over, and Linux 5.3-rc1
is tagged and pushed out.

This is a pretty big release, judging by the commit count. Not the
biggest ever (that honor still goes to 4.9-rc1, which was
exceptionally big), and we've had a couple of comparable ones (4.12,
4.15 and 4.19 were also big merge windows), but it's definitely up
there.

The merge window also started out pretty painfully, with me hitting a
couple of bugs in the first couple of days. That's never a good sign,
since I don't tend to do anything particularly odd, and if I hit bugs
it means code wasn't tested well enough. In one case it was due to me
using a simplified configuration that hadn't been tested, and caused
an odd issue to show up - it happens. But in the other case, it really
was code that was too recent and too rough and hadn't baked enough.
The first got fixed, the second just got reverted.

Anyway, despite the rocky start, and the big size, things mostly
smoothed out towards the end of the merge window. And there's a lot to
like in 5.3. Too much to do the shortlog with individual commits, of
course, so appended is the usual "mergelog" of people I merged from
and a one-liner very high-level "what got merged". For more detail,
you should go check the git tree.

As always: the people credited below are just the people I pull from,
there's about 1600 individual developers (for 12500+ non-merge
commits) in this merge window.

Go test,

            Linus

---

Al Viro (5):
    vfs mount updates
    adfs updates
    misc vfs updates
    dcache and mountpoint updates
    vfs documentation typo fix

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 (2):
    x86 platform driver updates
    another x86 platform driver update

Arnd Bergmann (1):
    asm-generic updates

Bartlomiej Zolnierkiewicz (1):
    fbdev updates

Benson Leung (1):
    chrome platform updates

Bjorn Andersson (3):
    rpmsg updates
    remoteproc updates
    hwspinlock updates

Bjorn Helgaas (1):
    PCI updates

Boris Brezillon (1):
    ic3 updates

Bruce Fields (1):
    nfsd updates

Catalin Marinas (1):
    arm64 updates

Christian Brauner (3):
    pidfd updates
    clone3 system call
    pidfd and clone3 fixes

Christoph Hellwig (2):
    dma-mapping updates
    dma-mapping fixes

Corey Minyard (1):
    IPMI updates

Dan Williams (2):
    libnvdimm updates
    dax updates

Daniel Vetter (1):
    drm fixes

Darrick Wong (6):
    iomap updates
    copy_file_range updates
    common SETFLAGS/FSSETXATTR parameter checking
    xfs updates
    xfs cleanups
    iomap split/cleanup

Dave Airlie (1):
    drm updates

David Howells (5):
    misc keyring updates
    request_key improvements
    keyring namespacing
    keyring ACL support
    afs updates

David Miller (5):
    networking updates
    IDE update
    networking fixes
    sparc updates
    networking fixes

David Sterba (1):
    btrfs updates

David Teigland (1):
    dlm updates

Denis Efremov (1):
    floppy ioctl verification fixes

Dennis Zhou (1):
    percpu updates

Dmitry Torokhov (2):
    input updates
    more input updates

Dominique Martinet (1):
    9p updates

Eric Biederman (1):
    force_sig() argument change

Eric Biggers (1):
    fscrypt updates

Geert Uytterhoeven (2):
    m68k updates
    m68k fix

Greg KH (5):
    char / misc driver updates
    staging and IIO driver updates
    tty / serial driver updates
    USB / PHY updates
    driver core and debugfs updates

Greg Ungerer (1):
    m68nommu updates

Guenter Roeck (1):
    hwmon updates

Guo Ren (1):
    arch/csky updates

Helge Deller (2):
    parisc updates
    parisc fixes

Herbert Xu (2):
    crypto updates
    crypto fixes

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (17):
    RCU updates
    locking updates
    RAS updates
    scheduler updates
    x86 asm updates
    x86 build updates
    x86 cache resource control update
    x86 cleanups
    x86 AVX512 status update
    x86 paravirt updates
    x86 platform updates
    x86 topology updates
    perf updates
    scheduler fix
    x86 fix
    locking fix
    perf fixes

Jacek Anaszewski (1):
    LED updates

Jaegeuk Kim (1):
    f2fs updates

James Bottomley (3):
    SCSI updates
    SCSI scatter-gather list updates
    SCSI fixes

James Morris (1):
    capabilities update

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

Jarkko Sakkinen (1):
    tpm updates

Jason Gunthorpe (2):
    HMM updates
    rdma updates

Jassi Brar (1):
    mailbox updates

Jeff Layton (1):
    file locking updates

Jens Axboe (4):
    block updates
    libata updates
    io_uring updates
    more block updates

Jessica Yu (1):
    module updates

Jiri Kosina (2):
    livepatching updates
    HID updates

Joerg Roedel (1):
    iommu updates

Jon Mason (1):
    NTB updates

Jonathan Corbet (1):
    Documentation updates

Juergen Gross (1):
    xen updates

Kees Cook (2):
    pstore updates
    security/loadpin updates

Kirill Smelkov (1):
    stream_open() updates

Konrad Rzeszutek Wilk (1):
    swiotlb updates

Lee Jones (2):
    MFD updates
    backlight updates

Ley Foon Tan (1):
    arch/nios2 updates

Linus Walleij (3):
    GPIO updates
    pin control updates
    GPIO fixes

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

Masahiro Yamada (3):
    Kbuild updates
    Kconfig updates
    more Kbuild updates

Mauro Carvalho Chehab (2):
    media updates
    rst conversion of docs

Max Filippov (1):
    Xtensa updates

Micah Morton (1):
    safesetid updates

Michael Ellerman (1):
    powerpc updates

Michael Tsirkin (1):
    virtio, vhost updates

Mike Marshall (1):
    orangefs updates

Mike Snitzer (2):
    device mapper updates
    more device mapper updates

Mimi Zohar (1):
    integrity updates

Miquel Raynal (1):
    MTD updates

Olof Johansson (4):
    ARM SoC platform updates
    ARM SoC-related driver updates
    ARM Devicetree updates
    ARM SoC defconfig updates

Paolo Bonzini (2):
    KVM updates
    more KVM updates

Paul Burton (1):
    MIPS updates

Paul Moore (2):
    audit updates
    selinux updates

Paul Walmsley (1):
    RISC-V updates

Petr Mladek (1):
    printk updates

Rafael Wysocki (6):
    power management updates
    ACPI updates
    device properties framework updates
    ACPI fix
    more ACPI updates
    more power management updates

Richard Weinberger (2):
    UML updates
    UBIFS updates

Rob Herring (2):
    Devicetree updates
    Devicetree fixes

Russell King (1):
    ARM updates

Sasha Levin (1):
    hyper-v updates

Sebastian Reichel (1):
    power supply and reset updates

Shuah Khan (1):
    Kselftest updates

Stephen Boyd (1):
    clk updates

Steve French (2):
    cifs updates
    cifs fixes

Steven Rostedt (2):
    tracing updates
    tracing fix

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (2):
    workqueue updates
    cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Gleixner (22):
    debugobjects updates
    Reed-Solomon library updates
    SMP/hotplug updates
    irq updates
    timer updates
    x96 apic updates
    x86 vsyscall updates
    x86 FPU updates
    x86 CPU feature updates
    x86 timer updates
    x86 pti updates
    x86 boot updates
    x865 kdump updates
    irq fixes
    stacktrace fix
    timer fixes
    x86 fixes
    CONFIG_PREEMPT_RT stub config
    smp fix
    core fixes
    perf tooling updates
    x86 fixes

Tony Luck (1):
    EDAC updates

Trond Myklebust (1):
    NFS client updates

Tyler Hicks (1):
    eCryptfs updates

Ulf Hansson (1):
    MMC updates

Vasily Gorbik (2):
    s390 updates
    more s390 updates

Vineet Gupta (1):
    ARC updates

Vinod Koul (1):
    dmaengine updates

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

Yoshinori Sato (2):
    SH updates
    h8300 update

Zhang Rui (1):
    thermal management updates

Re: Linux 5.3-rc1

[Bhaskar Chowdhury]

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

Here we go Linus! :) 

On 14:33 Sun 21 Jul , Linus Torvalds wrote:
>It's been two weeks, and the merge window is over, and Linux 5.3-rc1
>is tagged and pushed out.
>
>This is a pretty big release, judging by the commit count. Not the
>biggest ever (that honor still goes to 4.9-rc1, which was
>exceptionally big), and we've had a couple of comparable ones (4.12,
>4.15 and 4.19 were also big merge windows), but it's definitely up
>there.
>
>The merge window also started out pretty painfully, with me hitting a
>couple of bugs in the first couple of days. That's never a good sign,
>since I don't tend to do anything particularly odd, and if I hit bugs
>it means code wasn't tested well enough. In one case it was due to me
>using a simplified configuration that hadn't been tested, and caused
>an odd issue to show up - it happens. But in the other case, it really
>was code that was too recent and too rough and hadn't baked enough.
>The first got fixed, the second just got reverted.
>
>Anyway, despite the rocky start, and the big size, things mostly
>smoothed out towards the end of the merge window. And there's a lot to
>like in 5.3. Too much to do the shortlog with individual commits, of
>course, so appended is the usual "mergelog" of people I merged from
>and a one-liner very high-level "what got merged". For more detail,
>you should go check the git tree.
>
>As always: the people credited below are just the people I pull from,
>there's about 1600 individual developers (for 12500+ non-merge
>commits) in this merge window.
>
>Go test,
>
>            Linus
>
>---
>
>Al Viro (5):
>    vfs mount updates
>    adfs updates
>    misc vfs updates
>    dcache and mountpoint updates
>    vfs documentation typo fix
>
>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 (2):
>    x86 platform driver updates
>    another x86 platform driver update
>
>Arnd Bergmann (1):
>    asm-generic updates
>
>Bartlomiej Zolnierkiewicz (1):
>    fbdev updates
>
>Benson Leung (1):
>    chrome platform updates
>
>Bjorn Andersson (3):
>    rpmsg updates
>    remoteproc updates
>    hwspinlock updates
>
>Bjorn Helgaas (1):
>    PCI updates
>
>Boris Brezillon (1):
>    ic3 updates
>
>Bruce Fields (1):
>    nfsd updates
>
>Catalin Marinas (1):
>    arm64 updates
>
>Christian Brauner (3):
>    pidfd updates
>    clone3 system call
>    pidfd and clone3 fixes
>
>Christoph Hellwig (2):
>    dma-mapping updates
>    dma-mapping fixes
>
>Corey Minyard (1):
>    IPMI updates
>
>Dan Williams (2):
>    libnvdimm updates
>    dax updates
>
>Daniel Vetter (1):
>    drm fixes
>
>Darrick Wong (6):
>    iomap updates
>    copy_file_range updates
>    common SETFLAGS/FSSETXATTR parameter checking
>    xfs updates
>    xfs cleanups
>    iomap split/cleanup
>
>Dave Airlie (1):
>    drm updates
>
>David Howells (5):
>    misc keyring updates
>    request_key improvements
>    keyring namespacing
>    keyring ACL support
>    afs updates
>
>David Miller (5):
>    networking updates
>    IDE update
>    networking fixes
>    sparc updates
>    networking fixes
>
>David Sterba (1):
>    btrfs updates
>
>David Teigland (1):
>    dlm updates
>
>Denis Efremov (1):
>    floppy ioctl verification fixes
>
>Dennis Zhou (1):
>    percpu updates
>
>Dmitry Torokhov (2):
>    input updates
>    more input updates
>
>Dominique Martinet (1):
>    9p updates
>
>Eric Biederman (1):
>    force_sig() argument change
>
>Eric Biggers (1):
>    fscrypt updates
>
>Geert Uytterhoeven (2):
>    m68k updates
>    m68k fix
>
>Greg KH (5):
>    char / misc driver updates
>    staging and IIO driver updates
>    tty / serial driver updates
>    USB / PHY updates
>    driver core and debugfs updates
>
>Greg Ungerer (1):
>    m68nommu updates
>
>Guenter Roeck (1):
>    hwmon updates
>
>Guo Ren (1):
>    arch/csky updates
>
>Helge Deller (2):
>    parisc updates
>    parisc fixes
>
>Herbert Xu (2):
>    crypto updates
>    crypto fixes
>
>Ilya Dryomov (1):
>    ceph updates
>
>Ingo Molnar (17):
>    RCU updates
>    locking updates
>    RAS updates
>    scheduler updates
>    x86 asm updates
>    x86 build updates
>    x86 cache resource control update
>    x86 cleanups
>    x86 AVX512 status update
>    x86 paravirt updates
>    x86 platform updates
>    x86 topology updates
>    perf updates
>    scheduler fix
>    x86 fix
>    locking fix
>    perf fixes
>
>Jacek Anaszewski (1):
>    LED updates
>
>Jaegeuk Kim (1):
>    f2fs updates
>
>James Bottomley (3):
>    SCSI updates
>    SCSI scatter-gather list updates
>    SCSI fixes
>
>James Morris (1):
>    capabilities update
>
>Jan Kara (2):
>    fsnotify updates
>    ext2, udf and quota updates
>
>Jarkko Sakkinen (1):
>    tpm updates
>
>Jason Gunthorpe (2):
>    HMM updates
>    rdma updates
>
>Jassi Brar (1):
>    mailbox updates
>
>Jeff Layton (1):
>    file locking updates
>
>Jens Axboe (4):
>    block updates
>    libata updates
>    io_uring updates
>    more block updates
>
>Jessica Yu (1):
>    module updates
>
>Jiri Kosina (2):
>    livepatching updates
>    HID updates
>
>Joerg Roedel (1):
>    iommu updates
>
>Jon Mason (1):
>    NTB updates
>
>Jonathan Corbet (1):
>    Documentation updates
>
>Juergen Gross (1):
>    xen updates
>
>Kees Cook (2):
>    pstore updates
>    security/loadpin updates
>
>Kirill Smelkov (1):
>    stream_open() updates
>
>Konrad Rzeszutek Wilk (1):
>    swiotlb updates
>
>Lee Jones (2):
>    MFD updates
>    backlight updates
>
>Ley Foon Tan (1):
>    arch/nios2 updates
>
>Linus Walleij (3):
>    GPIO updates
>    pin control updates
>    GPIO fixes
>
>Mark Brown (3):
>    regmap updates
>    regulator updates
>    spi updates
>
>Masahiro Yamada (3):
>    Kbuild updates
>    Kconfig updates
>    more Kbuild updates
>
>Mauro Carvalho Chehab (2):
>    media updates
>    rst conversion of docs
>
>Max Filippov (1):
>    Xtensa updates
>
>Micah Morton (1):
>    safesetid updates
>
>Michael Ellerman (1):
>    powerpc updates
>
>Michael Tsirkin (1):
>    virtio, vhost updates
>
>Mike Marshall (1):
>    orangefs updates
>
>Mike Snitzer (2):
>    device mapper updates
>    more device mapper updates
>
>Mimi Zohar (1):
>    integrity updates
>
>Miquel Raynal (1):
>    MTD updates
>
>Olof Johansson (4):
>    ARM SoC platform updates
>    ARM SoC-related driver updates
>    ARM Devicetree updates
>    ARM SoC defconfig updates
>
>Paolo Bonzini (2):
>    KVM updates
>    more KVM updates
>
>Paul Burton (1):
>    MIPS updates
>
>Paul Moore (2):
>    audit updates
>    selinux updates
>
>Paul Walmsley (1):
>    RISC-V updates
>
>Petr Mladek (1):
>    printk updates
>
>Rafael Wysocki (6):
>    power management updates
>    ACPI updates
>    device properties framework updates
>    ACPI fix
>    more ACPI updates
>    more power management updates
>
>Richard Weinberger (2):
>    UML updates
>    UBIFS updates
>
>Rob Herring (2):
>    Devicetree updates
>    Devicetree fixes
>
>Russell King (1):
>    ARM updates
>
>Sasha Levin (1):
>    hyper-v updates
>
>Sebastian Reichel (1):
>    power supply and reset updates
>
>Shuah Khan (1):
>    Kselftest updates
>
>Stephen Boyd (1):
>    clk updates
>
>Steve French (2):
>    cifs updates
>    cifs fixes
>
>Steven Rostedt (2):
>    tracing updates
>    tracing fix
>
>Takashi Iwai (2):
>    sound updates
>    sound fixes
>
>Ted Ts'o (1):
>    ext4 updates
>
>Tejun Heo (2):
>    workqueue updates
>    cgroup updates
>
>Thierry Reding (1):
>    pwm updates
>
>Thomas Gleixner (22):
>    debugobjects updates
>    Reed-Solomon library updates
>    SMP/hotplug updates
>    irq updates
>    timer updates
>    x96 apic updates
>    x86 vsyscall updates
>    x86 FPU updates
>    x86 CPU feature updates
>    x86 timer updates
>    x86 pti updates
>    x86 boot updates
>    x865 kdump updates
>    irq fixes
>    stacktrace fix
>    timer fixes
>    x86 fixes
>    CONFIG_PREEMPT_RT stub config
>    smp fix
>    core fixes
>    perf tooling updates
>    x86 fixes
>
>Tony Luck (1):
>    EDAC updates
>
>Trond Myklebust (1):
>    NFS client updates
>
>Tyler Hicks (1):
>    eCryptfs updates
>
>Ulf Hansson (1):
>    MMC updates
>
>Vasily Gorbik (2):
>    s390 updates
>    more s390 updates
>
>Vineet Gupta (1):
>    ARC updates
>
>Vinod Koul (1):
>    dmaengine updates
>
>Wim Van Sebroeck (1):
>    watchdog updates
>
>Wolfram Sang (1):
>    i2c updates
>
>Yoshinori Sato (2):
>    SH updates
>    h8300 update
>
>Zhang Rui (1):
>    thermal management updates

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

Re: Linux 5.3-rc1

[Guenter Roeck]

On Sun, Jul 21, 2019 at 02:33:38PM -0700, Linus Torvalds wrote:

[ ... ]
> 
> Go test,
> 

Things looked pretty good until a few days ago. Unfortunately,
the last few days brought in a couple of issues.

riscv:virt:defconfig:scsi[virtio]
riscv:virt:defconfig:scsi[virtio-pci]

Boot tests crash with no useful backtrace. Bisect points to
merge ac60602a6d8f ("Merge tag 'dma-mapping-5.3-1'"). Log is at
https://kerneltests.org/builders/qemu-riscv64-master/builds/238/steps/qemubuildcommand_1/logs/stdio

ppc:mpc8544ds:mpc85xx_defconfig:sata-sii3112
ppc64:pseries:pseries_defconfig:sata-sii3112
ppc64:pseries:pseries_defconfig:little:sata-sii3112
ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112

ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ DMA

and many similar errors. Boot ultimately times out. Bisect points to merge
f65420df914a ("Merge tag 'scsi-fixes'").

Logs:
https://kerneltests.org/builders/qemu-ppc64-master/builds/1212/steps/qemubuildcommand/logs/stdio
https://kerneltests.org/builders/qemu-ppc-master/builds/1255/steps/qemubuildcommand/logs/stdio

Guenter

---
riscv bisect log

# bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
# good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take the DMA max mapping size into account
git bisect start 'HEAD' 'bdd17bdef7d8'
# good: [237f83dfbe668443b5e31c3c7576125871cca674] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 237f83dfbe668443b5e31c3c7576125871cca674
# good: [be8454afc50f43016ca8b6130d9673bdd0bd56ec] Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm
git bisect good be8454afc50f43016ca8b6130d9673bdd0bd56ec
# good: [d4df33b0e9925c158b313a586fb1557cf29cfdf4] Merge branch 'for-linus-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb
git bisect good d4df33b0e9925c158b313a586fb1557cf29cfdf4
# good: [f90b8fda3a9d72a9422ea80ae95843697f94ea4a] ARM: dts: gemini: Set DIR-685 SPI CS as active low
git bisect good f90b8fda3a9d72a9422ea80ae95843697f94ea4a
# good: [31cc088a4f5d83481c6f5041bd6eb06115b974af] Merge tag 'drm-next-2019-07-19' of git://anongit.freedesktop.org/drm/drm
git bisect good 31cc088a4f5d83481c6f5041bd6eb06115b974af
# good: [ad21a4ce040cc41b4a085417169b558e86af56b7] dt-bindings: pinctrl: aspeed: Fix 'compatible' schema errors
git bisect good ad21a4ce040cc41b4a085417169b558e86af56b7
# good: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good e6023adc5c6af79ac8ac5b17939f58091fa0d870
# bad: [ac60602a6d8f6830dee89f4b87ee005f62eb7171] Merge tag 'dma-mapping-5.3-1' of git://git.infradead.org/users/hch/dma-mapping
git bisect bad ac60602a6d8f6830dee89f4b87ee005f62eb7171
# good: [6e67d77d673d785631b0c52314b60d3c68ebe809] perf vendor events s390: Add JSON files for machine type 8561
git bisect good 6e67d77d673d785631b0c52314b60d3c68ebe809
# good: [a0d14b8909de55139b8702fe0c7e80b69763dcfb] x86/mm, tracing: Fix CR2 corruption
git bisect good a0d14b8909de55139b8702fe0c7e80b69763dcfb
# good: [6879298bd0673840cadd1fb36d7225485504ceb4] x86/entry/64: Prevent clobbering of saved CR2 value
git bisect good 6879298bd0673840cadd1fb36d7225485504ceb4
# good: [449fa54d6815be8c2c1f68fa9dbbae9384a7c03e] dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device
git bisect good 449fa54d6815be8c2c1f68fa9dbbae9384a7c03e
# good: [e0c5c5e308ee9b3548844f0d88da937782b895ef] Merge tag 'perf-core-for-mingo-5.3-20190715' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
git bisect good e0c5c5e308ee9b3548844f0d88da937782b895ef
# good: [c6dd78fcb8eefa15dd861889e0f59d301cb5230c] Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good c6dd78fcb8eefa15dd861889e0f59d301cb5230c
# first bad commit: [ac60602a6d8f6830dee89f4b87ee005f62eb7171] Merge tag 'dma-mapping-5.3-1' of git://git.infradead.org/users/hch/dma-mapping

---------
ppc/ppc64 bisect log

# bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
# good: [abdfd52a295fb5731ab07b5c9013e2e39f4d1cbe] Merge tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect start 'HEAD' 'abdfd52a295f'
# bad: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad e6023adc5c6af79ac8ac5b17939f58091fa0d870
# bad: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect bad f65420df914a85e33b2c8b1cab310858b2abb7c0
# good: [168c79971b4a7be7011e73bf488b740a8e1135c8] Merge tag 'kbuild-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
git bisect good 168c79971b4a7be7011e73bf488b740a8e1135c8
# good: [106d45f350c7cac876844dc685845cba4ffdb70b] scsi: zfcp: fix request object use-after-free in send path causing wrong traces
git bisect good 106d45f350c7cac876844dc685845cba4ffdb70b
# good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take the DMA max mapping size into account
git bisect good bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
# good: [09a4460ba4434ef0327cd26bf25f2d7afb973251] scsi: IB/iser: set virt_boundary_mask in the scsi host
git bisect good 09a4460ba4434ef0327cd26bf25f2d7afb973251
# good: [ce0ad853109733d772d26224297fda0de313bf13] scsi: mpt3sas: set an unlimited max_segment_size for SAS 3.0 HBAs
git bisect good ce0ad853109733d772d26224297fda0de313bf13
# good: [07d9aa14346489d6facae5777ceb267a1dcadbc5] scsi: megaraid_sas: set an unlimited max_segment_size
git bisect good 07d9aa14346489d6facae5777ceb267a1dcadbc5
# first bad commit: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

Re: Linux 5.3-rc1

[James Bottomley]

[linux-scsi added to cc]
On Mon, 2019-07-22 at 15:21 -0700, Guenter Roeck wrote:
> On Sun, Jul 21, 2019 at 02:33:38PM -0700, Linus Torvalds wrote:
> 
> [ ... ]
> > 
> > Go test,
> > 
> 
> Things looked pretty good until a few days ago. Unfortunately,
> the last few days brought in a couple of issues.
> 
> riscv:virt:defconfig:scsi[virtio]
> riscv:virt:defconfig:scsi[virtio-pci]
> 
> Boot tests crash with no useful backtrace. Bisect points to
> merge ac60602a6d8f ("Merge tag 'dma-mapping-5.3-1'"). Log is at
> https://kerneltests.org/builders/qemu-riscv64-master/builds/238/steps
> /qemubuildcommand_1/logs/stdio
> 
> ppc:mpc8544ds:mpc85xx_defconfig:sata-sii3112
> ppc64:pseries:pseries_defconfig:sata-sii3112
> ppc64:pseries:pseries_defconfig:little:sata-sii3112
> ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112
> 
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata1.00: failed command: READ DMA
> 
> and many similar errors. Boot ultimately times out. Bisect points to
> merge
> f65420df914a ("Merge tag 'scsi-fixes'").
> 
> Logs:
> https://kerneltests.org/builders/qemu-ppc64-master/builds/1212/steps/
> qemubuildcommand/logs/stdio
> https://kerneltests.org/builders/qemu-ppc-master/builds/1255/steps/qe
> mubuildcommand/logs/stdio
> 
> Guenter
> 
> ---
> riscv bisect log
> 
> # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
> # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take
> the DMA max mapping size into account
> git bisect start 'HEAD' 'bdd17bdef7d8'
> # good: [237f83dfbe668443b5e31c3c7576125871cca674] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> git bisect good 237f83dfbe668443b5e31c3c7576125871cca674
> # good: [be8454afc50f43016ca8b6130d9673bdd0bd56ec] Merge tag 'drm-
> next-2019-07-16' of git://anongit.freedesktop.org/drm/drm
> git bisect good be8454afc50f43016ca8b6130d9673bdd0bd56ec
> # good: [d4df33b0e9925c158b313a586fb1557cf29cfdf4] Merge branch 'for-
> linus-5.2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb
> git bisect good d4df33b0e9925c158b313a586fb1557cf29cfdf4
> # good: [f90b8fda3a9d72a9422ea80ae95843697f94ea4a] ARM: dts: gemini:
> Set DIR-685 SPI CS as active low
> git bisect good f90b8fda3a9d72a9422ea80ae95843697f94ea4a
> # good: [31cc088a4f5d83481c6f5041bd6eb06115b974af] Merge tag 'drm-
> next-2019-07-19' of git://anongit.freedesktop.org/drm/drm
> git bisect good 31cc088a4f5d83481c6f5041bd6eb06115b974af
> # good: [ad21a4ce040cc41b4a085417169b558e86af56b7] dt-bindings:
> pinctrl: aspeed: Fix 'compatible' schema errors
> git bisect good ad21a4ce040cc41b4a085417169b558e86af56b7
> # good: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch
> 'core-urgent-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect good e6023adc5c6af79ac8ac5b17939f58091fa0d870
> # bad: [ac60602a6d8f6830dee89f4b87ee005f62eb7171] Merge tag 'dma-
> mapping-5.3-1' of git://git.infradead.org/users/hch/dma-mapping
> git bisect bad ac60602a6d8f6830dee89f4b87ee005f62eb7171
> # good: [6e67d77d673d785631b0c52314b60d3c68ebe809] perf vendor events
> s390: Add JSON files for machine type 8561
> git bisect good 6e67d77d673d785631b0c52314b60d3c68ebe809
> # good: [a0d14b8909de55139b8702fe0c7e80b69763dcfb] x86/mm, tracing:
> Fix CR2 corruption
> git bisect good a0d14b8909de55139b8702fe0c7e80b69763dcfb
> # good: [6879298bd0673840cadd1fb36d7225485504ceb4] x86/entry/64:
> Prevent clobbering of saved CR2 value
> git bisect good 6879298bd0673840cadd1fb36d7225485504ceb4
> # good: [449fa54d6815be8c2c1f68fa9dbbae9384a7c03e] dma-direct:
> correct the physical addr in dma_direct_sync_sg_for_cpu/device
> git bisect good 449fa54d6815be8c2c1f68fa9dbbae9384a7c03e
> # good: [e0c5c5e308ee9b3548844f0d88da937782b895ef] Merge tag 'perf-
> core-for-mingo-5.3-20190715' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
> perf/urgent
> git bisect good e0c5c5e308ee9b3548844f0d88da937782b895ef
> # good: [c6dd78fcb8eefa15dd861889e0f59d301cb5230c] Merge branch 'x86-
> urgent-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect good c6dd78fcb8eefa15dd861889e0f59d301cb5230c
> # first bad commit: [ac60602a6d8f6830dee89f4b87ee005f62eb7171] Merge
> tag 'dma-mapping-5.3-1' of git://git.infradead.org/users/hch/dma-
> mapping
> 
> ---------
> ppc/ppc64 bisect log
> 
> # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
> # good: [abdfd52a295fb5731ab07b5c9013e2e39f4d1cbe] Merge tag 'armsoc-
> defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> git bisect start 'HEAD' 'abdfd52a295f'
> # bad: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch 'core-
> urgent-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad e6023adc5c6af79ac8ac5b17939f58091fa0d870
> # bad: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag 'scsi-
> fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> git bisect bad f65420df914a85e33b2c8b1cab310858b2abb7c0
> # good: [168c79971b4a7be7011e73bf488b740a8e1135c8] Merge tag 'kbuild-
> v5.3-2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
> git bisect good 168c79971b4a7be7011e73bf488b740a8e1135c8
> # good: [106d45f350c7cac876844dc685845cba4ffdb70b] scsi: zfcp: fix
> request object use-after-free in send path causing wrong traces
> git bisect good 106d45f350c7cac876844dc685845cba4ffdb70b
> # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take
> the DMA max mapping size into account
> git bisect good bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
> # good: [09a4460ba4434ef0327cd26bf25f2d7afb973251] scsi: IB/iser: set
> virt_boundary_mask in the scsi host
> git bisect good 09a4460ba4434ef0327cd26bf25f2d7afb973251
> # good: [ce0ad853109733d772d26224297fda0de313bf13] scsi: mpt3sas: set
> an unlimited max_segment_size for SAS 3.0 HBAs
> git bisect good ce0ad853109733d772d26224297fda0de313bf13
> # good: [07d9aa14346489d6facae5777ceb267a1dcadbc5] scsi:
> megaraid_sas: set an unlimited max_segment_size
> git bisect good 07d9aa14346489d6facae5777ceb267a1dcadbc5
> # first bad commit: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge
> tag 'scsi-fixes' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

When a bisect lands on a merge commit it usually indicates bad
interaction between two trees.  The way to find it is to do a bisect,
but merge up to the other side of the scsi-fixes pull before running
tests so the interaction is exposed in the bisect.

However my money is on:


commit bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 17 14:19:54 2019 +0200

    scsi: core: take the DMA max mapping size into account
 
Now that I look at the code again:


+       shost->max_sectors = min_t(unsigned int, shost->max_sectors,
+                       dma_max_mapping_size(dev) << SECTOR_SHIFT);

That shift looks to be the wrong way around (should be >>).  I bet
something is giving a very large number which becomes zero on left
shift, meaning max_sectors gets set to zero.

James

Re: Linux 5.3-rc1

[Guenter Roeck]

On 7/22/19 4:45 PM, James Bottomley wrote:
> [linux-scsi added to cc]
> On Mon, 2019-07-22 at 15:21 -0700, Guenter Roeck wrote:
>> On Sun, Jul 21, 2019 at 02:33:38PM -0700, Linus Torvalds wrote:
>>
>> [ ... ]
>>>
>>> Go test,
>>>
>>
>> Things looked pretty good until a few days ago. Unfortunately,
>> the last few days brought in a couple of issues.
>>
>> riscv:virt:defconfig:scsi[virtio]
>> riscv:virt:defconfig:scsi[virtio-pci]
>>
>> Boot tests crash with no useful backtrace. Bisect points to
>> merge ac60602a6d8f ("Merge tag 'dma-mapping-5.3-1'"). Log is at
>> https://kerneltests.org/builders/qemu-riscv64-master/builds/238/steps
>> /qemubuildcommand_1/logs/stdio
>>
>> ppc:mpc8544ds:mpc85xx_defconfig:sata-sii3112
>> ppc64:pseries:pseries_defconfig:sata-sii3112
>> ppc64:pseries:pseries_defconfig:little:sata-sii3112
>> ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112
>>
>> ata1: lost interrupt (Status 0x50)
>> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>> ata1.00: failed command: READ DMA
>>
>> and many similar errors. Boot ultimately times out. Bisect points to
>> merge
>> f65420df914a ("Merge tag 'scsi-fixes'").
>>
>> Logs:
>> https://kerneltests.org/builders/qemu-ppc64-master/builds/1212/steps/
>> qemubuildcommand/logs/stdio
>> https://kerneltests.org/builders/qemu-ppc-master/builds/1255/steps/qe
>> mubuildcommand/logs/stdio
>>
>> Guenter
>>
>> ---
>> riscv bisect log
>>
>> # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
>> # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take
>> the DMA max mapping size into account
>> git bisect start 'HEAD' 'bdd17bdef7d8'
>> # good: [237f83dfbe668443b5e31c3c7576125871cca674] Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>> git bisect good 237f83dfbe668443b5e31c3c7576125871cca674
>> # good: [be8454afc50f43016ca8b6130d9673bdd0bd56ec] Merge tag 'drm-
>> next-2019-07-16' of git://anongit.freedesktop.org/drm/drm
>> git bisect good be8454afc50f43016ca8b6130d9673bdd0bd56ec
>> # good: [d4df33b0e9925c158b313a586fb1557cf29cfdf4] Merge branch 'for-
>> linus-5.2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb
>> git bisect good d4df33b0e9925c158b313a586fb1557cf29cfdf4
>> # good: [f90b8fda3a9d72a9422ea80ae95843697f94ea4a] ARM: dts: gemini:
>> Set DIR-685 SPI CS as active low
>> git bisect good f90b8fda3a9d72a9422ea80ae95843697f94ea4a
>> # good: [31cc088a4f5d83481c6f5041bd6eb06115b974af] Merge tag 'drm-
>> next-2019-07-19' of git://anongit.freedesktop.org/drm/drm
>> git bisect good 31cc088a4f5d83481c6f5041bd6eb06115b974af
>> # good: [ad21a4ce040cc41b4a085417169b558e86af56b7] dt-bindings:
>> pinctrl: aspeed: Fix 'compatible' schema errors
>> git bisect good ad21a4ce040cc41b4a085417169b558e86af56b7
>> # good: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch
>> 'core-urgent-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> git bisect good e6023adc5c6af79ac8ac5b17939f58091fa0d870
>> # bad: [ac60602a6d8f6830dee89f4b87ee005f62eb7171] Merge tag 'dma-
>> mapping-5.3-1' of git://git.infradead.org/users/hch/dma-mapping
>> git bisect bad ac60602a6d8f6830dee89f4b87ee005f62eb7171
>> # good: [6e67d77d673d785631b0c52314b60d3c68ebe809] perf vendor events
>> s390: Add JSON files for machine type 8561
>> git bisect good 6e67d77d673d785631b0c52314b60d3c68ebe809
>> # good: [a0d14b8909de55139b8702fe0c7e80b69763dcfb] x86/mm, tracing:
>> Fix CR2 corruption
>> git bisect good a0d14b8909de55139b8702fe0c7e80b69763dcfb
>> # good: [6879298bd0673840cadd1fb36d7225485504ceb4] x86/entry/64:
>> Prevent clobbering of saved CR2 value
>> git bisect good 6879298bd0673840cadd1fb36d7225485504ceb4
>> # good: [449fa54d6815be8c2c1f68fa9dbbae9384a7c03e] dma-direct:
>> correct the physical addr in dma_direct_sync_sg_for_cpu/device
>> git bisect good 449fa54d6815be8c2c1f68fa9dbbae9384a7c03e
>> # good: [e0c5c5e308ee9b3548844f0d88da937782b895ef] Merge tag 'perf-
>> core-for-mingo-5.3-20190715' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
>> perf/urgent
>> git bisect good e0c5c5e308ee9b3548844f0d88da937782b895ef
>> # good: [c6dd78fcb8eefa15dd861889e0f59d301cb5230c] Merge branch 'x86-
>> urgent-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> git bisect good c6dd78fcb8eefa15dd861889e0f59d301cb5230c
>> # first bad commit: [ac60602a6d8f6830dee89f4b87ee005f62eb7171] Merge
>> tag 'dma-mapping-5.3-1' of git://git.infradead.org/users/hch/dma-
>> mapping
>>
>> ---------
>> ppc/ppc64 bisect log
>>
>> # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
>> # good: [abdfd52a295fb5731ab07b5c9013e2e39f4d1cbe] Merge tag 'armsoc-
>> defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>> git bisect start 'HEAD' 'abdfd52a295f'
>> # bad: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch 'core-
>> urgent-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> git bisect bad e6023adc5c6af79ac8ac5b17939f58091fa0d870
>> # bad: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag 'scsi-
>> fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>> git bisect bad f65420df914a85e33b2c8b1cab310858b2abb7c0
>> # good: [168c79971b4a7be7011e73bf488b740a8e1135c8] Merge tag 'kbuild-
>> v5.3-2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
>> git bisect good 168c79971b4a7be7011e73bf488b740a8e1135c8
>> # good: [106d45f350c7cac876844dc685845cba4ffdb70b] scsi: zfcp: fix
>> request object use-after-free in send path causing wrong traces
>> git bisect good 106d45f350c7cac876844dc685845cba4ffdb70b
>> # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take
>> the DMA max mapping size into account
>> git bisect good bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
>> # good: [09a4460ba4434ef0327cd26bf25f2d7afb973251] scsi: IB/iser: set
>> virt_boundary_mask in the scsi host
>> git bisect good 09a4460ba4434ef0327cd26bf25f2d7afb973251
>> # good: [ce0ad853109733d772d26224297fda0de313bf13] scsi: mpt3sas: set
>> an unlimited max_segment_size for SAS 3.0 HBAs
>> git bisect good ce0ad853109733d772d26224297fda0de313bf13
>> # good: [07d9aa14346489d6facae5777ceb267a1dcadbc5] scsi:
>> megaraid_sas: set an unlimited max_segment_size
>> git bisect good 07d9aa14346489d6facae5777ceb267a1dcadbc5
>> # first bad commit: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge
>> tag 'scsi-fixes' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> 
> When a bisect lands on a merge commit it usually indicates bad
> interaction between two trees.  The way to find it is to do a bisect,
> but merge up to the other side of the scsi-fixes pull before running
> tests so the interaction is exposed in the bisect.
> 

Can you provide instructions for dummies ?

> However my money is on:
> 
> 
> commit bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
> Author: Christoph Hellwig <hch@lst.de>
> Date:   Mon Jun 17 14:19:54 2019 +0200
> 
>      scsi: core: take the DMA max mapping size into account
>   
> Now that I look at the code again:
> 
> 
> +       shost->max_sectors = min_t(unsigned int, shost->max_sectors,
> +                       dma_max_mapping_size(dev) << SECTOR_SHIFT);
> 
> That shift looks to be the wrong way around (should be >>).  I bet
> something is giving a very large number which becomes zero on left
> shift, meaning max_sectors gets set to zero.
> 

That does indeed look bad, but changing it doesn't make a difference.

Thanks,
Guenter

Re: Linux 5.3-rc1

[James Bottomley]

On Mon, 2019-07-22 at 19:42 -0700, Guenter Roeck wrote:
> On 7/22/19 4:45 PM, James Bottomley wrote:
> > [linux-scsi added to cc]
> > On Mon, 2019-07-22 at 15:21 -0700, Guenter Roeck wrote:
> > > On Sun, Jul 21, 2019 at 02:33:38PM -0700, Linus Torvalds wrote:
> > > 
> > > [ ... ]
> > > > 
> > > > Go test,
> > > > 
> > > 
> > > Things looked pretty good until a few days ago. Unfortunately,
> > > the last few days brought in a couple of issues.
> > > 
> > > riscv:virt:defconfig:scsi[virtio]
> > > riscv:virt:defconfig:scsi[virtio-pci]
> > > 
> > > Boot tests crash with no useful backtrace. Bisect points to
> > > merge ac60602a6d8f ("Merge tag 'dma-mapping-5.3-1'"). Log is at
> > > https://kerneltests.org/builders/qemu-riscv64-master/builds/238/s
> > > teps
> > > /qemubuildcommand_1/logs/stdio
> > > 
> > > ppc:mpc8544ds:mpc85xx_defconfig:sata-sii3112
> > > ppc64:pseries:pseries_defconfig:sata-sii3112
> > > ppc64:pseries:pseries_defconfig:little:sata-sii3112
> > > ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112
> > > 
> > > ata1: lost interrupt (Status 0x50)
> > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> > > ata1.00: failed command: READ DMA
> > > 
> > > and many similar errors. Boot ultimately times out. Bisect points
> > > to
> > > merge
> > > f65420df914a ("Merge tag 'scsi-fixes'").
> > > 
> > > Logs:
> > > https://kerneltests.org/builders/qemu-ppc64-master/builds/1212/st
> > > eps/
> > > qemubuildcommand/logs/stdio
> > > https://kerneltests.org/builders/qemu-ppc-master/builds/1255/step
> > > s/qe
> > > mubuildcommand/logs/stdio
> > > 
> > > Guenter
> > > 
> > > ---
> > > riscv bisect log
> > > 
> > > # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
> > > # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core:
> > > take
> > > the DMA max mapping size into account
> > > git bisect start 'HEAD' 'bdd17bdef7d8'
> > > # good: [237f83dfbe668443b5e31c3c7576125871cca674] Merge
> > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> > > git bisect good 237f83dfbe668443b5e31c3c7576125871cca674
> > > # good: [be8454afc50f43016ca8b6130d9673bdd0bd56ec] Merge tag
> > > 'drm-
> > > next-2019-07-16' of git://anongit.freedesktop.org/drm/drm
> > > git bisect good be8454afc50f43016ca8b6130d9673bdd0bd56ec
> > > # good: [d4df33b0e9925c158b313a586fb1557cf29cfdf4] Merge branch
> > > 'for-
> > > linus-5.2' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb
> > > git bisect good d4df33b0e9925c158b313a586fb1557cf29cfdf4
> > > # good: [f90b8fda3a9d72a9422ea80ae95843697f94ea4a] ARM: dts:
> > > gemini:
> > > Set DIR-685 SPI CS as active low
> > > git bisect good f90b8fda3a9d72a9422ea80ae95843697f94ea4a
> > > # good: [31cc088a4f5d83481c6f5041bd6eb06115b974af] Merge tag
> > > 'drm-
> > > next-2019-07-19' of git://anongit.freedesktop.org/drm/drm
> > > git bisect good 31cc088a4f5d83481c6f5041bd6eb06115b974af
> > > # good: [ad21a4ce040cc41b4a085417169b558e86af56b7] dt-bindings:
> > > pinctrl: aspeed: Fix 'compatible' schema errors
> > > git bisect good ad21a4ce040cc41b4a085417169b558e86af56b7
> > > # good: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch
> > > 'core-urgent-for-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> > > git bisect good e6023adc5c6af79ac8ac5b17939f58091fa0d870
> > > # bad: [ac60602a6d8f6830dee89f4b87ee005f62eb7171] Merge tag 'dma-
> > > mapping-5.3-1' of git://git.infradead.org/users/hch/dma-mapping
> > > git bisect bad ac60602a6d8f6830dee89f4b87ee005f62eb7171
> > > # good: [6e67d77d673d785631b0c52314b60d3c68ebe809] perf vendor
> > > events
> > > s390: Add JSON files for machine type 8561
> > > git bisect good 6e67d77d673d785631b0c52314b60d3c68ebe809
> > > # good: [a0d14b8909de55139b8702fe0c7e80b69763dcfb] x86/mm,
> > > tracing:
> > > Fix CR2 corruption
> > > git bisect good a0d14b8909de55139b8702fe0c7e80b69763dcfb
> > > # good: [6879298bd0673840cadd1fb36d7225485504ceb4] x86/entry/64:
> > > Prevent clobbering of saved CR2 value
> > > git bisect good 6879298bd0673840cadd1fb36d7225485504ceb4
> > > # good: [449fa54d6815be8c2c1f68fa9dbbae9384a7c03e] dma-direct:
> > > correct the physical addr in dma_direct_sync_sg_for_cpu/device
> > > git bisect good 449fa54d6815be8c2c1f68fa9dbbae9384a7c03e
> > > # good: [e0c5c5e308ee9b3548844f0d88da937782b895ef] Merge tag
> > > 'perf-
> > > core-for-mingo-5.3-20190715' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
> > > perf/urgent
> > > git bisect good e0c5c5e308ee9b3548844f0d88da937782b895ef
> > > # good: [c6dd78fcb8eefa15dd861889e0f59d301cb5230c] Merge branch
> > > 'x86-
> > > urgent-for-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> > > git bisect good c6dd78fcb8eefa15dd861889e0f59d301cb5230c
> > > # first bad commit: [ac60602a6d8f6830dee89f4b87ee005f62eb7171]
> > > Merge
> > > tag 'dma-mapping-5.3-1' of git://git.infradead.org/users/hch/dma-
> > > mapping
> > > 
> > > ---------
> > > ppc/ppc64 bisect log
> > > 
> > > # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
> > > # good: [abdfd52a295fb5731ab07b5c9013e2e39f4d1cbe] Merge tag
> > > 'armsoc-
> > > defconfig' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> > > git bisect start 'HEAD' 'abdfd52a295f'
> > > # bad: [e6023adc5c6af79ac8ac5b17939f58091fa0d870] Merge branch
> > > 'core-
> > > urgent-for-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> > > git bisect bad e6023adc5c6af79ac8ac5b17939f58091fa0d870
> > > # bad: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag
> > > 'scsi-
> > > fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> > > git bisect bad f65420df914a85e33b2c8b1cab310858b2abb7c0
> > > # good: [168c79971b4a7be7011e73bf488b740a8e1135c8] Merge tag
> > > 'kbuild-
> > > v5.3-2' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-
> > > kbuild
> > > git bisect good 168c79971b4a7be7011e73bf488b740a8e1135c8
> > > # good: [106d45f350c7cac876844dc685845cba4ffdb70b] scsi: zfcp:
> > > fix
> > > request object use-after-free in send path causing wrong traces
> > > git bisect good 106d45f350c7cac876844dc685845cba4ffdb70b
> > > # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core:
> > > take
> > > the DMA max mapping size into account
> > > git bisect good bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
> > > # good: [09a4460ba4434ef0327cd26bf25f2d7afb973251] scsi: IB/iser:
> > > set
> > > virt_boundary_mask in the scsi host
> > > git bisect good 09a4460ba4434ef0327cd26bf25f2d7afb973251
> > > # good: [ce0ad853109733d772d26224297fda0de313bf13] scsi: mpt3sas:
> > > set
> > > an unlimited max_segment_size for SAS 3.0 HBAs
> > > git bisect good ce0ad853109733d772d26224297fda0de313bf13
> > > # good: [07d9aa14346489d6facae5777ceb267a1dcadbc5] scsi:
> > > megaraid_sas: set an unlimited max_segment_size
> > > git bisect good 07d9aa14346489d6facae5777ceb267a1dcadbc5
> > > # first bad commit: [f65420df914a85e33b2c8b1cab310858b2abb7c0]
> > > Merge
> > > tag 'scsi-fixes' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> > 
> > When a bisect lands on a merge commit it usually indicates bad
> > interaction between two trees.  The way to find it is to do a
> > bisect,
> > but merge up to the other side of the scsi-fixes pull before
> > running
> > tests so the interaction is exposed in the bisect.
> > 
> 
> Can you provide instructions for dummies ?

do a man git-bisect and then follow the 'Automatically bisect with
temporary modifications' example.  You substitute
168c79971b4a7be7011e73bf488b740a8e1135c8 for hot-fix

> > However my money is on:
> > 
> > 
> > commit bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
> > Author: Christoph Hellwig <hch@lst.de>
> > Date:   Mon Jun 17 14:19:54 2019 +0200
> > 
> >      scsi: core: take the DMA max mapping size into account
> >   
> > Now that I look at the code again:
> > 
> > 
> > +       shost->max_sectors = min_t(unsigned int, shost-
> > >max_sectors,
> > +                       dma_max_mapping_size(dev) << SECTOR_SHIFT);
> > 
> > That shift looks to be the wrong way around (should be >>).  I bet
> > something is giving a very large number which becomes zero on left
> > shift, meaning max_sectors gets set to zero.
> > 
> 
> That does indeed look bad, but changing it doesn't make a difference.

Odd, all the other changes are driver specific (and not in ATA) apart
from this one:

commit 7ad388d8e4c703980b7018b938cdeec58832d78d
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 17 14:19:53 2019 +0200

    scsi: core: add a host / host template field for the virt boundary
 

I suppose it could be because the virt_boundary_mask isn't set, but
that should just set zero, which is what block usually does.

James

Re: Linux 5.3-rc1

[Steffen Maier]

On 7/23/19 7:28 AM, James Bottomley wrote:
> On Mon, 2019-07-22 at 19:42 -0700, Guenter Roeck wrote:
>> On 7/22/19 4:45 PM, James Bottomley wrote:
>>> [linux-scsi added to cc]
>>> On Mon, 2019-07-22 at 15:21 -0700, Guenter Roeck wrote:
>>>> On Sun, Jul 21, 2019 at 02:33:38PM -0700, Linus Torvalds wrote:
>>>>
>>>> [ ... ]
>>>>>
>>>>> Go test,
>>>>>
>>>>
>>>> Things looked pretty good until a few days ago. Unfortunately,
>>>> the last few days brought in a couple of issues.
>>>>
>>>> riscv:virt:defconfig:scsi[virtio]
>>>> riscv:virt:defconfig:scsi[virtio-pci]
>>>>
>>>> Boot tests crash with no useful backtrace. Bisect points to
>>>> merge ac60602a6d8f ("Merge tag 'dma-mapping-5.3-1'"). Log is at
>>>> https://kerneltests.org/builders/qemu-riscv64-master/builds/238/s
>>>> teps
>>>> /qemubuildcommand_1/logs/stdio
>>>>
>>>> ppc:mpc8544ds:mpc85xx_defconfig:sata-sii3112
>>>> ppc64:pseries:pseries_defconfig:sata-sii3112
>>>> ppc64:pseries:pseries_defconfig:little:sata-sii3112
>>>> ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112
>>>>
>>>> ata1: lost interrupt (Status 0x50)
>>>> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>>>> ata1.00: failed command: READ DMA
>>>>
>>>> and many similar errors. Boot ultimately times out. Bisect points
>>>> to
>>>> merge
>>>> f65420df914a ("Merge tag 'scsi-fixes'").
>>>>
>>>> Logs:
>>>> https://kerneltests.org/builders/qemu-ppc64-master/builds/1212/st
>>>> eps/
>>>> qemubuildcommand/logs/stdio
>>>> https://kerneltests.org/builders/qemu-ppc-master/builds/1255/step
>>>> s/qe
>>>> mubuildcommand/logs/stdio
>>>>
>>>> Guenter
>>>>
>>>> ---
>>>> riscv bisect log
>>>>
>>>> # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
>>>> # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core:
>>>> take
>>>> the DMA max mapping size into account

>>>> # first bad commit: [ac60602a6d8f6830dee89f4b87ee005f62eb7171]
>>>> Merge
>>>> tag 'dma-mapping-5.3-1' of git://git.infradead.org/users/hch/dma-
>>>> mapping

>>> When a bisect lands on a merge commit it usually indicates bad
>>> interaction between two trees.  The way to find it is to do a
>>> bisect,
>>> but merge up to the other side of the scsi-fixes pull before
>>> running
>>> tests so the interaction is exposed in the bisect.
>>>
>>
>> Can you provide instructions for dummies ?
> 
> do a man git-bisect and then follow the 'Automatically bisect with
> temporary modifications' example.  You substitute
> 168c79971b4a7be7011e73bf488b740a8e1135c8 for hot-fix
> 
>>> However my money is on:
>>>
>>>
>>> commit bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
>>> Author: Christoph Hellwig <hch@lst.de>
>>> Date:   Mon Jun 17 14:19:54 2019 +0200
>>>
>>>       scsi: core: take the DMA max mapping size into account
>>>    
>>> Now that I look at the code again:
>>>
>>>
>>> +       shost->max_sectors = min_t(unsigned int, shost-
>>>> max_sectors,
>>> +                       dma_max_mapping_size(dev) << SECTOR_SHIFT);
>>>
>>> That shift looks to be the wrong way around (should be >>).  I bet
>>> something is giving a very large number which becomes zero on left
>>> shift, meaning max_sectors gets set to zero.
>>>
>>
>> That does indeed look bad, but changing it doesn't make a difference.
> 
> Odd, all the other changes are driver specific (and not in ATA) apart
> from this one:
> 
> commit 7ad388d8e4c703980b7018b938cdeec58832d78d
> Author: Christoph Hellwig <hch@lst.de>
> Date:   Mon Jun 17 14:19:53 2019 +0200
> 
>      scsi: core: add a host / host template field for the virt boundary
> 
> 
> I suppose it could be because the virt_boundary_mask isn't set, but
> that should just set zero, which is what block usually does.

I found max_segment_size unexpectedly to be UINT_MAX with zfcp today in our CI. 
My investigations are still very early, but I thought, I share a few thoughts 
as I'm way too unfamiliar with the DMA business and thus hope for help.

Above commit introduced an unconditional call to blk_queue_virt_boundary(q, 
shost->virt_boundary_mask), _after_ blk_queue_max_segment_size(q, 
shost->max_segment_size).

Looking at the source, dma_set_max_seg_size() seems to unconditionally 
overwrite max_segment_size:

> /**
>  * blk_queue_virt_boundary - set boundary rules for bio merging
>  * @q:  the request queue for the device
>  * @mask:  the memory boundary mask
>  **/
> void blk_queue_virt_boundary(struct request_queue *q, unsigned long mask)
> {
> 	q->limits.virt_boundary_mask = mask;
> 
> 	/*
> 	 * Devices that require a virtual boundary do not support scatter/gather
> 	 * I/O natively, but instead require a descriptor list entry for each
> 	 * page (which might not be idential to the Linux PAGE_SIZE).  Because
> 	 * of that they are not limited by our notion of "segment size".
> 	 */
> 	q->limits.max_segment_size = UINT_MAX;
> }
> EXPORT_SYMBOL(blk_queue_virt_boundary);

Wild guess: Do we need to make the call to blk_queue_virt_boundary() conditional?

Cf. https://www.spinics.net/lists/linux-scsi/msg131077.html ("[PATCH v2] iser: 
explicitly set shost max_segment_size if non virtual boundary devices")

-- 
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: Linux 5.3-rc1

[James Bottomley]

On Tue, 2019-07-23 at 16:25 +0200, Steffen Maier wrote:
> On 7/23/19 7:28 AM, James Bottomley wrote:
> > On Mon, 2019-07-22 at 19:42 -0700, Guenter Roeck wrote:
> > > On 7/22/19 4:45 PM, James Bottomley wrote:
> > > > [linux-scsi added to cc]
> > > > On Mon, 2019-07-22 at 15:21 -0700, Guenter Roeck wrote:
> > > > > On Sun, Jul 21, 2019 at 02:33:38PM -0700, Linus Torvalds
> > > > > wrote:
> > > > > 
> > > > > [ ... ]
> > > > > > 
> > > > > > Go test,
> > > > > > 
> > > > > 
> > > > > Things looked pretty good until a few days ago.
> > > > > Unfortunately,
> > > > > the last few days brought in a couple of issues.
> > > > > 
> > > > > riscv:virt:defconfig:scsi[virtio]
> > > > > riscv:virt:defconfig:scsi[virtio-pci]
> > > > > 
> > > > > Boot tests crash with no useful backtrace. Bisect points to
> > > > > merge ac60602a6d8f ("Merge tag 'dma-mapping-5.3-1'"). Log is
> > > > > at
> > > > > https://kerneltests.org/builders/qemu-riscv64-master/builds/2
> > > > > 38/s
> > > > > teps
> > > > > /qemubuildcommand_1/logs/stdio
> > > > > 
> > > > > ppc:mpc8544ds:mpc85xx_defconfig:sata-sii3112
> > > > > ppc64:pseries:pseries_defconfig:sata-sii3112
> > > > > ppc64:pseries:pseries_defconfig:little:sata-sii3112
> > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112
> > > > > 
> > > > > ata1: lost interrupt (Status 0x50)
> > > > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> > > > > frozen
> > > > > ata1.00: failed command: READ DMA
> > > > > 
> > > > > and many similar errors. Boot ultimately times out. Bisect
> > > > > points
> > > > > to
> > > > > merge
> > > > > f65420df914a ("Merge tag 'scsi-fixes'").
> > > > > 
> > > > > Logs:
> > > > > https://kerneltests.org/builders/qemu-ppc64-master/builds/121
> > > > > 2/st
> > > > > eps/
> > > > > qemubuildcommand/logs/stdio
> > > > > https://kerneltests.org/builders/qemu-ppc-master/builds/1255/
> > > > > step
> > > > > s/qe
> > > > > mubuildcommand/logs/stdio
> > > > > 
> > > > > Guenter
> > > > > 
> > > > > ---
> > > > > riscv bisect log
> > > > > 
> > > > > # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-
> > > > > rc1
> > > > > # good: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi:
> > > > > core:
> > > > > take
> > > > > the DMA max mapping size into account
> > > > > # first bad commit:
> > > > > [ac60602a6d8f6830dee89f4b87ee005f62eb7171]
> > > > > Merge
> > > > > tag 'dma-mapping-5.3-1' of
> > > > > git://git.infradead.org/users/hch/dma-
> > > > > mapping
> > > > When a bisect lands on a merge commit it usually indicates bad
> > > > interaction between two trees.  The way to find it is to do a
> > > > bisect,
> > > > but merge up to the other side of the scsi-fixes pull before
> > > > running
> > > > tests so the interaction is exposed in the bisect.
> > > > 
> > > 
> > > Can you provide instructions for dummies ?
> > 
> > do a man git-bisect and then follow the 'Automatically bisect with
> > temporary modifications' example.  You substitute
> > 168c79971b4a7be7011e73bf488b740a8e1135c8 for hot-fix
> > 
> > > > However my money is on:
> > > > 
> > > > 
> > > > commit bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
> > > > Author: Christoph Hellwig <hch@lst.de>
> > > > Date:   Mon Jun 17 14:19:54 2019 +0200
> > > > 
> > > >       scsi: core: take the DMA max mapping size into account
> > > >    
> > > > Now that I look at the code again:
> > > > 
> > > > 
> > > > +       shost->max_sectors = min_t(unsigned int, shost-
> > > > > max_sectors,
> > > > 
> > > > +                       dma_max_mapping_size(dev) <<
> > > > SECTOR_SHIFT);
> > > > 
> > > > That shift looks to be the wrong way around (should be >>).  I
> > > > bet
> > > > something is giving a very large number which becomes zero on
> > > > left
> > > > shift, meaning max_sectors gets set to zero.
> > > > 
> > > 
> > > That does indeed look bad, but changing it doesn't make a
> > > difference.
> > 
> > Odd, all the other changes are driver specific (and not in ATA)
> > apart
> > from this one:
> > 
> > commit 7ad388d8e4c703980b7018b938cdeec58832d78d
> > Author: Christoph Hellwig <hch@lst.de>
> > Date:   Mon Jun 17 14:19:53 2019 +0200
> > 
> >      scsi: core: add a host / host template field for the virt
> > boundary
> > 
> > 
> > I suppose it could be because the virt_boundary_mask isn't set, but
> > that should just set zero, which is what block usually does.
> 
> I found max_segment_size unexpectedly to be UINT_MAX with zfcp today
> in our CI. 
> My investigations are still very early, but I thought, I share a few
> thoughts 
> as I'm way too unfamiliar with the DMA business and thus hope for
> help.
> 
> Above commit introduced an unconditional call to
> blk_queue_virt_boundary(q, 
> shost->virt_boundary_mask), _after_ blk_queue_max_segment_size(q, 
> shost->max_segment_size).
> 
> Looking at the source, dma_set_max_seg_size() seems to
> unconditionally 
> overwrite max_segment_size:
> 
> > /**
> >  * blk_queue_virt_boundary - set boundary rules for bio merging
> >  * @q:  the request queue for the device
> >  * @mask:  the memory boundary mask
> >  **/
> > void blk_queue_virt_boundary(struct request_queue *q, unsigned long
> > mask)
> > {
> > 	q->limits.virt_boundary_mask = mask;
> > 
> > 	/*
> > 	 * Devices that require a virtual boundary do not support
> > scatter/gather
> > 	 * I/O natively, but instead require a descriptor list entry
> > for each
> > 	 * page (which might not be idential to the Linux
> > PAGE_SIZE).  Because
> > 	 * of that they are not limited by our notion of "segment
> > size".
> > 	 */
> > 	q->limits.max_segment_size = UINT_MAX;
> > }
> > EXPORT_SYMBOL(blk_queue_virt_boundary);
> 
> Wild guess: Do we need to make the call to blk_queue_virt_boundary()
> conditional?
> 
> Cf. https://www.spinics.net/lists/linux-scsi/msg131077.html ("[PATCH
> v2] iser: 
> explicitly set shost max_segment_size if non virtual boundary
> devices")
> 

Yes, I think so.  Can someone try this, or something like it.

Thanks,

James

---

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9381171c2fc0..4715671a1537 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
 	dma_set_seg_boundary(dev, shost->dma_boundary);
 
 	blk_queue_max_segment_size(q, shost->max_segment_size);
-	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
+	if (shost->virt_boundary_mask)
+		blk_queue_virt_boundary(q, shost->virt_boundary_mask);
 	dma_set_max_seg_size(dev, queue_max_segment_size(q));
 
 	/*

Re: Linux 5.3-rc1

[Guenter Roeck]

On Tue, Jul 23, 2019 at 08:33:15AM -0700, James Bottomley wrote:
[ ... ]
> 
> Yes, I think so.  Can someone try this, or something like it.
> 
> Thanks,
> 
> James
> 
> ---
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9381171c2fc0..4715671a1537 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
>  	dma_set_seg_boundary(dev, shost->dma_boundary);
>  
>  	blk_queue_max_segment_size(q, shost->max_segment_size);
> -	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
> +	if (shost->virt_boundary_mask)
> +		blk_queue_virt_boundary(q, shost->virt_boundary_mask);
>  	dma_set_max_seg_size(dev, queue_max_segment_size(q));
>  
>  	/*

This fixes the problem for me.

Guenter

Re: Linux 5.3-rc1

[James Bottomley]

On Tue, 2019-07-23 at 09:19 -0700, Guenter Roeck wrote:
> On Tue, Jul 23, 2019 at 08:33:15AM -0700, James Bottomley wrote:
> [ ... ]
> > 
> > Yes, I think so.  Can someone try this, or something like it.
> > 
> > Thanks,
> > 
> > James
> > 
> > ---
> > 
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index 9381171c2fc0..4715671a1537 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host
> > *shost, struct request_queue *q)
> >  	dma_set_seg_boundary(dev, shost->dma_boundary);
> >  
> >  	blk_queue_max_segment_size(q, shost->max_segment_size);
> > -	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
> > +	if (shost->virt_boundary_mask)
> > +		blk_queue_virt_boundary(q, shost-
> > >virt_boundary_mask);
> >  	dma_set_max_seg_size(dev, queue_max_segment_size(q));
> >  
> >  	/*
> 
> This fixes the problem for me.

Great, thanks!

I'm thinking this is the more correct fix:

https://lore.kernel.org/linux-block/1563896932.3609.15.camel@HansenPartnership.com/

But we'll see what Jens says.

James

Re: Linux 5.3-rc1

[Guenter Roeck]

On Tue, Jul 23, 2019 at 09:23:34AM -0700, James Bottomley wrote:
> On Tue, 2019-07-23 at 09:19 -0700, Guenter Roeck wrote:
> > On Tue, Jul 23, 2019 at 08:33:15AM -0700, James Bottomley wrote:
> > [ ... ]
> > > 
> > > Yes, I think so.  Can someone try this, or something like it.
> > > 
> > > Thanks,
> > > 
> > > James
> > > 
> > > ---
> > > 
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index 9381171c2fc0..4715671a1537 100644
> > > --- a/drivers/scsi/scsi_lib.c
> > > +++ b/drivers/scsi/scsi_lib.c
> > > @@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host
> > > *shost, struct request_queue *q)
> > >  	dma_set_seg_boundary(dev, shost->dma_boundary);
> > >  
> > >  	blk_queue_max_segment_size(q, shost->max_segment_size);
> > > -	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
> > > +	if (shost->virt_boundary_mask)
> > > +		blk_queue_virt_boundary(q, shost-
> > > >virt_boundary_mask);
> > >  	dma_set_max_seg_size(dev, queue_max_segment_size(q));
> > >  
> > >  	/*
> > 
> > This fixes the problem for me.
> 
> Great, thanks!
> 
> I'm thinking this is the more correct fix:
> 
> https://lore.kernel.org/linux-block/1563896932.3609.15.camel@HansenPartnership.com/
> 
> But we'll see what Jens says.

Yes, that patch also fixes the problem with sata-sii3112.

Guenter

> 
> James
> 

Re: Linux 5.3-rc1

[Steffen Maier]

On 7/23/19 6:19 PM, Guenter Roeck wrote:
> On Tue, Jul 23, 2019 at 08:33:15AM -0700, James Bottomley wrote:
> [ ... ]
>>
>> Yes, I think so.  Can someone try this, or something like it.
>>
>> Thanks,
>>
>> James
>>
>> ---
>>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 9381171c2fc0..4715671a1537 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
>>   	dma_set_seg_boundary(dev, shost->dma_boundary);
>>   
>>   	blk_queue_max_segment_size(q, shost->max_segment_size);
>> -	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
>> +	if (shost->virt_boundary_mask)
>> +		blk_queue_virt_boundary(q, shost->virt_boundary_mask);
>>   	dma_set_max_seg_size(dev, queue_max_segment_size(q));
>>   
>>   	/*
> 
> This fixes the problem for me.

+1
(on a first glimpse with zfcp)


-- 
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: Linux 5.3-rc1

[Christoph Hellwig]

The fix was sent last morning my time:

https://marc.info/?l=linux-scsi&m=156378725427719&w=2

Re: Linux 5.3-rc1

[Guenter Roeck]

On 7/22/19 10:48 PM, Christoph Hellwig wrote:
> The fix was sent last morning my time:
> 
> https://marc.info/?l=linux-scsi&m=156378725427719&w=2
> 

That patch does not fix the problem observed with sata-sii3112.
It does, however, fix the problem observed with riscv64, suggesting
some interaction between the scsi-fixes merge and the dma-mapping
merge.

I am still bisecting the sata-sii3112 failure using the method
suggested by James. I'll report results when available.

Guenter

Re: Linux 5.3-rc1

[Guenter Roeck]

On Tue, Jul 23, 2019 at 07:48:41AM +0200, Christoph Hellwig wrote:
> The fix was sent last morning my time:
> 
> https://marc.info/?l=linux-scsi&m=156378725427719&w=2

Here is the updated bisect for the ppc scsi problem.

Guenter

---
# bad: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
# good: [168c79971b4a7be7011e73bf488b740a8e1135c8] Merge tag 'kbuild-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
git bisect start 'f65420df914a' '168c79971b4a'
# good: [106d45f350c7cac876844dc685845cba4ffdb70b] scsi: zfcp: fix request object use-after-free in send path causing wrong traces
git bisect good 106d45f350c7cac876844dc685845cba4ffdb70b
# bad: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take the DMA max mapping size into account
git bisect bad bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
# good: [0cdc58580b37a160fac4b884266b8b7cb096f539] scsi: sd_zbc: Fix compilation warning
git bisect good 0cdc58580b37a160fac4b884266b8b7cb096f539
# bad: [7ad388d8e4c703980b7018b938cdeec58832d78d] scsi: core: add a host / host template field for the virt boundary
git bisect bad 7ad388d8e4c703980b7018b938cdeec58832d78d
# good: [f9b0530fa02e0c73f31a49ef743e8f44eb8e32cc] scsi: core: Fix race on creating sense cache
git bisect good f9b0530fa02e0c73f31a49ef743e8f44eb8e32cc
# first bad commit: [7ad388d8e4c703980b7018b938cdeec58832d78d] scsi: core: add a host / host template field for the virt boundary

Re: Linux 5.3-rc1

[James Bottomley]

On Tue, 2019-07-23 at 07:58 -0700, Guenter Roeck wrote:
> On Tue, Jul 23, 2019 at 07:48:41AM +0200, Christoph Hellwig wrote:
> > The fix was sent last morning my time:
> > 
> > https://marc.info/?l=linux-scsi&m=156378725427719&w=2
> 
> Here is the updated bisect for the ppc scsi problem.
> 
> Guenter
> 
> ---
> # bad: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag 'scsi-
> fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> # good: [168c79971b4a7be7011e73bf488b740a8e1135c8] Merge tag 'kbuild-
> v5.3-2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
> git bisect start 'f65420df914a' '168c79971b4a'
> # good: [106d45f350c7cac876844dc685845cba4ffdb70b] scsi: zfcp: fix
> request object use-after-free in send path causing wrong traces
> git bisect good 106d45f350c7cac876844dc685845cba4ffdb70b
> # bad: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take
> the DMA max mapping size into account
> git bisect bad bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
> # good: [0cdc58580b37a160fac4b884266b8b7cb096f539] scsi: sd_zbc: Fix
> compilation warning
> git bisect good 0cdc58580b37a160fac4b884266b8b7cb096f539
> # bad: [7ad388d8e4c703980b7018b938cdeec58832d78d] scsi: core: add a
> host / host template field for the virt boundary
> git bisect bad 7ad388d8e4c703980b7018b938cdeec58832d78d
> # good: [f9b0530fa02e0c73f31a49ef743e8f44eb8e32cc] scsi: core: Fix
> race on creating sense cache
> git bisect good f9b0530fa02e0c73f31a49ef743e8f44eb8e32cc
> # first bad commit: [7ad388d8e4c703980b7018b938cdeec58832d78d] scsi:
> core: add a host / host template field for the virt boundary

And reverting that commit fixes your problem?

James

Re: Linux 5.3-rc1

[Guenter Roeck]

On Tue, Jul 23, 2019 at 08:14:21AM -0700, James Bottomley wrote:
> On Tue, 2019-07-23 at 07:58 -0700, Guenter Roeck wrote:
> > On Tue, Jul 23, 2019 at 07:48:41AM +0200, Christoph Hellwig wrote:
> > > The fix was sent last morning my time:
> > > 
> > > https://marc.info/?l=linux-scsi&m=156378725427719&w=2
> > 
> > Here is the updated bisect for the ppc scsi problem.
> > 
> > Guenter
> > 
> > ---
> > # bad: [f65420df914a85e33b2c8b1cab310858b2abb7c0] Merge tag 'scsi-
> > fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> > # good: [168c79971b4a7be7011e73bf488b740a8e1135c8] Merge tag 'kbuild-
> > v5.3-2' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
> > git bisect start 'f65420df914a' '168c79971b4a'
> > # good: [106d45f350c7cac876844dc685845cba4ffdb70b] scsi: zfcp: fix
> > request object use-after-free in send path causing wrong traces
> > git bisect good 106d45f350c7cac876844dc685845cba4ffdb70b
> > # bad: [bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1] scsi: core: take
> > the DMA max mapping size into account
> > git bisect bad bdd17bdef7d8da4d8eee254abb4c92d8a566bdc1
> > # good: [0cdc58580b37a160fac4b884266b8b7cb096f539] scsi: sd_zbc: Fix
> > compilation warning
> > git bisect good 0cdc58580b37a160fac4b884266b8b7cb096f539
> > # bad: [7ad388d8e4c703980b7018b938cdeec58832d78d] scsi: core: add a
> > host / host template field for the virt boundary
> > git bisect bad 7ad388d8e4c703980b7018b938cdeec58832d78d
> > # good: [f9b0530fa02e0c73f31a49ef743e8f44eb8e32cc] scsi: core: Fix
> > race on creating sense cache
> > git bisect good f9b0530fa02e0c73f31a49ef743e8f44eb8e32cc
> > # first bad commit: [7ad388d8e4c703980b7018b938cdeec58832d78d] scsi:
> > core: add a host / host template field for the virt boundary
> 
> And reverting that commit fixes your problem?
> 
I didn't have time to try yet; I am still on my way to work.
I'll get back later with more info. Give me a couple of hours.

Guenter

Re: Linux 5.3-rc1

[Christoph Hellwig]

Does this fix the problem for you?

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9381171c2fc0..4715671a1537 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
 	dma_set_seg_boundary(dev, shost->dma_boundary);
 
 	blk_queue_max_segment_size(q, shost->max_segment_size);
-	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
+	if (shost->virt_boundary_mask)
+		blk_queue_virt_boundary(q, shost->virt_boundary_mask);
 	dma_set_max_seg_size(dev, queue_max_segment_size(q));
 
 	/*

Re: Linux 5.3-rc1

[Guenter Roeck]

On Tue, Jul 23, 2019 at 05:34:21PM +0200, Christoph Hellwig wrote:
> Does this fix the problem for you?
> 
I'll try. Give me a couple of hours. 

Guenter

> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9381171c2fc0..4715671a1537 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
>  	dma_set_seg_boundary(dev, shost->dma_boundary);
>  
>  	blk_queue_max_segment_size(q, shost->max_segment_size);
> -	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
> +	if (shost->virt_boundary_mask)
> +		blk_queue_virt_boundary(q, shost->virt_boundary_mask);
>  	dma_set_max_seg_size(dev, queue_max_segment_size(q));
>  
>  	/*

Re: Linux 5.3-rc1

[Guenter Roeck]

On Tue, Jul 23, 2019 at 05:34:21PM +0200, Christoph Hellwig wrote:
> Does this fix the problem for you?
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9381171c2fc0..4715671a1537 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1793,7 +1793,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
>  	dma_set_seg_boundary(dev, shost->dma_boundary);
>  
>  	blk_queue_max_segment_size(q, shost->max_segment_size);
> -	blk_queue_virt_boundary(q, shost->virt_boundary_mask);
> +	if (shost->virt_boundary_mask)
> +		blk_queue_virt_boundary(q, shost->virt_boundary_mask);
>  	dma_set_max_seg_size(dev, queue_max_segment_size(q));
>  
>  	/*

This fixes the problem for me.

Guenter

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

[Stephen Rothwell]

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

Hi all,

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

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

Commits in v5.3-rc1 (relative to v5.2):            12608
Commits in next-20190709:                          12256
Commits with the same SHA1:                        11291
Commits with the same patch_id:                      303 (1)
Commits with the same subject line:                   63 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20190709:     11657 92%

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

Top ten first word of commit summary:

     85 net
     78 docs
     64 perf
     61 drm
     39 kvm
     37 x86
     26 scsi
     24 kbuild
     23 selftests
     21 s390

Top ten authors:

     78 mchehab+samsung@kernel.org
     33 yamada.masahiro@socionext.com
     23 adrian.hunter@intel.com
     21 jpoimboe@redhat.com
     18 arnd@arndb.de
     18 acme@redhat.com
     15 iii@linux.ibm.com
     14 rui.zhang@intel.com
     14 pbonzini@redhat.com
     14 hoeppner@linux.ibm.com

Top ten commiters:

    157 davem@davemloft.net
     77 mchehab+samsung@kernel.org
     63 acme@redhat.com
     54 tglx@linutronix.de
     46 alexander.deucher@amd.com
     44 pbonzini@redhat.com
     34 yamada.masahiro@socionext.com
     29 rafael.j.wysocki@intel.com
     28 torvalds@linux-foundation.org
     26 daniel@iogearbox.net

There are also 599 commits in next-20190709 that didn't make it into
v5.3-rc1.

Top ten first word of commit summary:

    286 drm
     27 mm
     25 xtensa
     25 vfs
     24 arm
     21 pm
     11 nfc
      9 apparmor
      8 lib
      8 dt-bindings

Top ten authors:

     65 chris@chris-wilson.co.uk
     42 xiaojie.yuan@amd.com
     37 tvrtko.ursulin@intel.com
     29 dhowells@redhat.com
     23 imre.deak@intel.com
     21 jcmvbkbc@gmail.com
     21 james.qian.wang@arm.com
     21 akpm@linux-foundation.org
     19 olof@lixom.net
     16 digetx@gmail.com

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

Top ten commiters:

     95 sfr@canb.auug.org.au
     86 chris@chris-wilson.co.uk
     53 alexander.deucher@amd.com
     39 tvrtko.ursulin@intel.com
     38 liviu.dudau@arm.com
     35 viro@zeniv.linux.org.uk
     28 jcmvbkbc@gmail.com
     23 imre.deak@intel.com
     21 myungjoo.ham@samsung.com
     19 olof@lixom.net

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