* 5.9.0-next-20201015: autofs oops in update-binfmts
@ 2020-10-16 12:35 Pavel Machek
2020-10-17 2:11 ` Ian Kent
0 siblings, 1 reply; 8+ messages in thread
From: Pavel Machek @ 2020-10-16 12:35 UTC (permalink / raw)
To: kernel list, autofs, raven, tglx, mingo, bp, x86, hpa
[-- Attachment #1: Type: text/plain, Size: 4188 bytes --]
Hi!
I'm getting this during boot: 32-bit thinkpad x60.
[ 10.718377] BUG: kernel NULL pointer dereference, address: 00000000
[ 10.721848] #PF: supervisor read access in kernel mode
[ 10.722763] #PF: error_code(0x0000) - not-present page
[ 10.726759] *pdpt = 000000000339e001 *pde = 0000000000000000
[ 10.730793] Oops: 0000 [#1] PREEMPT SMP PTI
[ 10.736201] CPU: 1 PID: 2762 Comm: update-binfmts Not tainted 5.9.0-next-20201015+ #152
[ 10.738769] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011
[ 10.742769] EIP: __kernel_write+0xd4/0x230
[ 10.746769] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31 d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01 00 00 00
[ 10.758762] EAX: 00020000 EBX: c1922a40 ECX: c33cdad0 EDX: 00000000
[ 10.762791] ESI: 00000000 EDI: 0000012c EBP: c33cdb20 ESP: c33cdacc
[ 10.766766] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286
[ 10.770762] CR0: 80050033 CR2: 00000000 CR3: 033d0000 CR4: 000006b0
[ 10.770762] Call Trace:
[ 10.770762] ? __mutex_unlock_slowpath+0x2b/0x2c0
[ 10.770762] ? dma_direct_map_sg+0x13a/0x320
[ 10.770762] autofs_notify_daemon+0x14d/0x2b0
[ 10.770762] autofs_wait+0x4cd/0x770
[ 10.793051] ? autofs_d_automount+0xd6/0x1e0
[ 10.793051] autofs_mount_wait+0x43/0xe0
[ 10.797808] autofs_d_automount+0xdf/0x1e0
[ 10.797808] __traverse_mounts+0x85/0x200
[ 10.797808] step_into+0x368/0x620
[ 10.797808] ? proc_setup_thread_self+0x110/0x110
[ 10.797808] walk_component+0x58/0x190
[ 10.811838] link_path_walk.part.0+0x245/0x360
[ 10.811838] path_lookupat.isra.0+0x31/0x130
[ 10.811838] filename_lookup+0x8d/0x130
[ 10.818749] ? cache_alloc_debugcheck_after+0x151/0x180
[ 10.818749] ? getname_flags+0x1f/0x160
[ 10.818749] ? kmem_cache_alloc+0x75/0x100
[ 10.818749] user_path_at_empty+0x25/0x30
[ 10.818749] vfs_statx+0x63/0x100
[ 10.831022] ? _raw_spin_unlock+0x18/0x30
[ 10.831022] ? replace_page_cache_page+0x160/0x160
[ 10.831022] __do_sys_stat64+0x36/0x60
[ 10.831022] ? exit_to_user_mode_prepare+0x35/0xe0
[ 10.831022] ? irqentry_exit_to_user_mode+0x8/0x20
[ 10.838773] ? irqentry_exit+0x55/0x70
[ 10.838773] ? exc_page_fault+0x228/0x3c0
[ 10.838773] __ia32_sys_stat64+0xd/0x10
[ 10.838773] do_int80_syscall_32+0x2c/0x40
[ 10.848561] entry_INT80_32+0x111/0x111
[ 10.848561] EIP: 0xb7ee2092
[ 10.848561] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 <c3> 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00
[ 10.848561] EAX: ffffffda EBX: 00468490 ECX: bfbce6ec EDX: 00467348
[ 10.848561] ESI: 00000000 EDI: 00468490 EBP: bfbce6ec ESP: bfbce6c4
[ 10.848561] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292
[ 10.848561] Modules linked in:
[ 10.848561] CR2: 0000000000000000
[ 10.851552] ---[ end trace d01bd7323c2317a5 ]---
[ 10.851558] EIP: __kernel_write+0xd4/0x230
[ 10.851561] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31 d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01 00 00 00
[ 10.851563] EAX: 00020000 EBX: c1922a40 ECX: c33cdad0 EDX: 00000000
[ 10.851565] ESI: 00000000 EDI: 0000012c EBP: c33cdb20 ESP: c33cdacc
[ 10.851568] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286
[ 10.851570] CR0: 80050033 CR2: 004a700e CR3: 033d0000 CR4: 000006b0
[ 11.803128] systemd-journald[2514]: Received request to flush runtime journal from PID 1
[ 26.113941] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9
[ 59.809322] traps: clock-applet[3636] trap int3 ip:b724ffc0 sp:bf879b90 error:0 in libglib-2.0.so.0.5000.3[b7203000+12a000]
[ 59.812036] traps: mateweather-app[3638] trap int3 ip:b7283fc0 sp:bfb65760 error:0 in libglib-2.0.so.0.5000.3[b7237000+12a000]
[ 64.628401] wlan0: authenticate with 5c:f4:ab:10:d2:bb
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 5.9.0-next-20201015: autofs oops in update-binfmts
2020-10-16 12:35 5.9.0-next-20201015: autofs oops in update-binfmts Pavel Machek
@ 2020-10-17 2:11 ` Ian Kent
2020-10-17 10:02 ` autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was " Pavel Machek
0 siblings, 1 reply; 8+ messages in thread
From: Ian Kent @ 2020-10-17 2:11 UTC (permalink / raw)
To: Pavel Machek, kernel list, autofs, tglx, mingo, bp, x86, hpa
On Fri, 2020-10-16 at 14:35 +0200, Pavel Machek wrote:
> Hi!
>
> I'm getting this during boot: 32-bit thinkpad x60.
This is very odd.
The change in next is essentially a revert of a change, maybe I'm
missing something and the revert isn't quite a revert. Although
there was one difference.
I'll check for other revert differences too.
Are you in a position to check a kernel without the 5.9 change
if I send you a patch?
And we should check if that difference to what was originally
there is the source of the problem, so probably two things to
follow up on, reverting that small difference first would be
the way to go.
Are you able to reliably reproduce it?
>
> [ 10.718377] BUG: kernel NULL pointer dereference, address:
> 00000000
> [ 10.721848] #PF: supervisor read access in kernel mode
> [ 10.722763] #PF: error_code(0x0000) - not-present page
> [ 10.726759] *pdpt = 000000000339e001 *pde = 0000000000000000
> [ 10.730793] Oops: 0000 [#1] PREEMPT SMP PTI
> [ 10.736201] CPU: 1 PID: 2762 Comm: update-binfmts Not tainted
> 5.9.0-next-20201015+ #152
> [ 10.738769] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW
> (2.19 ) 03/31/2011
> [ 10.742769] EIP: __kernel_write+0xd4/0x230
> [ 10.746769] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31
> d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66
> 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01
> 00 00 00
> [ 10.758762] EAX: 00020000 EBX: c1922a40 ECX: c33cdad0 EDX:
> 00000000
> [ 10.762791] ESI: 00000000 EDI: 0000012c EBP: c33cdb20 ESP:
> c33cdacc
> [ 10.766766] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
> 00010286
> [ 10.770762] CR0: 80050033 CR2: 00000000 CR3: 033d0000 CR4:
> 000006b0
> [ 10.770762] Call Trace:
> [ 10.770762] ? __mutex_unlock_slowpath+0x2b/0x2c0
> [ 10.770762] ? dma_direct_map_sg+0x13a/0x320
> [ 10.770762] autofs_notify_daemon+0x14d/0x2b0
> [ 10.770762] autofs_wait+0x4cd/0x770
> [ 10.793051] ? autofs_d_automount+0xd6/0x1e0
> [ 10.793051] autofs_mount_wait+0x43/0xe0
> [ 10.797808] autofs_d_automount+0xdf/0x1e0
> [ 10.797808] __traverse_mounts+0x85/0x200
> [ 10.797808] step_into+0x368/0x620
> [ 10.797808] ? proc_setup_thread_self+0x110/0x110
> [ 10.797808] walk_component+0x58/0x190
> [ 10.811838] link_path_walk.part.0+0x245/0x360
> [ 10.811838] path_lookupat.isra.0+0x31/0x130
> [ 10.811838] filename_lookup+0x8d/0x130
> [ 10.818749] ? cache_alloc_debugcheck_after+0x151/0x180
> [ 10.818749] ? getname_flags+0x1f/0x160
> [ 10.818749] ? kmem_cache_alloc+0x75/0x100
> [ 10.818749] user_path_at_empty+0x25/0x30
> [ 10.818749] vfs_statx+0x63/0x100
> [ 10.831022] ? _raw_spin_unlock+0x18/0x30
> [ 10.831022] ? replace_page_cache_page+0x160/0x160
> [ 10.831022] __do_sys_stat64+0x36/0x60
> [ 10.831022] ? exit_to_user_mode_prepare+0x35/0xe0
> [ 10.831022] ? irqentry_exit_to_user_mode+0x8/0x20
> [ 10.838773] ? irqentry_exit+0x55/0x70
> [ 10.838773] ? exc_page_fault+0x228/0x3c0
> [ 10.838773] __ia32_sys_stat64+0xd/0x10
> [ 10.838773] do_int80_syscall_32+0x2c/0x40
> [ 10.848561] entry_INT80_32+0x111/0x111
> [ 10.848561] EIP: 0xb7ee2092
> [ 10.848561] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30
> 00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00
> 00 cd 80 <c3> 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d
> b4 26 00
> [ 10.848561] EAX: ffffffda EBX: 00468490 ECX: bfbce6ec EDX:
> 00467348
> [ 10.848561] ESI: 00000000 EDI: 00468490 EBP: bfbce6ec ESP:
> bfbce6c4
> [ 10.848561] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS:
> 00000292
> [ 10.848561] Modules linked in:
> [ 10.848561] CR2: 0000000000000000
> [ 10.851552] ---[ end trace d01bd7323c2317a5 ]---
> [ 10.851558] EIP: __kernel_write+0xd4/0x230
> [ 10.851561] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31
> d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66
> 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01
> 00 00 00
> [ 10.851563] EAX: 00020000 EBX: c1922a40 ECX: c33cdad0 EDX:
> 00000000
> [ 10.851565] ESI: 00000000 EDI: 0000012c EBP: c33cdb20 ESP:
> c33cdacc
> [ 10.851568] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
> 00010286
> [ 10.851570] CR0: 80050033 CR2: 004a700e CR3: 033d0000 CR4:
> 000006b0
> [ 11.803128] systemd-journald[2514]: Received request to flush
> runtime journal from PID 1
> [ 26.113941] iwl3945 0000:03:00.0: loaded firmware version
> 15.32.2.9
> [ 59.809322] traps: clock-applet[3636] trap int3 ip:b724ffc0
> sp:bf879b90 error:0 in libglib-2.0.so.0.5000.3[b7203000+12a000]
> [ 59.812036] traps: mateweather-app[3638] trap int3 ip:b7283fc0
> sp:bfb65760 error:0 in libglib-2.0.so.0.5000.3[b7237000+12a000]
> [ 64.628401] wlan0: authenticate with 5c:f4:ab:10:d2:bb
>
--
Ian Kent <raven@themaw.net>
^ permalink raw reply [flat|nested] 8+ messages in thread
* autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was Re: 5.9.0-next-20201015: autofs oops in update-binfmts
2020-10-17 2:11 ` Ian Kent
@ 2020-10-17 10:02 ` Pavel Machek
2020-10-17 18:05 ` Linus Torvalds
0 siblings, 1 reply; 8+ messages in thread
From: Pavel Machek @ 2020-10-17 10:02 UTC (permalink / raw)
To: Ian Kent, torvalds, omosnace, hch
Cc: kernel list, autofs, tglx, mingo, bp, x86, hpa
[-- Attachment #1: Type: text/plain, Size: 5162 bytes --]
Hi!
> > I'm getting this during boot: 32-bit thinkpad x60.
>
> This is very odd.
>
> The change in next is essentially a revert of a change, maybe I'm
> missing something and the revert isn't quite a revert. Although
> there was one difference.
>
> I'll check for other revert differences too.
>
> Are you in a position to check a kernel without the 5.9 change
> if I send you a patch?
I think I can revert changes myself.
pavel@amd:/data/l/linux-next-32$ git show
90fb702791bf99b959006972e8ee7bb4609f441b | git apply -R
pavel@amd:/data/l/linux-next-32$
pavel@amd:/data/l/linux-next-32$ git show
d7a8c5c78d37500346c25cc8887ed2c3fda8ed4d | git apply -R
...and it boots up without a warning. Let me re-apply Linus' patch:
pavel@amd:/data/l/linux-next-32$ git show
90fb702791bf99b959006972e8ee7bb4609f441b | git apply
pavel@amd:/data/l/linux-next-32$
...and the oops is back:
Bad Linus!
[ 9.889419] EXT4-fs (sda2): mounted filesystem with ordered data
mode. Opts: errors=remount-ro
[ 10.042221] BUG: kernel NULL pointer dereference, address: 00000000
[ 10.045702] #PF: supervisor read access in kernel mode
[ 10.048142] #PF: error_code(0x0000) - not-present page
[ 10.052172] *pdpt = 00000000031ea001 *pde = 0000000000000000
[ 10.052172] Oops: 0000 [#1] PREEMPT SMP PTI
[ 10.052172] CPU: 1 PID: 2764 Comm: update-binfmts Not tainted
5.9.0-next-20201015+ #154
[ 10.065205] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW
(2.19 ) 03/31/2011
[ 10.065205] EIP: __kernel_write+0xd4/0x230
[ 10.065205] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31
d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66
89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01 00
00 00
[ 10.065205] EAX: 00020000 EBX: c192d640 ECX: c2b89ad0 EDX: 00000000
[ 10.065205] ESI: 00000000 EDI: 0000012c EBP: c2b89b20 ESP: c2b89acc
[ 10.065205] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
00010282
[ 10.065205] CR0: 80050033 CR2: 00000000 CR3: 03414000 CR4: 000006b0
[ 10.065205] Call Trace:
[ 10.065205] ? __mutex_unlock_slowpath+0x2b/0x2c0
[ 10.065205] ? dma_direct_map_sg+0x13a/0x320
[ 10.065205] autofs_notify_daemon+0x14d/0x2b0
[ 10.065205] autofs_wait+0x4cd/0x770
[ 10.065205] ? autofs_d_automount+0xd6/0x1e0
[ 10.065205] autofs_mount_wait+0x43/0xe0
[ 10.065205] autofs_d_automount+0xdf/0x1e0
[ 10.065205] __traverse_mounts+0x85/0x200
[ 10.065205] step_into+0x368/0x620
[ 10.065205] ? proc_setup_thread_self+0x110/0x110
[ 10.065205] walk_component+0x58/0x190
[ 10.065205] link_path_walk.part.0+0x245/0x360
[ 10.065205] path_lookupat.isra.0+0x31/0x130
[ 10.065205] filename_lookup+0x8d/0x130
[ 10.065205] ? cache_alloc_debugcheck_after+0x151/0x180
[ 10.065205] ? getname_flags+0x1f/0x160
[ 10.065205] ? kmem_cache_alloc+0x75/0x100
[ 10.065205] user_path_at_empty+0x25/0x30
[ 10.065205] vfs_statx+0x63/0x100
[ 10.065205] ? _raw_spin_unlock+0x18/0x30
[ 10.065205] ? replace_page_cache_page+0x160/0x160
[ 10.065205] __do_sys_stat64+0x36/0x60
[ 10.065205] ? exit_to_user_mode_prepare+0x35/0xe0
[ 10.065205] ? irqentry_exit_to_user_mode+0x8/0x20
[ 10.065205] ? irqentry_exit+0x55/0x70
[ 10.065205] ? exc_page_fault+0x228/0x3c0
[ 10.065205] __ia32_sys_stat64+0xd/0x10
[ 10.065205] do_int80_syscall_32+0x2c/0x40
[ 10.065205] entry_INT80_32+0x111/0x111
[ 10.065205] EIP: 0xb7f03092
[ 10.065205] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30
00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00
00 cd 80 <c3> 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4
26 00
[ 10.065205] EAX: ffffffda EBX: 004fa490 ECX: bfaf7e6c EDX: 004f9348
[ 10.065205] ESI: 00000000 EDI: 004fa490 EBP: bfaf7e6c ESP: bfaf7e44
[ 10.065205] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS:
00000296
[ 10.065205] Modules linked in:
[ 10.065205] CR2: 0000000000000000
[ 10.073216] ---[ end trace 13a709ba02b08366 ]---
[ 10.073221] EIP: __kernel_write+0xd4/0x230
[ 10.073224] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31
d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66
89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01 00
00 00
[ 10.073226] EAX: 00020000 EBX: c192d640 ECX: c2b89ad0 EDX: 00000000
[ 10.073228] ESI: 00000000 EDI: 0000012c EBP: c2b89b20 ESP: c2b89acc
[ 10.073230] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
00010282
[ 10.073232] CR0: 80050033 CR2: b7e10020 CR3: 03414000 CR4: 000006b0
[ 10.453818] systemd-journald[2512]: Received request to flush
runtime journal from PID 1
[ 24.752167] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9
> And we should check if that difference to what was originally
> there is the source of the problem, so probably two things to
> follow up on, reverting that small difference first would be
> the way to go.
>
> Are you able to reliably reproduce it?
Looks so, yes.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was Re: 5.9.0-next-20201015: autofs oops in update-binfmts
2020-10-17 10:02 ` autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was " Pavel Machek
@ 2020-10-17 18:05 ` Linus Torvalds
2020-10-17 19:47 ` Pavel Machek
2020-10-18 7:22 ` Christoph Hellwig
0 siblings, 2 replies; 8+ messages in thread
From: Linus Torvalds @ 2020-10-17 18:05 UTC (permalink / raw)
To: Pavel Machek
Cc: Ian Kent, Ondrej Mosnacek, Christoph Hellwig, kernel list,
autofs, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Peter Anvin
On Sat, Oct 17, 2020 at 3:02 AM Pavel Machek <pavel@ucw.cz> wrote:
>
> Bad Linus!
Christ people.
The bug is in linux-next, not in mainline. I've told the people
involved already over a week ago.
I can't do anything about linux-next being broken and people not fixing it.
Linus
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was Re: 5.9.0-next-20201015: autofs oops in update-binfmts
2020-10-17 18:05 ` Linus Torvalds
@ 2020-10-17 19:47 ` Pavel Machek
2020-10-18 0:13 ` Linus Torvalds
2020-10-18 7:22 ` Christoph Hellwig
1 sibling, 1 reply; 8+ messages in thread
From: Pavel Machek @ 2020-10-17 19:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ian Kent, Ondrej Mosnacek, Christoph Hellwig, kernel list,
autofs, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Peter Anvin
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Hi!
> > Bad Linus!
>
> Christ people.
https://www.christpeople.church/ ? Those are unlikely to help, I'd say :-).
> The bug is in linux-next, not in mainline. I've told the people
> involved already over a week ago.
Yes, I reported the bug against -next.
But: you are the last one to sign it off, so I assume committed it to
git, and you are the one to talk to about fixing it.
> I can't do anything about linux-next being broken and people not
> fixing it.
90fb702791bf99b959006972e8ee7bb4609f441b causes oops at boot for me.
So... I'm not git wizard, but... if I do log on v5.8, it is not in the
list, and if I do log on v5.9, it shows it.
So yes, I believe this in mainline.
Should I test v5.9 next? Or do you want me to test some patch?
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was Re: 5.9.0-next-20201015: autofs oops in update-binfmts
2020-10-17 19:47 ` Pavel Machek
@ 2020-10-18 0:13 ` Linus Torvalds
2020-10-26 8:38 ` Pavel Machek
0 siblings, 1 reply; 8+ messages in thread
From: Linus Torvalds @ 2020-10-18 0:13 UTC (permalink / raw)
To: Pavel Machek
Cc: Ian Kent, Ondrej Mosnacek, Christoph Hellwig, kernel list,
autofs, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Peter Anvin
On Sat, Oct 17, 2020 at 12:48 PM Pavel Machek <pavel@ucw.cz> wrote:
>
> But: you are the last one to sign it off, so I assume committed it to
> git, and you are the one to talk to about fixing it.
The thing is, the commit you point to - and the one I signed off on - is fine.
The buggy one is in linux-next, which breaks that whole "NULL means no
position" thing.
IOW, the real bug is in commit 4d03e3cc5982 ("fs: don't allow kernel
reads and writes without iter ops"), which does that bogus
kiocb.ki_pos = *pos;
and no, I never signed off on that.
Get it? Stop confusing people. This bug does not exist in mainline,
and never will. Because I'm not pulling that buggy commit.
The commit you talk about IS NOT THE BUGGY ONE.
Linus
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was Re: 5.9.0-next-20201015: autofs oops in update-binfmts
2020-10-18 0:13 ` Linus Torvalds
@ 2020-10-26 8:38 ` Pavel Machek
0 siblings, 0 replies; 8+ messages in thread
From: Pavel Machek @ 2020-10-26 8:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ian Kent, Ondrej Mosnacek, Christoph Hellwig, kernel list,
autofs, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Peter Anvin
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Sat 2020-10-17 17:13:20, Linus Torvalds wrote:
> On Sat, Oct 17, 2020 at 12:48 PM Pavel Machek <pavel@ucw.cz> wrote:
> >
> > But: you are the last one to sign it off, so I assume committed it to
> > git, and you are the one to talk to about fixing it.
>
> The thing is, the commit you point to - and the one I signed off on - is fine.
>
> The buggy one is in linux-next, which breaks that whole "NULL means no
> position" thing.
>
> IOW, the real bug is in commit 4d03e3cc5982 ("fs: don't allow kernel
> reads and writes without iter ops"), which does that bogus
>
> kiocb.ki_pos = *pos;
>
> and no, I never signed off on that.
>
> Get it? Stop confusing people. This bug does not exist in mainline,
> and never will. Because I'm not pulling that buggy commit.
And I guess that's a good thing. It is now fixed in -next, too. Sorry
for the noise.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was Re: 5.9.0-next-20201015: autofs oops in update-binfmts
2020-10-17 18:05 ` Linus Torvalds
2020-10-17 19:47 ` Pavel Machek
@ 2020-10-18 7:22 ` Christoph Hellwig
1 sibling, 0 replies; 8+ messages in thread
From: Christoph Hellwig @ 2020-10-18 7:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pavel Machek, Ian Kent, Ondrej Mosnacek, Christoph Hellwig,
kernel list, autofs, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, the arch/x86 maintainers, Peter Anvin
On Sat, Oct 17, 2020 at 11:05:06AM -0700, Linus Torvalds wrote:
> On Sat, Oct 17, 2020 at 3:02 AM Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Bad Linus!
>
> Christ people.
>
> The bug is in linux-next, not in mainline. I've told the people
> involved already over a week ago.
>
> I can't do anything about linux-next being broken and people not fixing it.
While it took longer than I would have preferred, Al has commited the
fix to his for-next tree a few days ago:
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=for-next&id=4c207ef48269377236cd38979197c5e1631c8c16
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-10-26 8:38 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-16 12:35 5.9.0-next-20201015: autofs oops in update-binfmts Pavel Machek
2020-10-17 2:11 ` Ian Kent
2020-10-17 10:02 ` autofs: use __kernel_write() for the autofs pipe writing causes regression in -next was " Pavel Machek
2020-10-17 18:05 ` Linus Torvalds
2020-10-17 19:47 ` Pavel Machek
2020-10-18 0:13 ` Linus Torvalds
2020-10-26 8:38 ` Pavel Machek
2020-10-18 7:22 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).