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
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
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
[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 <[email protected]>
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
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 <[email protected]>
> > 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 <[email protected]>
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
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 <[email protected]>
> 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
The fix was sent last morning my time:
https://marc.info/?l=linux-scsi&m=156378725427719&w=2
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
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 <[email protected]>
>>> 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 <[email protected]>
> 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
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
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 <[email protected]>
> > > > 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 <[email protected]>
> > 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));
/*
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));
/*
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
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
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
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/[email protected]/
But we'll see what Jens says.
James
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
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/[email protected]/
>
> But we'll see what Jens says.
Yes, that patch also fixes the problem with sata-sii3112.
Guenter
>
> James
>
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
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));
>
> /*
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 [email protected]
33 [email protected]
23 [email protected]
21 [email protected]
18 [email protected]
18 [email protected]
15 [email protected]
14 [email protected]
14 [email protected]
14 [email protected]
Top ten commiters:
157 [email protected]
77 [email protected]
63 [email protected]
54 [email protected]
46 [email protected]
44 [email protected]
34 [email protected]
29 [email protected]
28 [email protected]
26 [email protected]
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 [email protected]
42 [email protected]
37 [email protected]
29 [email protected]
23 [email protected]
21 [email protected]
21 [email protected]
21 [email protected]
19 [email protected]
16 [email protected]
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
95 [email protected]
86 [email protected]
53 [email protected]
39 [email protected]
38 [email protected]
35 [email protected]
28 [email protected]
23 [email protected]
21 [email protected]
19 [email protected]
Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).
--
Cheers,
Stephen Rothwell