Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On 9/9/20 11:36 PM, Geert Uytterhoeven wrote: > Hi Günter, > > On Wed, Sep 9, 2020 at 8:24 PM Guenter Roeck wrote: >> On 9/9/20 11:01 AM, Greg Kroah-Hartman wrote: >>> On Wed, Sep 09, 2020 at 09:47:05AM -0700, Guenter Roeck wrote: On Tue, Sep 08, 2020 at 05:22:22PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.8.8 release. > There are 186 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > Anything received after that time might be too late. > Build results: total: 154 pass: 153 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 430 pass: 430 fail: 0 The powerpc problem is the same as before: Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround KALLSYMS_EXTRA_PASS=1 doesn't help. The problem is sporadic, elusive, and all but impossible to bisect. The same build passes on another system, for example, with a different load pattern. It may pass with -j30 and fail with -j40. The problem started at some point after v5.8, and got worse over time; by now it almost always happens. I'd be happy to debug if there is a means to do it, but I don't have an idea where to even start. I'd disable KALLSYMS in my test configurations, but the symbol is selected from various places and thus difficult to disable. So unless I stop building ppc:allmodconfig entirely we'll just have to live with the failure. >>> >>> Ah, I was worried when I saw your dashboard orange for this kernel. >>> >>> I guess the powerpc maintainers don't care? Sad :( >>> >> >> Not sure if the powerpc architecture is to blame. Bisect attempts end up >> all over the place, and don't typically include any powerpc changes. >> I have no idea how kallsyms is created, but my suspicion is that it is >> a generic problem and that powerpc just happens to hit it right now. >> I have added KALLSYMS_EXTRA_PASS=1 to several architecture builds over >> time, when they reported similar problems. Right now I set it for >> alpha, arm, and m68k. powerpc just happens to be the first architecture >> where it doesn't help. > > This is a generic problem, cfr. scripts/link-vmlinux.sh: > > # kallsyms support > # Generate section listing all symbols and add it into vmlinux > # It's a three step process: > # 1) Link .tmp_vmlinux1 so it has all symbols and sections, > # but __kallsyms is empty. > # Running kallsyms on that gives us .tmp_kallsyms1.o with > # the right size > # 2) Link .tmp_vmlinux2 so it now has a __kallsyms section of > # the right size, but due to the added section, some > # addresses have shifted. > # From here, we generate a correct .tmp_kallsyms2.o > # 3) That link may have expanded the kernel image enough that > # more linker branch stubs / trampolines had to be added, which > # introduces new names, which further expands kallsyms. Do another > # pass if that is the case. In theory it's possible this results > # in even more stubs, but unlikely. > # KALLSYMS_EXTRA_PASS=1 may also used to debug or work around > # other bugs. > Ah, that explains a lot. > Adding even more kallsyms_steps may help (or not, if you're really > unlucky). Perhaps the number of passes should be handled automatically > (i.e. run until it succeeds, with a sane (16?) upper limit to avoid > endless builds, so it can still fail, in theory). > Turns out it needs four steps. I prepared a patch to try up to 8 steps. We'll see if it gets accepted. Thanks, Guenter
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
Hi Günter,
On Wed, Sep 9, 2020 at 8:24 PM Guenter Roeck wrote:
> On 9/9/20 11:01 AM, Greg Kroah-Hartman wrote:
> > On Wed, Sep 09, 2020 at 09:47:05AM -0700, Guenter Roeck wrote:
> >> On Tue, Sep 08, 2020 at 05:22:22PM +0200, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 5.8.8 release.
> >>> There are 186 patches in this series, all will be posted as a response
> >>> to this one. If anyone has any issues with these being applied, please
> >>> let me know.
> >>>
> >>> Responses should be made by Thu, 10 Sep 2020 15:21:57 +.
> >>> Anything received after that time might be too late.
> >>>
> >>
> >> Build results:
> >> total: 154 pass: 153 fail: 1
> >> Failed builds:
> >> powerpc:allmodconfig
> >> Qemu test results:
> >> total: 430 pass: 430 fail: 0
> >>
> >> The powerpc problem is the same as before:
> >>
> >> Inconsistent kallsyms data
> >> Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> >>
> >> KALLSYMS_EXTRA_PASS=1 doesn't help. The problem is sporadic, elusive, and
> >> all
> >> but impossible to bisect. The same build passes on another system, for
> >> example,
> >> with a different load pattern. It may pass with -j30 and fail with -j40.
> >> The problem started at some point after v5.8, and got worse over time; by
> >> now
> >> it almost always happens. I'd be happy to debug if there is a means to do
> >> it,
> >> but I don't have an idea where to even start. I'd disable KALLSYMS in my
> >> test configurations, but the symbol is selected from various places and
> >> thus
> >> difficult to disable. So unless I stop building ppc:allmodconfig entirely
> >> we'll just have to live with the failure.
> >
> > Ah, I was worried when I saw your dashboard orange for this kernel.
> >
> > I guess the powerpc maintainers don't care? Sad :(
> >
>
> Not sure if the powerpc architecture is to blame. Bisect attempts end up
> all over the place, and don't typically include any powerpc changes.
> I have no idea how kallsyms is created, but my suspicion is that it is
> a generic problem and that powerpc just happens to hit it right now.
> I have added KALLSYMS_EXTRA_PASS=1 to several architecture builds over
> time, when they reported similar problems. Right now I set it for
> alpha, arm, and m68k. powerpc just happens to be the first architecture
> where it doesn't help.
This is a generic problem, cfr. scripts/link-vmlinux.sh:
# kallsyms support
# Generate section listing all symbols and add it into vmlinux
# It's a three step process:
# 1) Link .tmp_vmlinux1 so it has all symbols and sections,
# but __kallsyms is empty.
# Running kallsyms on that gives us .tmp_kallsyms1.o with
# the right size
# 2) Link .tmp_vmlinux2 so it now has a __kallsyms section of
# the right size, but due to the added section, some
# addresses have shifted.
# From here, we generate a correct .tmp_kallsyms2.o
# 3) That link may have expanded the kernel image enough that
# more linker branch stubs / trampolines had to be added, which
# introduces new names, which further expands kallsyms. Do another
# pass if that is the case. In theory it's possible this results
# in even more stubs, but unlikely.
# KALLSYMS_EXTRA_PASS=1 may also used to debug or work around
# other bugs.
Adding even more kallsyms_steps may help (or not, if you're really
unlucky). Perhaps the number of passes should be handled automatically
(i.e. run until it succeeds, with a sane (16?) upper limit to avoid
endless builds, so it can still fail, in theory).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On 9/9/20 11:01 AM, Greg Kroah-Hartman wrote: > On Wed, Sep 09, 2020 at 09:47:05AM -0700, Guenter Roeck wrote: >> On Tue, Sep 08, 2020 at 05:22:22PM +0200, Greg Kroah-Hartman wrote: >>> This is the start of the stable review cycle for the 5.8.8 release. >>> There are 186 patches in this series, all will be posted as a response >>> to this one. If anyone has any issues with these being applied, please >>> let me know. >>> >>> Responses should be made by Thu, 10 Sep 2020 15:21:57 +. >>> Anything received after that time might be too late. >>> >> >> Build results: >> total: 154 pass: 153 fail: 1 >> Failed builds: >> powerpc:allmodconfig >> Qemu test results: >> total: 430 pass: 430 fail: 0 >> >> The powerpc problem is the same as before: >> >> Inconsistent kallsyms data >> Try make KALLSYMS_EXTRA_PASS=1 as a workaround >> >> KALLSYMS_EXTRA_PASS=1 doesn't help. The problem is sporadic, elusive, and all >> but impossible to bisect. The same build passes on another system, for >> example, >> with a different load pattern. It may pass with -j30 and fail with -j40. >> The problem started at some point after v5.8, and got worse over time; by now >> it almost always happens. I'd be happy to debug if there is a means to do it, >> but I don't have an idea where to even start. I'd disable KALLSYMS in my >> test configurations, but the symbol is selected from various places and thus >> difficult to disable. So unless I stop building ppc:allmodconfig entirely >> we'll just have to live with the failure. > > Ah, I was worried when I saw your dashboard orange for this kernel. > > I guess the powerpc maintainers don't care? Sad :( > Not sure if the powerpc architecture is to blame. Bisect attempts end up all over the place, and don't typically include any powerpc changes. I have no idea how kallsyms is created, but my suspicion is that it is a generic problem and that powerpc just happens to hit it right now. I have added KALLSYMS_EXTRA_PASS=1 to several architecture builds over time, when they reported similar problems. Right now I set it for alpha, arm, and m68k. powerpc just happens to be the first architecture where it doesn't help. Guenter
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On Wed, Sep 09, 2020 at 09:47:05AM -0700, Guenter Roeck wrote: > On Tue, Sep 08, 2020 at 05:22:22PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.8 release. > > There are 186 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > > Anything received after that time might be too late. > > > > Build results: > total: 154 pass: 153 fail: 1 > Failed builds: > powerpc:allmodconfig > Qemu test results: > total: 430 pass: 430 fail: 0 > > The powerpc problem is the same as before: > > Inconsistent kallsyms data > Try make KALLSYMS_EXTRA_PASS=1 as a workaround > > KALLSYMS_EXTRA_PASS=1 doesn't help. The problem is sporadic, elusive, and all > but impossible to bisect. The same build passes on another system, for > example, > with a different load pattern. It may pass with -j30 and fail with -j40. > The problem started at some point after v5.8, and got worse over time; by now > it almost always happens. I'd be happy to debug if there is a means to do it, > but I don't have an idea where to even start. I'd disable KALLSYMS in my > test configurations, but the symbol is selected from various places and thus > difficult to disable. So unless I stop building ppc:allmodconfig entirely > we'll just have to live with the failure. Ah, I was worried when I saw your dashboard orange for this kernel. I guess the powerpc maintainers don't care? Sad :( Anyway, thanks for testing them all and letting me know. greg k-h
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On Tue, Sep 08, 2020 at 07:39:08PM -0600, Shuah Khan wrote: > On 9/8/20 9:22 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.8 release. > > There are 186 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.8-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.8.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. > > Tested-by: Shuah Khan Thanks for testing all of them and letting me know. greg k-h
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On Wed, Sep 09, 2020 at 11:18:57AM +0530, Naresh Kamboju wrote: > On Tue, 8 Sep 2020 at 21:05, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.8.8 release. > > There are 186 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.8-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.8.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. > > Tested-by: Linux Kernel Functional Testing Thanks for testing them all and letting me konw. greg k-h
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On Tue, Sep 08, 2020 at 05:22:22PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.8.8 release. > There are 186 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > Anything received after that time might be too late. > Build results: total: 154 pass: 153 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 430 pass: 430 fail: 0 The powerpc problem is the same as before: Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround KALLSYMS_EXTRA_PASS=1 doesn't help. The problem is sporadic, elusive, and all but impossible to bisect. The same build passes on another system, for example, with a different load pattern. It may pass with -j30 and fail with -j40. The problem started at some point after v5.8, and got worse over time; by now it almost always happens. I'd be happy to debug if there is a means to do it, but I don't have an idea where to even start. I'd disable KALLSYMS in my test configurations, but the symbol is selected from various places and thus difficult to disable. So unless I stop building ppc:allmodconfig entirely we'll just have to live with the failure. Tested-by: Guenter Roeck Guenter
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On Tue, 8 Sep 2020 at 21:05, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.8 release. > There are 186 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.8-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.8.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.8.8-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.8.y git commit: 456fe9607f8f8a55179d2527598b8e90a2591e4d git describe: v5.8.7-187-g456fe9607f8f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.8-oe/build/v5.8.7-187-g456fe9607f8f No regressions (compared to build v5.8.7) No fixes (compared to build v5.8.7) Ran 36239 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * ltp-containers-tests * ltp-ipc-tests * ltp-tracing-tests * network-basic-tests * ltp-dio-tests * ltp-io-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On 9/8/20 9:22 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.8.8 release. There are 186 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu, 10 Sep 2020 15:21:57 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.8-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.8.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. Tested-by: Shuah Khan thanks, -- Shuah
[PATCH 5.8 000/186] 5.8.8-rc1 review
This is the start of the stable review cycle for the 5.8.8 release. There are 186 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu, 10 Sep 2020 15:21:57 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.8-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.8.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 5.8.8-rc1 Himadri Pandya net: usb: Fix uninit-was-stored issue in asix_read_phy_addr() Johannes Berg cfg80211: regulatory: reject invalid hints David Howells mm/khugepaged.c: fix khugepaged's request size in collapse_file Muchun Song mm/hugetlb: fix a race between hugetlb sysctl handlers Li Xinhai mm/hugetlb: try preferred node first when alloc gigantic page from cma Alistair Popple mm/migrate: fixup setting UFFD_WP flag Mrinal Pandey checkpatch: fix the usage of capture group ( ... ) Sowjanya Komatineni sdhci: tegra: Add missing TMCLK for data timeout Randy Dunlap kconfig: streamline_config.pl: check defined(ENV variable) before using it Wei Li perf record: Correct the help info of option "--no-bpf-event" Jens Axboe io_uring: no read/write-retry on -EAGAIN error and O_NONBLOCK marked file Alistair Popple mm/rmap: fixup copying of soft dirty and uffd ptes Yang Shi mm: madvise: fix vma user-after-free Joerg Roedel mm: track page table modifications in __apply_to_page_range() Eugeniu Rosca mm: slub: fix conversion of freelist_corrupted() Ye Bin dm thin metadata: Fix use-after-free in dm_bm_set_read_only Ye Bin dm thin metadata: Avoid returning cmd->bm wild pointer on error Ye Bin dm cache metadata: Avoid returning cmd->bm wild pointer on error Damien Le Moal dm crypt: Initialize crypto wait structures Mikulas Patocka dm integrity: fix error reporting in bitmap mode after creation Mike Snitzer dm mpath: fix racey management of PG initialization Mikulas Patocka dm writecache: handle DAX to partitions on persistent memory correctly Sandeep Raghuraman drm/amdgpu: Specify get_argument function for ci_smu_funcs Evan Quan drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting Sean Paul drm/i915: Fix sha_text population code Gustavo Pimentel dmaengine: dw-edma: Fix scatter-gather address calculation Tejun Heo blk-stat: make q->stats->lock irqsafe Tejun Heo blk-iocost: ioc_pd_free() shouldn't assume irq disabled He Zhe mips/oprofile: Fix fallthrough placement Tejun Heo libata: implement ATA_HORKAGE_MAX_TRIM_128M and apply to Sandisks Eric Farman s390: fix GENERIC_LOCKBREAK dependency typo in Kconfig Jiufei Xue io_uring: fix removing the wrong file in __io_sqe_files_update() Jiufei Xue io_uring: set table->files[i] to NULL when io_sqe_file_register failed Jens Axboe block: ensure bdi->io_pages is always initialized Ming Lei block: allow for_each_bvec to support zero len bvec Max Staudt affs: fix basic permission bits to actually work Sean Young media: rc: uevent sysfs file races with rc_unregister_device() Sean Young media: rc: do not access device via sysfs after rc_unregister_device() Adrian Hunter mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers Wenbin Mei mmc: dt-bindings: Add resets/reset-names for Mediatek MMC bindings Wenbin Mei mmc: mediatek: add optional module reset property Wenbin Mei arm64: dts: mt7622: add reset node for mmc device Takashi Iwai ALSA: hda/realtek - Improved routing for Thinkpad X1 7th/8th Gen Adrien Crivelli ALSA: hda/realtek: Add quirk for Samsung Galaxy Book Ion NT950XCJ-X716A Takashi Sakamoto ALSA; firewire-tascam: exclude Tascam FE-8 from detection Dan Crawford ALSA: hda - Fix silent audio output and corrupted input on MSI X570-A PRO Takashi Sakamoto ALSA: firewire-digi00x: exclude Avid Adrenaline from detection Kai Vehmanen ALSA: hda/hdmi: always check pin power status in i915 pin fixup Takashi Iwai ALSA: pcm: oss: Remove superfluous WARN_ON() for mulaw sanity check Joshua Sivec ALSA: usb-audio: Add implicit feedback quirk for UR22C František Kučera ALSA: usb-audio: Add basic capture support for Pioneer DJ DJM-250MK2 Tong Zhang ALSA: ca0106: fix error code handling Tiezhu Yang Revert "ALSA: hda: Add support for Loongson 7A1000 controller" Sasha Levin x86/mm/32: Bring back vmalloc faulting on x86_32 Max Chou Bluetooth: Return NOTIFY_DONE for hci_suspend_notifier Qu Wenruo btrfs:
