Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 10:01 AM, Linus Torvalds wrote: On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote: On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 It's stuck in this loop: loop: pause mov0x18(%rcx),%edx and$0x1,%edx jneloop which is csd_lock_wait(). Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess. Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of. Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further. Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related. Turns out this is a well known problem with Ryzen CPUs: https://bugzilla.kernel.org/show_bug.cgi?id=196683 Guenter
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 10:01 AM, Linus Torvalds wrote: On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote: On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 It's stuck in this loop: loop: pause mov0x18(%rcx),%edx and$0x1,%edx jneloop which is csd_lock_wait(). Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess. Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of. Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further. Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related. Turns out this is a well known problem with Ryzen CPUs: https://bugzilla.kernel.org/show_bug.cgi?id=196683 Guenter
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote: > > On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: > >> --- > >> [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! > >> [kworker/5:1:155] > >> [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 > >> [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 > >> 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 > >> <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 It's stuck in this loop: loop: pause mov0x18(%rcx),%edx and$0x1,%edx jneloop which is csd_lock_wait(). Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess. Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of. > Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is > related to heavy load, not to suspend/resume. At this point I suspect that > it may be an AMD/Ryzen specific problem - it looks like it disappears if I > add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a > CPU bug or some AMD specific code problem. I'll try to analyze it further. Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related. Linus
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote: > > On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: > >> --- > >> [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! > >> [kworker/5:1:155] > >> [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 > >> [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 > >> 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 > >> <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 It's stuck in this loop: loop: pause mov0x18(%rcx),%edx and$0x1,%edx jneloop which is csd_lock_wait(). Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess. Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of. > Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is > related to heavy load, not to suspend/resume. At this point I suspect that > it may be an AMD/Ryzen specific problem - it looks like it disappears if I > add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a > CPU bug or some AMD specific code problem. I'll try to analyze it further. Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related. Linus
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 03:43 AM, Greg Kroah-Hartman wrote: On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote: On 5 September 2018 at 01:02, Greg Kroah-Hartman wrote: On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Wed Sep 5 16:56:53 UTC 2018. 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/v4.x/stable-review/patch-4.18.6-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-4.18.y and the diffstat can be found below. I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz I get to see 4.18.6-rc1 not rc2. Odd. Something is up with the kernel.org mirroring right now. Let's wait for people to wake up to look into it... Same here (rc1 vs. rc2). The necessary added patch was there, so I figured you did not update the release number and ignored it. Guenter With the current results on given commit id are looking good. Wonderful, thanks for testing and letting me know. greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 03:43 AM, Greg Kroah-Hartman wrote: On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote: On 5 September 2018 at 01:02, Greg Kroah-Hartman wrote: On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Wed Sep 5 16:56:53 UTC 2018. 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/v4.x/stable-review/patch-4.18.6-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-4.18.y and the diffstat can be found below. I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz I get to see 4.18.6-rc1 not rc2. Odd. Something is up with the kernel.org mirroring right now. Let's wait for people to wake up to look into it... Same here (rc1 vs. rc2). The necessary added patch was there, so I figured you did not update the release number and ignored it. Guenter With the current results on given commit id are looking good. Wonderful, thanks for testing and letting me know. greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: On Tue, Sep 04, 2018 at 09:24:34AM -0700, Guenter Roeck wrote: On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Wed Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late. Not directly related to v4.18.6-rc1. I have seen the following hang several times with v4.18.5. It happens on a quite regular basis after a suspend-resume cycle. CPU is Ryzen 1700X. Guenter --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L 4.18.5+ #1 [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 [ 9990.762596] Workqueue: events free_work [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 [ 9990.762626] RSP: 0018:95ebc3effd20 EFLAGS: 0202 ORIG_RAX: ff13 [ 9990.762628] RAX: 000c RBX: 94eeded63cc8 RCX: 94eedef27bc0 [ 9990.762629] RDX: 0001 RSI: 0100 RDI: 94eeded63cc8 [ 9990.762630] RBP: 95ebc3effd60 R08: fff0 R09: 00ff [ 9990.762631] R10: 94eeded63ce8 R11: 94eeded63cc8 R12: 94eeded63cc0 [ 9990.762632] R13: a6076150 R14: R15: 0100 [ 9990.762633] FS: () GS:94eeded4() knlGS: [ 9990.762635] CS: 0010 DS: ES: CR0: 80050033 [ 9990.762636] CR2: 00a67000 CR3: 0006f120c000 CR4: 003406e0 [ 9990.762637] Call Trace: [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 [ 9990.762644] on_each_cpu+0x2d/0x60 [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 [ 9990.762654] remove_vm_area+0x74/0x80 [ 9990.762656] __vunmap+0x3b/0xc0 [ 9990.762657] free_work+0x25/0x40 [ 9990.762660] process_one_work+0x15e/0x3f0 [ 9990.762662] worker_thread+0x4a/0x440 [ 9990.762664] kthread+0x105/0x140 [ 9990.762666] ? process_one_work+0x3f0/0x3f0 [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 [ 9990.762670] ret_from_fork+0x22/0x40 Odd. Do you see this on Linus's tree? Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further. Either case, it is not a concern for the current release since it affects other kernel versions. Guenter
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: On Tue, Sep 04, 2018 at 09:24:34AM -0700, Guenter Roeck wrote: On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Wed Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late. Not directly related to v4.18.6-rc1. I have seen the following hang several times with v4.18.5. It happens on a quite regular basis after a suspend-resume cycle. CPU is Ryzen 1700X. Guenter --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L 4.18.5+ #1 [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 [ 9990.762596] Workqueue: events free_work [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 [ 9990.762626] RSP: 0018:95ebc3effd20 EFLAGS: 0202 ORIG_RAX: ff13 [ 9990.762628] RAX: 000c RBX: 94eeded63cc8 RCX: 94eedef27bc0 [ 9990.762629] RDX: 0001 RSI: 0100 RDI: 94eeded63cc8 [ 9990.762630] RBP: 95ebc3effd60 R08: fff0 R09: 00ff [ 9990.762631] R10: 94eeded63ce8 R11: 94eeded63cc8 R12: 94eeded63cc0 [ 9990.762632] R13: a6076150 R14: R15: 0100 [ 9990.762633] FS: () GS:94eeded4() knlGS: [ 9990.762635] CS: 0010 DS: ES: CR0: 80050033 [ 9990.762636] CR2: 00a67000 CR3: 0006f120c000 CR4: 003406e0 [ 9990.762637] Call Trace: [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 [ 9990.762644] on_each_cpu+0x2d/0x60 [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 [ 9990.762654] remove_vm_area+0x74/0x80 [ 9990.762656] __vunmap+0x3b/0xc0 [ 9990.762657] free_work+0x25/0x40 [ 9990.762660] process_one_work+0x15e/0x3f0 [ 9990.762662] worker_thread+0x4a/0x440 [ 9990.762664] kthread+0x105/0x140 [ 9990.762666] ? process_one_work+0x3f0/0x3f0 [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 [ 9990.762670] ret_from_fork+0x22/0x40 Odd. Do you see this on Linus's tree? Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further. Either case, it is not a concern for the current release since it affects other kernel versions. Guenter
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote: > On 5 September 2018 at 01:02, Greg Kroah-Hartman > wrote: > > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > >> This is the start of the stable review cycle for the 4.18.6 release. > >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y > >> and the diffstat can be found below. > > > > I have released -rc2 to fix a reported problem: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz > > I get to see 4.18.6-rc1 not rc2. > With the current results on given commit id are looking good. > > Results from Linaro’s test farm. > No regressions on arm64, arm and x86_64. You may have noticed i386 listed below under Environments. This was added last week, and runs functional testing on an i386 kernel under QEMU emulation, as well as on x86_64 server hardware. This also accounts for our total test count (unique tests * test environments) surpassing 20,000. We'll therefore be updating the email header to read: No regressions on arm64, arm, x86_64, and i386. Thanks, Dan > > Summary > > > kernel: 4.18.6-rc1 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-4.18.y > git commit: a6a229cf7e7f147eb6d118815a01758749fa6e8d > git describe: v4.18.5-124-ga6a229cf7e7f > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-124-ga6a229cf7e7f > > > No regressions (compared to build v4.18.5) > > > Ran 21181 total tests in the following environments and test suites. > > Environments > -- > - dragonboard-410c - arm64 > - hi6220-hikey - arm64 > - i386 > - juno-r2 - arm64 > - qemu_arm > - qemu_arm64 > - qemu_i386 > - qemu_x86_64 > - x15 - arm > - x86_64 > > Test Suites > --- > * boot > * kselftest > * libhugetlbfs > * ltp-cap_bounds-tests > * ltp-containers-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-io-tests > * ltp-ipc-tests > * ltp-math-tests > * ltp-nptl-tests > * ltp-pty-tests > * ltp-sched-tests > * ltp-securebits-tests > * ltp-syscalls-tests > * ltp-timers-tests > * prep-inline > * ltp-open-posix-tests > * kselftest-vsyscall-mode-native > * kselftest-vsyscall-mode-none > > -- > Linaro LKFT > https://lkft.linaro.org > > >
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote: > On 5 September 2018 at 01:02, Greg Kroah-Hartman > wrote: > > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > >> This is the start of the stable review cycle for the 4.18.6 release. > >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y > >> and the diffstat can be found below. > > > > I have released -rc2 to fix a reported problem: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz > > I get to see 4.18.6-rc1 not rc2. > With the current results on given commit id are looking good. > > Results from Linaro’s test farm. > No regressions on arm64, arm and x86_64. You may have noticed i386 listed below under Environments. This was added last week, and runs functional testing on an i386 kernel under QEMU emulation, as well as on x86_64 server hardware. This also accounts for our total test count (unique tests * test environments) surpassing 20,000. We'll therefore be updating the email header to read: No regressions on arm64, arm, x86_64, and i386. Thanks, Dan > > Summary > > > kernel: 4.18.6-rc1 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-4.18.y > git commit: a6a229cf7e7f147eb6d118815a01758749fa6e8d > git describe: v4.18.5-124-ga6a229cf7e7f > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-124-ga6a229cf7e7f > > > No regressions (compared to build v4.18.5) > > > Ran 21181 total tests in the following environments and test suites. > > Environments > -- > - dragonboard-410c - arm64 > - hi6220-hikey - arm64 > - i386 > - juno-r2 - arm64 > - qemu_arm > - qemu_arm64 > - qemu_i386 > - qemu_x86_64 > - x15 - arm > - x86_64 > > Test Suites > --- > * boot > * kselftest > * libhugetlbfs > * ltp-cap_bounds-tests > * ltp-containers-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-io-tests > * ltp-ipc-tests > * ltp-math-tests > * ltp-nptl-tests > * ltp-pty-tests > * ltp-sched-tests > * ltp-securebits-tests > * ltp-syscalls-tests > * ltp-timers-tests > * prep-inline > * ltp-open-posix-tests > * kselftest-vsyscall-mode-native > * kselftest-vsyscall-mode-none > > -- > Linaro LKFT > https://lkft.linaro.org > > >
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote: > On 5 September 2018 at 01:02, Greg Kroah-Hartman > wrote: > > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > >> This is the start of the stable review cycle for the 4.18.6 release. > >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y > >> and the diffstat can be found below. > > > > I have released -rc2 to fix a reported problem: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz > > I get to see 4.18.6-rc1 not rc2. Odd. Something is up with the kernel.org mirroring right now. Let's wait for people to wake up to look into it... > With the current results on given commit id are looking good. Wonderful, thanks for testing and letting me know. greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote: > On 5 September 2018 at 01:02, Greg Kroah-Hartman > wrote: > > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > >> This is the start of the stable review cycle for the 4.18.6 release. > >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y > >> and the diffstat can be found below. > > > > I have released -rc2 to fix a reported problem: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz > > I get to see 4.18.6-rc1 not rc2. Odd. Something is up with the kernel.org mirroring right now. Let's wait for people to wake up to look into it... > With the current results on given commit id are looking good. Wonderful, thanks for testing and letting me know. greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 5 September 2018 at 01:02, Greg Kroah-Hartman wrote: > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.18.6 release. >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y >> and the diffstat can be found below. > > I have released -rc2 to fix a reported problem: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz I get to see 4.18.6-rc1 not rc2. With the current results on given commit id are looking good. Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.18.6-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.18.y git commit: a6a229cf7e7f147eb6d118815a01758749fa6e8d git describe: v4.18.5-124-ga6a229cf7e7f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-124-ga6a229cf7e7f No regressions (compared to build v4.18.5) Ran 21181 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-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-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * prep-inline * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org >
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 5 September 2018 at 01:02, Greg Kroah-Hartman wrote: > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.18.6 release. >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y >> and the diffstat can be found below. > > I have released -rc2 to fix a reported problem: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz I get to see 4.18.6-rc1 not rc2. With the current results on given commit id are looking good. Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.18.6-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.18.y git commit: a6a229cf7e7f147eb6d118815a01758749fa6e8d git describe: v4.18.5-124-ga6a229cf7e7f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-124-ga6a229cf7e7f No regressions (compared to build v4.18.5) Ran 21181 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-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-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * prep-inline * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org >
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Tue, Sep 04, 2018 at 09:24:34AM -0700, Guenter Roeck wrote: > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.6 release. > > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > > Anything received after that time might be too late. > > > > Not directly related to v4.18.6-rc1. I have seen the following hang > several times with v4.18.5. It happens on a quite regular basis after > a suspend-resume cycle. CPU is Ryzen 1700X. > > Guenter > > --- > [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! > [kworker/5:1:155] > [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport > sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc > edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic > snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel > snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd > glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm > k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc > ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video > ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb > fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi > [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L > 4.18.5+ #1 > [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming > 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 > [ 9990.762596] Workqueue: events free_work > [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 > [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 > d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 > 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 > [ 9990.762626] RSP: 0018:95ebc3effd20 EFLAGS: 0202 ORIG_RAX: > ff13 > [ 9990.762628] RAX: 000c RBX: 94eeded63cc8 RCX: > 94eedef27bc0 > [ 9990.762629] RDX: 0001 RSI: 0100 RDI: > 94eeded63cc8 > [ 9990.762630] RBP: 95ebc3effd60 R08: fff0 R09: > 00ff > [ 9990.762631] R10: 94eeded63ce8 R11: 94eeded63cc8 R12: > 94eeded63cc0 > [ 9990.762632] R13: a6076150 R14: R15: > 0100 > [ 9990.762633] FS: () GS:94eeded4() > knlGS: > [ 9990.762635] CS: 0010 DS: ES: CR0: 80050033 > [ 9990.762636] CR2: 00a67000 CR3: 0006f120c000 CR4: > 003406e0 > [ 9990.762637] Call Trace: > [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 > [ 9990.762644] on_each_cpu+0x2d/0x60 > [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 > [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 > [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 > [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 > [ 9990.762654] remove_vm_area+0x74/0x80 > [ 9990.762656] __vunmap+0x3b/0xc0 > [ 9990.762657] free_work+0x25/0x40 > [ 9990.762660] process_one_work+0x15e/0x3f0 > [ 9990.762662] worker_thread+0x4a/0x440 > [ 9990.762664] kthread+0x105/0x140 > [ 9990.762666] ? process_one_work+0x3f0/0x3f0 > [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 > [ 9990.762670] ret_from_fork+0x22/0x40 Odd. Do you see this on Linus's tree? thanks, greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Tue, Sep 04, 2018 at 09:24:34AM -0700, Guenter Roeck wrote: > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.6 release. > > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > > Anything received after that time might be too late. > > > > Not directly related to v4.18.6-rc1. I have seen the following hang > several times with v4.18.5. It happens on a quite regular basis after > a suspend-resume cycle. CPU is Ryzen 1700X. > > Guenter > > --- > [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! > [kworker/5:1:155] > [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport > sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc > edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic > snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel > snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd > glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm > k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc > ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video > ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb > fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi > [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L > 4.18.5+ #1 > [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming > 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 > [ 9990.762596] Workqueue: events free_work > [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 > [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 > d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 > 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 > [ 9990.762626] RSP: 0018:95ebc3effd20 EFLAGS: 0202 ORIG_RAX: > ff13 > [ 9990.762628] RAX: 000c RBX: 94eeded63cc8 RCX: > 94eedef27bc0 > [ 9990.762629] RDX: 0001 RSI: 0100 RDI: > 94eeded63cc8 > [ 9990.762630] RBP: 95ebc3effd60 R08: fff0 R09: > 00ff > [ 9990.762631] R10: 94eeded63ce8 R11: 94eeded63cc8 R12: > 94eeded63cc0 > [ 9990.762632] R13: a6076150 R14: R15: > 0100 > [ 9990.762633] FS: () GS:94eeded4() > knlGS: > [ 9990.762635] CS: 0010 DS: ES: CR0: 80050033 > [ 9990.762636] CR2: 00a67000 CR3: 0006f120c000 CR4: > 003406e0 > [ 9990.762637] Call Trace: > [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 > [ 9990.762644] on_each_cpu+0x2d/0x60 > [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 > [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 > [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 > [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 > [ 9990.762654] remove_vm_area+0x74/0x80 > [ 9990.762656] __vunmap+0x3b/0xc0 > [ 9990.762657] free_work+0x25/0x40 > [ 9990.762660] process_one_work+0x15e/0x3f0 > [ 9990.762662] worker_thread+0x4a/0x440 > [ 9990.762664] kthread+0x105/0x140 > [ 9990.762666] ? process_one_work+0x3f0/0x3f0 > [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 > [ 9990.762670] ret_from_fork+0x22/0x40 Odd. Do you see this on Linus's tree? thanks, greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Tue, Sep 04, 2018 at 03:53:32PM -0700, Guenter Roeck wrote: > On 09/03/2018 09:55 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.6 release. > > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > > Anything received after that time might be too late. > > > > > Build results: > total: 136 pass: 136 fail: 0 > Qemu test results: > total: 314 pass: 314 fail: 0 > > Details are available at https://kerneltests.org/builders/. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Tue, Sep 04, 2018 at 03:53:32PM -0700, Guenter Roeck wrote: > On 09/03/2018 09:55 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.6 release. > > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > > Anything received after that time might be too late. > > > > > Build results: > total: 136 pass: 136 fail: 0 > Qemu test results: > total: 314 pass: 314 fail: 0 > > Details are available at https://kerneltests.org/builders/. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/03/2018 09:55 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Wed Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late. Build results: total: 136 pass: 136 fail: 0 Qemu test results: total: 314 pass: 314 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/03/2018 09:55 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Wed Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late. Build results: total: 136 pass: 136 fail: 0 Qemu test results: total: 314 pass: 314 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/04/2018 01:32 PM, Greg Kroah-Hartman wrote: > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.18.6 release. >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y >> and the diffstat can be found below. > > I have released -rc2 to fix a reported problem: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz > > It hasn't shown up on kernel.org yet. Found patch-4.14.68-rc2.gz thanks, -- Shuah
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/04/2018 01:32 PM, Greg Kroah-Hartman wrote: > On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.18.6 release. >> There are 123 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 Wed Sep 5 16:56:53 UTC 2018. >> 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/v4.x/stable-review/patch-4.18.6-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-4.18.y >> and the diffstat can be found below. > > I have released -rc2 to fix a reported problem: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz > > It hasn't shown up on kernel.org yet. Found patch-4.14.68-rc2.gz thanks, -- Shuah
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.18.6 release. > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > 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/v4.x/stable-review/patch-4.18.6-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-4.18.y > and the diffstat can be found below. I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.18.6 release. > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > 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/v4.x/stable-review/patch-4.18.6-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-4.18.y > and the diffstat can be found below. I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2.gz
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Tue, Sep 04, 2018 at 10:12:13AM -0700, Linus Torvalds wrote:
> On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
> wrote:
> >
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> > ..a few hundred times..
> > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> > Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70
> > Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30
>
> Yeah, so what seems to have happened is that commit db7ddef30112 ("mm:
> move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the
> stable tree (because it wasn't an obvious dependency).
>
> And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm:
> Support invalidating TLB caches for RCU_TABLE_FREE") ends up with
> recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(),
> which in turn calls tlb_table_invalidate(), which calls back to
> tlb_flush_mmu_tlbonly().
>
> So you have endless recursion - at least until you run out of stack.
> Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a
> nice clean kernel stack overflow message like you did.
>
> Or if you have KASAN enabled and no VMAP stack, you just end up with
> random hangs and huge memory corruption as the recursion stomps all
> over your memory.
Ok, I will go queue this patch up now, it was in my very-long "to-apply"
queue, but I didn't catch the dependancy here.
thanks,
greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Tue, Sep 04, 2018 at 10:12:13AM -0700, Linus Torvalds wrote:
> On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
> wrote:
> >
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> > ..a few hundred times..
> > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> > Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70
> > Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30
>
> Yeah, so what seems to have happened is that commit db7ddef30112 ("mm:
> move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the
> stable tree (because it wasn't an obvious dependency).
>
> And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm:
> Support invalidating TLB caches for RCU_TABLE_FREE") ends up with
> recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(),
> which in turn calls tlb_table_invalidate(), which calls back to
> tlb_flush_mmu_tlbonly().
>
> So you have endless recursion - at least until you run out of stack.
> Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a
> nice clean kernel stack overflow message like you did.
>
> Or if you have KASAN enabled and no VMAP stack, you just end up with
> random hangs and huge memory corruption as the recursion stomps all
> over your memory.
Ok, I will go queue this patch up now, it was in my very-long "to-apply"
queue, but I didn't catch the dependancy here.
thanks,
greg k-h
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
wrote:
>
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> ..a few hundred times..
> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70
> Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30
Yeah, so what seems to have happened is that commit db7ddef30112 ("mm:
move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the
stable tree (because it wasn't an obvious dependency).
And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm:
Support invalidating TLB caches for RCU_TABLE_FREE") ends up with
recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(),
which in turn calls tlb_table_invalidate(), which calls back to
tlb_flush_mmu_tlbonly().
So you have endless recursion - at least until you run out of stack.
Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a
nice clean kernel stack overflow message like you did.
Or if you have KASAN enabled and no VMAP stack, you just end up with
random hangs and huge memory corruption as the recursion stomps all
over your memory.
Linus
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
wrote:
>
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> ..a few hundred times..
> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70
> Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30
Yeah, so what seems to have happened is that commit db7ddef30112 ("mm:
move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the
stable tree (because it wasn't an obvious dependency).
And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm:
Support invalidating TLB caches for RCU_TABLE_FREE") ends up with
recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(),
which in turn calls tlb_table_invalidate(), which calls back to
tlb_flush_mmu_tlbonly().
So you have endless recursion - at least until you run out of stack.
Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a
nice clean kernel stack overflow message like you did.
Or if you have KASAN enabled and no VMAP stack, you just end up with
random hangs and huge memory corruption as the recursion stomps all
over your memory.
Linus
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.18.6 release. > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > Anything received after that time might be too late. > Not directly related to v4.18.6-rc1. I have seen the following hang several times with v4.18.5. It happens on a quite regular basis after a suspend-resume cycle. CPU is Ryzen 1700X. Guenter --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L 4.18.5+ #1 [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 [ 9990.762596] Workqueue: events free_work [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 [ 9990.762626] RSP: 0018:95ebc3effd20 EFLAGS: 0202 ORIG_RAX: ff13 [ 9990.762628] RAX: 000c RBX: 94eeded63cc8 RCX: 94eedef27bc0 [ 9990.762629] RDX: 0001 RSI: 0100 RDI: 94eeded63cc8 [ 9990.762630] RBP: 95ebc3effd60 R08: fff0 R09: 00ff [ 9990.762631] R10: 94eeded63ce8 R11: 94eeded63cc8 R12: 94eeded63cc0 [ 9990.762632] R13: a6076150 R14: R15: 0100 [ 9990.762633] FS: () GS:94eeded4() knlGS: [ 9990.762635] CS: 0010 DS: ES: CR0: 80050033 [ 9990.762636] CR2: 00a67000 CR3: 0006f120c000 CR4: 003406e0 [ 9990.762637] Call Trace: [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 [ 9990.762644] on_each_cpu+0x2d/0x60 [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 [ 9990.762654] remove_vm_area+0x74/0x80 [ 9990.762656] __vunmap+0x3b/0xc0 [ 9990.762657] free_work+0x25/0x40 [ 9990.762660] process_one_work+0x15e/0x3f0 [ 9990.762662] worker_thread+0x4a/0x440 [ 9990.762664] kthread+0x105/0x140 [ 9990.762666] ? process_one_work+0x3f0/0x3f0 [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 [ 9990.762670] ret_from_fork+0x22/0x40
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.18.6 release. > There are 123 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 Wed Sep 5 16:56:53 UTC 2018. > Anything received after that time might be too late. > Not directly related to v4.18.6-rc1. I have seen the following hang several times with v4.18.5. It happens on a quite regular basis after a suspend-resume cycle. CPU is Ryzen 1700X. Guenter --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L 4.18.5+ #1 [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 [ 9990.762596] Workqueue: events free_work [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 [ 9990.762626] RSP: 0018:95ebc3effd20 EFLAGS: 0202 ORIG_RAX: ff13 [ 9990.762628] RAX: 000c RBX: 94eeded63cc8 RCX: 94eedef27bc0 [ 9990.762629] RDX: 0001 RSI: 0100 RDI: 94eeded63cc8 [ 9990.762630] RBP: 95ebc3effd60 R08: fff0 R09: 00ff [ 9990.762631] R10: 94eeded63ce8 R11: 94eeded63cc8 R12: 94eeded63cc0 [ 9990.762632] R13: a6076150 R14: R15: 0100 [ 9990.762633] FS: () GS:94eeded4() knlGS: [ 9990.762635] CS: 0010 DS: ES: CR0: 80050033 [ 9990.762636] CR2: 00a67000 CR3: 0006f120c000 CR4: 003406e0 [ 9990.762637] Call Trace: [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 [ 9990.762644] on_each_cpu+0x2d/0x60 [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 [ 9990.762654] remove_vm_area+0x74/0x80 [ 9990.762656] __vunmap+0x3b/0xc0 [ 9990.762657] free_work+0x25/0x40 [ 9990.762660] process_one_work+0x15e/0x3f0 [ 9990.762662] worker_thread+0x4a/0x440 [ 9990.762664] kthread+0x105/0x140 [ 9990.762666] ? process_one_work+0x3f0/0x3f0 [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 [ 9990.762670] ret_from_fork+0x22/0x40
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 4 September 2018 at 02:46, François Valenduc wrote: > Le 3/09/18 à 20:39, Holger Hoffstätte a écrit : >> On 09/03/18 18:55, Greg Kroah-Hartman wrote: >>> This is the start of the stable review cycle for the 4.18.6 release. >> >> Unfortunately this is busted. First blamed my custom patches, but as it >> turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, >> but later when starting services and esp. autofs (I think - too much >> output) >> explodes with: >> >> ... >> Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link >> is not ready >> Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at >> ab58c99c (stack is 382b9464..d642b9d6) >> Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): >> [#1] SMP >> Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount >> Tainted: G O 4.18.6 #1 >> Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., >> Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 >> Sep 3 20:19:38 ragnarok kernel: RIP: >> 0010:flush_tlb_func_common.constprop.4+0x23/0x260 >> Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 >> 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 >> 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f >> b7 c3 65 48 8b 15 >> Sep 3 20:19:38 ragnarok kernel: RSP: 0018:c9000326bfe0 EFLAGS: >> 00010082 >> Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: >> 880601006cc0 RCX: >> Sep 3 20:19:38 ragnarok kernel: RDX: 7fb464e7e000 RSI: >> 0003 RDI: c9000326c040 >> Sep 3 20:19:38 ragnarok kernel: RBP: c9000326c030 R08: >> 0005fca490e7 R09: 004fa811 >> Sep 3 20:19:38 ragnarok kernel: R10: 0002 R11: >> R12: 0004 >> Sep 3 20:19:38 ragnarok kernel: R13: 8805fbab7600 R14: >> 880601006cc0 R15: 880602dfb540 >> Sep 3 20:19:38 ragnarok kernel: FS: 7fb469245240() >> GS:88061f50() knlGS: >> Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: ES: CR0: >> 80050033 >> Sep 3 20:19:38 ragnarok kernel: CR2: c9000326bfd8 CR3: >> 0005feadb001 CR4: 000606e0 >> Sep 3 20:19:38 ragnarok kernel: Call Trace: >> Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 >> Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 >> Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 >> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 >> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 >> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 >> ..a few hundred times.. >> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 >> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 >> Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 >> Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 >> Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 >> Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 >> Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 >> Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 >> Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 >> Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 >> Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 >> Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 >> 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 >> b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 >> f7 d8 89 01 48 83 >> Sep 3 20:19:38 ragnarok kernel: RSP: 002b:7ffef83ba548 EFLAGS: >> 0206 ORIG_RAX: 000b >> Sep 3 20:19:38 ragnarok kernel: RAX: ffda RBX: >> 562a1dca9010 RCX: 7fb469081187 >> Sep 3 20:19:38 ragnarok kernel: RDX: 0002 RSI: >> 00204028 RDI: 7fb464c79000 >> Sep 3 20:19:38 ragnarok kernel: RBP: 7ffef83ba720 R08: >> 7fb46928e930 R09: >> Sep 3 20:19:38 ragnarok kernel: R10: 7fb464e7d000 R11: >> 0206 R12: 7ffef83ba654 >> Sep 3 20:19:38 ragnarok kernel: R13: 7ffef83ba610 R14: >> 7ffef83ba655 R15: 7fb46928e000 >> Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr >> sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) >> it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc >> videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq >> snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device >> videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm >> snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi >> snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline >> fb_sys_fops
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 4 September 2018 at 02:46, François Valenduc wrote: > Le 3/09/18 à 20:39, Holger Hoffstätte a écrit : >> On 09/03/18 18:55, Greg Kroah-Hartman wrote: >>> This is the start of the stable review cycle for the 4.18.6 release. >> >> Unfortunately this is busted. First blamed my custom patches, but as it >> turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, >> but later when starting services and esp. autofs (I think - too much >> output) >> explodes with: >> >> ... >> Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link >> is not ready >> Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at >> ab58c99c (stack is 382b9464..d642b9d6) >> Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): >> [#1] SMP >> Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount >> Tainted: G O 4.18.6 #1 >> Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., >> Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 >> Sep 3 20:19:38 ragnarok kernel: RIP: >> 0010:flush_tlb_func_common.constprop.4+0x23/0x260 >> Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 >> 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 >> 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f >> b7 c3 65 48 8b 15 >> Sep 3 20:19:38 ragnarok kernel: RSP: 0018:c9000326bfe0 EFLAGS: >> 00010082 >> Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: >> 880601006cc0 RCX: >> Sep 3 20:19:38 ragnarok kernel: RDX: 7fb464e7e000 RSI: >> 0003 RDI: c9000326c040 >> Sep 3 20:19:38 ragnarok kernel: RBP: c9000326c030 R08: >> 0005fca490e7 R09: 004fa811 >> Sep 3 20:19:38 ragnarok kernel: R10: 0002 R11: >> R12: 0004 >> Sep 3 20:19:38 ragnarok kernel: R13: 8805fbab7600 R14: >> 880601006cc0 R15: 880602dfb540 >> Sep 3 20:19:38 ragnarok kernel: FS: 7fb469245240() >> GS:88061f50() knlGS: >> Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: ES: CR0: >> 80050033 >> Sep 3 20:19:38 ragnarok kernel: CR2: c9000326bfd8 CR3: >> 0005feadb001 CR4: 000606e0 >> Sep 3 20:19:38 ragnarok kernel: Call Trace: >> Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 >> Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 >> Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 >> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 >> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 >> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 >> ..a few hundred times.. >> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 >> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 >> Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 >> Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 >> Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 >> Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 >> Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 >> Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 >> Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 >> Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 >> Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 >> Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 >> 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 >> b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 >> f7 d8 89 01 48 83 >> Sep 3 20:19:38 ragnarok kernel: RSP: 002b:7ffef83ba548 EFLAGS: >> 0206 ORIG_RAX: 000b >> Sep 3 20:19:38 ragnarok kernel: RAX: ffda RBX: >> 562a1dca9010 RCX: 7fb469081187 >> Sep 3 20:19:38 ragnarok kernel: RDX: 0002 RSI: >> 00204028 RDI: 7fb464c79000 >> Sep 3 20:19:38 ragnarok kernel: RBP: 7ffef83ba720 R08: >> 7fb46928e930 R09: >> Sep 3 20:19:38 ragnarok kernel: R10: 7fb464e7d000 R11: >> 0206 R12: 7ffef83ba654 >> Sep 3 20:19:38 ragnarok kernel: R13: 7ffef83ba610 R14: >> 7ffef83ba655 R15: 7fb46928e000 >> Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr >> sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) >> it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc >> videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq >> snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device >> videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm >> snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi >> snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline >> fb_sys_fops
Re: [PATCH 4.18 000/123] 4.18.6-stable review
Le 3/09/18 à 20:39, Holger Hoffstätte a écrit : > On 09/03/18 18:55, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.18.6 release. > > Unfortunately this is busted. First blamed my custom patches, but as it > turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, > but later when starting services and esp. autofs (I think - too much > output) > explodes with: > > ... > Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link > is not ready > Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at > ab58c99c (stack is 382b9464..d642b9d6) > Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): > [#1] SMP > Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount > Tainted: G O 4.18.6 #1 > Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., > Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 > Sep 3 20:19:38 ragnarok kernel: RIP: > 0010:flush_tlb_func_common.constprop.4+0x23/0x260 > Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 > 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 > 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f > b7 c3 65 48 8b 15 > Sep 3 20:19:38 ragnarok kernel: RSP: 0018:c9000326bfe0 EFLAGS: > 00010082 > Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: > 880601006cc0 RCX: > Sep 3 20:19:38 ragnarok kernel: RDX: 7fb464e7e000 RSI: > 0003 RDI: c9000326c040 > Sep 3 20:19:38 ragnarok kernel: RBP: c9000326c030 R08: > 0005fca490e7 R09: 004fa811 > Sep 3 20:19:38 ragnarok kernel: R10: 0002 R11: > R12: 0004 > Sep 3 20:19:38 ragnarok kernel: R13: 8805fbab7600 R14: > 880601006cc0 R15: 880602dfb540 > Sep 3 20:19:38 ragnarok kernel: FS: 7fb469245240() > GS:88061f50() knlGS: > Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: ES: CR0: > 80050033 > Sep 3 20:19:38 ragnarok kernel: CR2: c9000326bfd8 CR3: > 0005feadb001 CR4: 000606e0 > Sep 3 20:19:38 ragnarok kernel: Call Trace: > Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 > Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 > Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 > ..a few hundred times.. > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 > Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 > Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 > Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 > Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 > Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 > Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 > Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 > Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 > Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 > Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 > 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 > b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 > f7 d8 89 01 48 83 > Sep 3 20:19:38 ragnarok kernel: RSP: 002b:7ffef83ba548 EFLAGS: > 0206 ORIG_RAX: 000b > Sep 3 20:19:38 ragnarok kernel: RAX: ffda RBX: > 562a1dca9010 RCX: 7fb469081187 > Sep 3 20:19:38 ragnarok kernel: RDX: 0002 RSI: > 00204028 RDI: 7fb464c79000 > Sep 3 20:19:38 ragnarok kernel: RBP: 7ffef83ba720 R08: > 7fb46928e930 R09: > Sep 3 20:19:38 ragnarok kernel: R10: 7fb464e7d000 R11: > 0206 R12: 7ffef83ba654 > Sep 3 20:19:38 ragnarok kernel: R13: 7ffef83ba610 R14: > 7ffef83ba655 R15: 7fb46928e000 > Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr > sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) > it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc > videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq > snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device > videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm > snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi > snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline > fb_sys_fops ttm snd_hda_intel aesni_intel snd_hda_codec drm snd_hda_core > aes_x86_64 crypto_simd drm_panel_orientation_quirks cryptd snd_pcm > glue_helper
Re: [PATCH 4.18 000/123] 4.18.6-stable review
Le 3/09/18 à 20:39, Holger Hoffstätte a écrit : > On 09/03/18 18:55, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.18.6 release. > > Unfortunately this is busted. First blamed my custom patches, but as it > turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, > but later when starting services and esp. autofs (I think - too much > output) > explodes with: > > ... > Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link > is not ready > Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at > ab58c99c (stack is 382b9464..d642b9d6) > Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): > [#1] SMP > Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount > Tainted: G O 4.18.6 #1 > Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., > Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 > Sep 3 20:19:38 ragnarok kernel: RIP: > 0010:flush_tlb_func_common.constprop.4+0x23/0x260 > Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 > 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 > 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f > b7 c3 65 48 8b 15 > Sep 3 20:19:38 ragnarok kernel: RSP: 0018:c9000326bfe0 EFLAGS: > 00010082 > Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: > 880601006cc0 RCX: > Sep 3 20:19:38 ragnarok kernel: RDX: 7fb464e7e000 RSI: > 0003 RDI: c9000326c040 > Sep 3 20:19:38 ragnarok kernel: RBP: c9000326c030 R08: > 0005fca490e7 R09: 004fa811 > Sep 3 20:19:38 ragnarok kernel: R10: 0002 R11: > R12: 0004 > Sep 3 20:19:38 ragnarok kernel: R13: 8805fbab7600 R14: > 880601006cc0 R15: 880602dfb540 > Sep 3 20:19:38 ragnarok kernel: FS: 7fb469245240() > GS:88061f50() knlGS: > Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: ES: CR0: > 80050033 > Sep 3 20:19:38 ragnarok kernel: CR2: c9000326bfd8 CR3: > 0005feadb001 CR4: 000606e0 > Sep 3 20:19:38 ragnarok kernel: Call Trace: > Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 > Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 > Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 > ..a few hundred times.. > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 > Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 > Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 > Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 > Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 > Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 > Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 > Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 > Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 > Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 > Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 > 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 > b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 > f7 d8 89 01 48 83 > Sep 3 20:19:38 ragnarok kernel: RSP: 002b:7ffef83ba548 EFLAGS: > 0206 ORIG_RAX: 000b > Sep 3 20:19:38 ragnarok kernel: RAX: ffda RBX: > 562a1dca9010 RCX: 7fb469081187 > Sep 3 20:19:38 ragnarok kernel: RDX: 0002 RSI: > 00204028 RDI: 7fb464c79000 > Sep 3 20:19:38 ragnarok kernel: RBP: 7ffef83ba720 R08: > 7fb46928e930 R09: > Sep 3 20:19:38 ragnarok kernel: R10: 7fb464e7d000 R11: > 0206 R12: 7ffef83ba654 > Sep 3 20:19:38 ragnarok kernel: R13: 7ffef83ba610 R14: > 7ffef83ba655 R15: 7fb46928e000 > Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr > sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) > it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc > videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq > snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device > videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm > snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi > snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline > fb_sys_fops ttm snd_hda_intel aesni_intel snd_hda_codec drm snd_hda_core > aes_x86_64 crypto_simd drm_panel_orientation_quirks cryptd snd_pcm > glue_helper
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/03/18 18:55, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. Unfortunately this is busted. First blamed my custom patches, but as it turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, but later when starting services and esp. autofs (I think - too much output) explodes with: ... Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at ab58c99c (stack is 382b9464..d642b9d6) Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): [#1] SMP Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount Tainted: G O 4.18.6 #1 Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:c9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: 880601006cc0 RCX: Sep 3 20:19:38 ragnarok kernel: RDX: 7fb464e7e000 RSI: 0003 RDI: c9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: c9000326c030 R08: 0005fca490e7 R09: 004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0002 R11: R12: 0004 Sep 3 20:19:38 ragnarok kernel: R13: 8805fbab7600 R14: 880601006cc0 R15: 880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 7fb469245240() GS:88061f50() knlGS: Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: ES: CR0: 80050033 Sep 3 20:19:38 ragnarok kernel: CR2: c9000326bfd8 CR3: 0005feadb001 CR4: 000606e0 Sep 3 20:19:38 ragnarok kernel: Call Trace: Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 ..a few hundred times.. Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 f7 d8 89 01 48 83 Sep 3 20:19:38 ragnarok kernel: RSP: 002b:7ffef83ba548 EFLAGS: 0206 ORIG_RAX: 000b Sep 3 20:19:38 ragnarok kernel: RAX: ffda RBX: 562a1dca9010 RCX: 7fb469081187 Sep 3 20:19:38 ragnarok kernel: RDX: 0002 RSI: 00204028 RDI: 7fb464c79000 Sep 3 20:19:38 ragnarok kernel: RBP: 7ffef83ba720 R08: 7fb46928e930 R09: Sep 3 20:19:38 ragnarok kernel: R10: 7fb464e7d000 R11: 0206 R12: 7ffef83ba654 Sep 3 20:19:38 ragnarok kernel: R13: 7ffef83ba610 R14: 7ffef83ba655 R15: 7fb46928e000 Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline fb_sys_fops ttm snd_hda_intel aesni_intel snd_hda_codec drm snd_hda_core aes_x86_64 crypto_simd drm_panel_orientation_quirks cryptd snd_pcm glue_helper backlight snd_timer snd i2c_i801 soundcore i2c_core r8169 parport_pc parport mii Sep 3 20:19:38 ragnarok kernel: ---[ end trace cf25033b43d98311 ]--- Sep 3 20:19:38 ragnarok kernel: RIP:
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/03/18 18:55, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.6 release. Unfortunately this is busted. First blamed my custom patches, but as it turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, but later when starting services and esp. autofs (I think - too much output) explodes with: ... Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at ab58c99c (stack is 382b9464..d642b9d6) Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): [#1] SMP Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount Tainted: G O 4.18.6 #1 Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:c9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: 880601006cc0 RCX: Sep 3 20:19:38 ragnarok kernel: RDX: 7fb464e7e000 RSI: 0003 RDI: c9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: c9000326c030 R08: 0005fca490e7 R09: 004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0002 R11: R12: 0004 Sep 3 20:19:38 ragnarok kernel: R13: 8805fbab7600 R14: 880601006cc0 R15: 880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 7fb469245240() GS:88061f50() knlGS: Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: ES: CR0: 80050033 Sep 3 20:19:38 ragnarok kernel: CR2: c9000326bfd8 CR3: 0005feadb001 CR4: 000606e0 Sep 3 20:19:38 ragnarok kernel: Call Trace: Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 ..a few hundred times.. Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 f7 d8 89 01 48 83 Sep 3 20:19:38 ragnarok kernel: RSP: 002b:7ffef83ba548 EFLAGS: 0206 ORIG_RAX: 000b Sep 3 20:19:38 ragnarok kernel: RAX: ffda RBX: 562a1dca9010 RCX: 7fb469081187 Sep 3 20:19:38 ragnarok kernel: RDX: 0002 RSI: 00204028 RDI: 7fb464c79000 Sep 3 20:19:38 ragnarok kernel: RBP: 7ffef83ba720 R08: 7fb46928e930 R09: Sep 3 20:19:38 ragnarok kernel: R10: 7fb464e7d000 R11: 0206 R12: 7ffef83ba654 Sep 3 20:19:38 ragnarok kernel: R13: 7ffef83ba610 R14: 7ffef83ba655 R15: 7fb46928e000 Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline fb_sys_fops ttm snd_hda_intel aesni_intel snd_hda_codec drm snd_hda_core aes_x86_64 crypto_simd drm_panel_orientation_quirks cryptd snd_pcm glue_helper backlight snd_timer snd i2c_i801 soundcore i2c_core r8169 parport_pc parport mii Sep 3 20:19:38 ragnarok kernel: ---[ end trace cf25033b43d98311 ]--- Sep 3 20:19:38 ragnarok kernel: RIP:
[PATCH 4.18 000/123] 4.18.6-stable review
This is the start of the stable review cycle for the 4.18.6 release.
There are 123 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 Wed Sep 5 16:56:53 UTC 2018.
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/v4.x/stable-review/patch-4.18.6-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-4.18.y
and the diffstat can be found below.
thanks,
greg k-h
-
Pseudo-Shortlog of commits:
Greg Kroah-Hartman
Linux 4.18.6-rc1
Arnd Bergmann
x86: kvm: avoid unused variable warning
Jann Horn
x86/dumpstack: Don't dump kernel memory based on usermode RIP
Scott Bauer
cdrom: Fix info leak/OOB read in cdrom_ioctl_drive_status
Vincent Whitchurch
watchdog: Mark watchdog touch functions as notrace
H. Nikolaus Schaller
power: generic-adc-battery: check for duplicate properties copied from iio
channels
H. Nikolaus Schaller
power: generic-adc-battery: fix out-of-bounds write when copying channel
properties
Dan Carpenter
PM / clk: signedness bug in of_pm_clk_add_clks()
Gustavo A. R. Silva
clk: npcm7xx: fix memory allocation
Alberto Panizzo
clk: rockchip: fix clk_i2sout parent selection bits on rk3399
Abhishek Sahu
mtd: rawnand: qcom: wait for desc completion in all BAM channels
Daniel Mack
mtd: rawnand: marvell: add suspend and resume hooks
Boris Brezillon
mtd: rawnand: fsmc: Stop using chip->read_buf()
Boris Brezillon
mtd: rawnand: hynix: Use ->exec_op() in hynix_nand_reg_write_op()
Mike Christie
iscsi target: fix session creation failure handling
Bart Van Assche
scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock
Bart Van Assche
scsi: sysfs: Introduce sysfs_{un,}break_active_protection()
Bart Van Assche
scsi: mpt3sas: Fix _transport_smp_handler() error path
Sreekanth Reddy
scsi: mpt3sas: Fix calltrace observed while running IO & reset
Tomas Winkler
tpm: separate cmd_ready/go_idle from runtime_pm
Ricardo Schwarzmeier
tpm: Return the actual size when receiving an unsupported command
Paul Burton
MIPS: lib: Provide MIPS64r6 __multi3() for GCC < 7
Huacai Chen
MIPS: Change definition of cpu_relax() for Loongson-3
Paul Burton
MIPS: Always use -march=, not - shortcuts
Matt Redfearn
MIPS: memset.S: Fix byte_fixup for MIPSr6
Maciej W. Rozycki
MIPS: Correct the 64-bit DSP accumulator register size
Masami Hiramatsu
kprobes: Make list and blacklist root user read only
Masami Hiramatsu
kprobes/arm: Fix %p uses in error messages
Masami Hiramatsu
kprobes: Replace %p with other pointer types
Masami Hiramatsu
kprobes: Show blacklist addresses as same as kallsyms does
Philipp Rudo
s390/purgatory: Add missing FORCE to Makefile targets
Philipp Rudo
s390/purgatory: Fix crash with expoline enabled
Sebastian Ott
s390/pci: fix out of bounds access during irq setup
Martin Schwidefsky
s390/numa: move initial setup of node_to_cpumask_map
Julian Wiedmann
s390/qdio: reset old sbal_state flags
Martin Schwidefsky
s390: fix br_r1_trampoline for machines without exrl
Martin Schwidefsky
s390/lib: use expoline for all bcr instructions
Gerald Schaefer
s390/mm: fix addressing exception after suspend/resume
Ben Hutchings
x86: Allow generating user-space headers without a compiler
Jann Horn
x86/entry/64: Wipe KASAN stack shadow before rewind_stack_do_exit()
Gustavo A. R. Silva
hwmon: (nct6775) Fix potential Spectre v1
Andi Kleen
x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+
Andi Kleen
x86/spectre: Add missing family 6 check to microcode check
Nick Desaulniers
x86/irqflags: Mark native_restore_fl extern inline
Andy Lutomirski
x86/nmi: Fix NMI uaccess race against CR3 switching
Samuel Neves
x86/vdso: Fix lsl operand order
Himanshu Madhani
scsi: qla2xxx: Fix stalled relogin
Dan Carpenter
pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()
Johan Hovold
soc: qcom: rmtfs-mem: fix memleak in probe error paths
Ajit Pandey
ASoC: wm_adsp: Correct DSP pointer for preloader control
Gustavo A. R. Silva
ASoC: sirf: Fix potential NULL pointer dereference
Takashi Iwai
ASoC: zte: Fix incorrect PCM format bit usages
Jerome Brunet
ASoC: dpcm: don't merge format from invalid codec dai
Michael Buesch
b43/leds: Ensure NUL-termination of LED name string
Michael Buesch
b43legacy/leds: Ensure NUL-termination of LED name string
Mikulas Patocka
udl-kms: avoid division
Mikulas Patocka
udl-kms: fix crash due to uninitialized memory
Mikulas Patocka
udl-kms: handle allocation failure
[PATCH 4.18 000/123] 4.18.6-stable review
This is the start of the stable review cycle for the 4.18.6 release.
There are 123 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 Wed Sep 5 16:56:53 UTC 2018.
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/v4.x/stable-review/patch-4.18.6-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-4.18.y
and the diffstat can be found below.
thanks,
greg k-h
-
Pseudo-Shortlog of commits:
Greg Kroah-Hartman
Linux 4.18.6-rc1
Arnd Bergmann
x86: kvm: avoid unused variable warning
Jann Horn
x86/dumpstack: Don't dump kernel memory based on usermode RIP
Scott Bauer
cdrom: Fix info leak/OOB read in cdrom_ioctl_drive_status
Vincent Whitchurch
watchdog: Mark watchdog touch functions as notrace
H. Nikolaus Schaller
power: generic-adc-battery: check for duplicate properties copied from iio
channels
H. Nikolaus Schaller
power: generic-adc-battery: fix out-of-bounds write when copying channel
properties
Dan Carpenter
PM / clk: signedness bug in of_pm_clk_add_clks()
Gustavo A. R. Silva
clk: npcm7xx: fix memory allocation
Alberto Panizzo
clk: rockchip: fix clk_i2sout parent selection bits on rk3399
Abhishek Sahu
mtd: rawnand: qcom: wait for desc completion in all BAM channels
Daniel Mack
mtd: rawnand: marvell: add suspend and resume hooks
Boris Brezillon
mtd: rawnand: fsmc: Stop using chip->read_buf()
Boris Brezillon
mtd: rawnand: hynix: Use ->exec_op() in hynix_nand_reg_write_op()
Mike Christie
iscsi target: fix session creation failure handling
Bart Van Assche
scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock
Bart Van Assche
scsi: sysfs: Introduce sysfs_{un,}break_active_protection()
Bart Van Assche
scsi: mpt3sas: Fix _transport_smp_handler() error path
Sreekanth Reddy
scsi: mpt3sas: Fix calltrace observed while running IO & reset
Tomas Winkler
tpm: separate cmd_ready/go_idle from runtime_pm
Ricardo Schwarzmeier
tpm: Return the actual size when receiving an unsupported command
Paul Burton
MIPS: lib: Provide MIPS64r6 __multi3() for GCC < 7
Huacai Chen
MIPS: Change definition of cpu_relax() for Loongson-3
Paul Burton
MIPS: Always use -march=, not - shortcuts
Matt Redfearn
MIPS: memset.S: Fix byte_fixup for MIPSr6
Maciej W. Rozycki
MIPS: Correct the 64-bit DSP accumulator register size
Masami Hiramatsu
kprobes: Make list and blacklist root user read only
Masami Hiramatsu
kprobes/arm: Fix %p uses in error messages
Masami Hiramatsu
kprobes: Replace %p with other pointer types
Masami Hiramatsu
kprobes: Show blacklist addresses as same as kallsyms does
Philipp Rudo
s390/purgatory: Add missing FORCE to Makefile targets
Philipp Rudo
s390/purgatory: Fix crash with expoline enabled
Sebastian Ott
s390/pci: fix out of bounds access during irq setup
Martin Schwidefsky
s390/numa: move initial setup of node_to_cpumask_map
Julian Wiedmann
s390/qdio: reset old sbal_state flags
Martin Schwidefsky
s390: fix br_r1_trampoline for machines without exrl
Martin Schwidefsky
s390/lib: use expoline for all bcr instructions
Gerald Schaefer
s390/mm: fix addressing exception after suspend/resume
Ben Hutchings
x86: Allow generating user-space headers without a compiler
Jann Horn
x86/entry/64: Wipe KASAN stack shadow before rewind_stack_do_exit()
Gustavo A. R. Silva
hwmon: (nct6775) Fix potential Spectre v1
Andi Kleen
x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+
Andi Kleen
x86/spectre: Add missing family 6 check to microcode check
Nick Desaulniers
x86/irqflags: Mark native_restore_fl extern inline
Andy Lutomirski
x86/nmi: Fix NMI uaccess race against CR3 switching
Samuel Neves
x86/vdso: Fix lsl operand order
Himanshu Madhani
scsi: qla2xxx: Fix stalled relogin
Dan Carpenter
pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()
Johan Hovold
soc: qcom: rmtfs-mem: fix memleak in probe error paths
Ajit Pandey
ASoC: wm_adsp: Correct DSP pointer for preloader control
Gustavo A. R. Silva
ASoC: sirf: Fix potential NULL pointer dereference
Takashi Iwai
ASoC: zte: Fix incorrect PCM format bit usages
Jerome Brunet
ASoC: dpcm: don't merge format from invalid codec dai
Michael Buesch
b43/leds: Ensure NUL-termination of LED name string
Michael Buesch
b43legacy/leds: Ensure NUL-termination of LED name string
Mikulas Patocka
udl-kms: avoid division
Mikulas Patocka
udl-kms: fix crash due to uninitialized memory
Mikulas Patocka
udl-kms: handle allocation failure
