Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Fri, Jul 13, 2018 at 11:28:28AM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 12, 2018 at 12:30:01PM -0600, Tycho Andersen wrote: > > On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > > > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > > > + if (uport) > > > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why > > > > > > > aren't you > > > > > > > doing that? > > > > > > > > > > > > Because the compiler can't seem to "see" through the macros/ref > > > > > > calls, > > > > > > and I get the warning I mentioned here if I use them: > > > > > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > > > > > What horrible version of gcc are you using that give you that? Don't > > > > > open-code things just because of a broken compiler. > > > > > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > > > here but not elsewhere in the file is because there's an actual > > > > function call (free_page()) in the critical section. > > > > > > > > If we move that out, something like the below patch, it all works for > > > > me. > > > > > > Ick. Which version of this series had the problem? Let me test it out > > > here... > > > > v3, if you remove the initialization of flags from both functions you > > should see it. > > Ok, I tried v3 out and yes, you are right, removing the "= 0" causes gcc > to complain. The compiler is being dumb here, so I'll just leave it > as-is. I've queued up the v3 version now, thanks for sticking with > this. Great, thanks! Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Fri, Jul 13, 2018 at 11:28:28AM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 12, 2018 at 12:30:01PM -0600, Tycho Andersen wrote: > > On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > > > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > > > + if (uport) > > > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why > > > > > > > aren't you > > > > > > > doing that? > > > > > > > > > > > > Because the compiler can't seem to "see" through the macros/ref > > > > > > calls, > > > > > > and I get the warning I mentioned here if I use them: > > > > > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > > > > > What horrible version of gcc are you using that give you that? Don't > > > > > open-code things just because of a broken compiler. > > > > > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > > > here but not elsewhere in the file is because there's an actual > > > > function call (free_page()) in the critical section. > > > > > > > > If we move that out, something like the below patch, it all works for > > > > me. > > > > > > Ick. Which version of this series had the problem? Let me test it out > > > here... > > > > v3, if you remove the initialization of flags from both functions you > > should see it. > > Ok, I tried v3 out and yes, you are right, removing the "= 0" causes gcc > to complain. The compiler is being dumb here, so I'll just leave it > as-is. I've queued up the v3 version now, thanks for sticking with > this. Great, thanks! Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 12:30:01PM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > > + if (uport) > > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't > > > > > > you > > > > > > doing that? > > > > > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > > > and I get the warning I mentioned here if I use them: > > > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > > > What horrible version of gcc are you using that give you that? Don't > > > > open-code things just because of a broken compiler. > > > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > > here but not elsewhere in the file is because there's an actual > > > function call (free_page()) in the critical section. > > > > > > If we move that out, something like the below patch, it all works for > > > me. > > > > Ick. Which version of this series had the problem? Let me test it out > > here... > > v3, if you remove the initialization of flags from both functions you > should see it. Ok, I tried v3 out and yes, you are right, removing the "= 0" causes gcc to complain. The compiler is being dumb here, so I'll just leave it as-is. I've queued up the v3 version now, thanks for sticking with this. greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 12:30:01PM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > > + if (uport) > > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't > > > > > > you > > > > > > doing that? > > > > > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > > > and I get the warning I mentioned here if I use them: > > > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > > > What horrible version of gcc are you using that give you that? Don't > > > > open-code things just because of a broken compiler. > > > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > > here but not elsewhere in the file is because there's an actual > > > function call (free_page()) in the critical section. > > > > > > If we move that out, something like the below patch, it all works for > > > me. > > > > Ick. Which version of this series had the problem? Let me test it out > > here... > > v3, if you remove the initialization of flags from both functions you > should see it. Ok, I tried v3 out and yes, you are right, removing the "= 0" causes gcc to complain. The compiler is being dumb here, so I'll just leave it as-is. I've queued up the v3 version now, thanks for sticking with this. greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > + if (uport) > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > > > > doing that? > > > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > > and I get the warning I mentioned here if I use them: > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > What horrible version of gcc are you using that give you that? Don't > > > open-code things just because of a broken compiler. > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > here but not elsewhere in the file is because there's an actual > > function call (free_page()) in the critical section. > > > > If we move that out, something like the below patch, it all works for > > me. > > Ick. Which version of this series had the problem? Let me test it out > here... v3, if you remove the initialization of flags from both functions you should see it. Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > + if (uport) > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > > > > doing that? > > > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > > and I get the warning I mentioned here if I use them: > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > What horrible version of gcc are you using that give you that? Don't > > > open-code things just because of a broken compiler. > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > here but not elsewhere in the file is because there's an actual > > function call (free_page()) in the critical section. > > > > If we move that out, something like the below patch, it all works for > > me. > > Ick. Which version of this series had the problem? Let me test it out > here... v3, if you remove the initialization of flags from both functions you should see it. Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > + if (uport) > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > > > doing that? > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > and I get the warning I mentioned here if I use them: > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > What horrible version of gcc are you using that give you that? Don't > > open-code things just because of a broken compiler. > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > here but not elsewhere in the file is because there's an actual > function call (free_page()) in the critical section. > > If we move that out, something like the below patch, it all works for > me. Ick. Which version of this series had the problem? Let me test it out here... thanks, greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > + if (uport) > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > > > doing that? > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > and I get the warning I mentioned here if I use them: > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > What horrible version of gcc are you using that give you that? Don't > > open-code things just because of a broken compiler. > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > here but not elsewhere in the file is because there's an actual > function call (free_page()) in the critical section. > > If we move that out, something like the below patch, it all works for > me. Ick. Which version of this series had the problem? Let me test it out here... thanks, greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > + if (uport) > > > > + spin_lock_irqsave(>lock, flags); > > > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > > doing that? > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > and I get the warning I mentioned here if I use them: > > > > https://lkml.org/lkml/2018/7/6/840 > > What horrible version of gcc are you using that give you that? Don't > open-code things just because of a broken compiler. I've tried with both 7.3.0 and 5.4.0. I think the reason we see this here but not elsewhere in the file is because there's an actual function call (free_page()) in the critical section. If we move that out, something like the below patch, it all works for me. Tycho >From 532e82ceec67142b71c60ce74ce08c5339195a94 Mon Sep 17 00:00:00 2001 From: Tycho Andersen Date: Mon, 4 Jun 2018 09:55:09 -0600 Subject: [PATCH] uart: fix race between uart_put_char() and uart_shutdown() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We have reports of the following crash: PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" #0 [88085c6db710] machine_kexec at 81046239 #1 [88085c6db760] crash_kexec at 810fc248 #2 [88085c6db830] oops_end at 81008ae7 #3 [88085c6db860] no_context at 81050b8f #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 #5 [88085c6db900] bad_area_nosemaphore at 81050e83 #6 [88085c6db910] __do_page_fault at 8105132e #7 [88085c6db9b0] do_page_fault at 8105152c #8 [88085c6db9c0] page_fault at 81a3f122 [exception RIP: uart_put_char+149] RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 RAX: 0292 RBX: 827c5120 RCX: 0081 RDX: RSI: 005f RDI: 827c5120 RBP: 88085c6dba98 R8: 012c R9: 822ea320 R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 R13: 0001 R14: 005f R15: 0fba ORIG_RAX: CS: 0010 SS: 0018 #9 [88085c6dbaa0] tty_put_char at 81497544 #10 [88085c6dbac0] do_output_char at 8149c91c #11 [88085c6dbae0] __process_echoes at 8149cb8b #12 [88085c6dbb30] commit_echoes at 8149cdc2 #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b #14 [88085c6dbbc0] __receive_buf at 8149ef5a #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 #17 [88085c6dbcb0] flush_to_ldisc at 814a238a #18 [88085c6dbd50] process_one_work at 81090be2 #19 [88085c6dbe20] worker_thread at 81091b4d #20 [88085c6dbeb0] kthread at 81096384 #21 [88085c6dbf50] ret_from_fork at 81a3d69f after slogging through some dissasembly: 814b6720 : 814b6720: 55 push %rbp 814b6721: 48 89 e5mov%rsp,%rbp 814b6724: 48 83 ec 20 sub$0x20,%rsp 814b6728: 48 89 1c 24 mov%rbx,(%rsp) 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 814b6747: 45 31 edxor%r13d,%r13d 814b674a: 41 89 f6mov%esi,%r14d 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) 814b6754: 00 00 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx 814b675d: 00 814b675e: 74 2f je 814b678f 814b6760: 48 89 dfmov%rbx,%rdi 814b6763: e8 a8 67 58 00 callq 81a3cf10 <_raw_spin_lock_irqsave> 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx 814b676f: 00 814b6770: 89 ca mov%ecx,%edx 814b6772: f7 d2 not%edx 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx 814b677b: 00 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx 814b6782: 75 23
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > + if (uport) > > > > + spin_lock_irqsave(>lock, flags); > > > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > > doing that? > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > and I get the warning I mentioned here if I use them: > > > > https://lkml.org/lkml/2018/7/6/840 > > What horrible version of gcc are you using that give you that? Don't > open-code things just because of a broken compiler. I've tried with both 7.3.0 and 5.4.0. I think the reason we see this here but not elsewhere in the file is because there's an actual function call (free_page()) in the critical section. If we move that out, something like the below patch, it all works for me. Tycho >From 532e82ceec67142b71c60ce74ce08c5339195a94 Mon Sep 17 00:00:00 2001 From: Tycho Andersen Date: Mon, 4 Jun 2018 09:55:09 -0600 Subject: [PATCH] uart: fix race between uart_put_char() and uart_shutdown() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We have reports of the following crash: PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" #0 [88085c6db710] machine_kexec at 81046239 #1 [88085c6db760] crash_kexec at 810fc248 #2 [88085c6db830] oops_end at 81008ae7 #3 [88085c6db860] no_context at 81050b8f #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 #5 [88085c6db900] bad_area_nosemaphore at 81050e83 #6 [88085c6db910] __do_page_fault at 8105132e #7 [88085c6db9b0] do_page_fault at 8105152c #8 [88085c6db9c0] page_fault at 81a3f122 [exception RIP: uart_put_char+149] RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 RAX: 0292 RBX: 827c5120 RCX: 0081 RDX: RSI: 005f RDI: 827c5120 RBP: 88085c6dba98 R8: 012c R9: 822ea320 R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 R13: 0001 R14: 005f R15: 0fba ORIG_RAX: CS: 0010 SS: 0018 #9 [88085c6dbaa0] tty_put_char at 81497544 #10 [88085c6dbac0] do_output_char at 8149c91c #11 [88085c6dbae0] __process_echoes at 8149cb8b #12 [88085c6dbb30] commit_echoes at 8149cdc2 #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b #14 [88085c6dbbc0] __receive_buf at 8149ef5a #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 #17 [88085c6dbcb0] flush_to_ldisc at 814a238a #18 [88085c6dbd50] process_one_work at 81090be2 #19 [88085c6dbe20] worker_thread at 81091b4d #20 [88085c6dbeb0] kthread at 81096384 #21 [88085c6dbf50] ret_from_fork at 81a3d69f after slogging through some dissasembly: 814b6720 : 814b6720: 55 push %rbp 814b6721: 48 89 e5mov%rsp,%rbp 814b6724: 48 83 ec 20 sub$0x20,%rsp 814b6728: 48 89 1c 24 mov%rbx,(%rsp) 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 814b6747: 45 31 edxor%r13d,%r13d 814b674a: 41 89 f6mov%esi,%r14d 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) 814b6754: 00 00 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx 814b675d: 00 814b675e: 74 2f je 814b678f 814b6760: 48 89 dfmov%rbx,%rdi 814b6763: e8 a8 67 58 00 callq 81a3cf10 <_raw_spin_lock_irqsave> 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx 814b676f: 00 814b6770: 89 ca mov%ecx,%edx 814b6772: f7 d2 not%edx 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx 814b677b: 00 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx 814b6782: 75 23
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > + if (uport) > > > + spin_lock_irqsave(>lock, flags); > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > doing that? > > Because the compiler can't seem to "see" through the macros/ref calls, > and I get the warning I mentioned here if I use them: > > https://lkml.org/lkml/2018/7/6/840 What horrible version of gcc are you using that give you that? Don't open-code things just because of a broken compiler. thanks, greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > + if (uport) > > > + spin_lock_irqsave(>lock, flags); > > > > That's the same thing as just calling uart_port_lock(), why aren't you > > doing that? > > Because the compiler can't seem to "see" through the macros/ref calls, > and I get the warning I mentioned here if I use them: > > https://lkml.org/lkml/2018/7/6/840 What horrible version of gcc are you using that give you that? Don't open-code things just because of a broken compiler. thanks, greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > + if (uport) > > + spin_lock_irqsave(>lock, flags); > > That's the same thing as just calling uart_port_lock(), why aren't you > doing that? Because the compiler can't seem to "see" through the macros/ref calls, and I get the warning I mentioned here if I use them: https://lkml.org/lkml/2018/7/6/840 Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > + if (uport) > > + spin_lock_irqsave(>lock, flags); > > That's the same thing as just calling uart_port_lock(), why aren't you > doing that? Because the compiler can't seem to "see" through the macros/ref calls, and I get the warning I mentioned here if I use them: https://lkml.org/lkml/2018/7/6/840 Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 02:00:56PM -0600, Tycho Andersen wrote: > On Wed, Jul 11, 2018 at 02:49:08PM -0500, Serge E. Hallyn wrote: > > Quoting Tycho Andersen (ty...@tycho.ws): > > > We have reports of the following crash: > > > > > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > > > #0 [88085c6db710] machine_kexec at 81046239 > > > #1 [88085c6db760] crash_kexec at 810fc248 > > > #2 [88085c6db830] oops_end at 81008ae7 > > > #3 [88085c6db860] no_context at 81050b8f > > > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > > > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > > > #6 [88085c6db910] __do_page_fault at 8105132e > > > #7 [88085c6db9b0] do_page_fault at 8105152c > > > #8 [88085c6db9c0] page_fault at 81a3f122 > > > [exception RIP: uart_put_char+149] > > > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > > > RAX: 0292 RBX: 827c5120 RCX: 0081 > > > RDX: RSI: 005f RDI: 827c5120 > > > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > > > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > > > R13: 0001 R14: 005f R15: 0fba > > > ORIG_RAX: CS: 0010 SS: 0018 > > > #9 [88085c6dbaa0] tty_put_char at 81497544 > > > #10 [88085c6dbac0] do_output_char at 8149c91c > > > #11 [88085c6dbae0] __process_echoes at 8149cb8b > > > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > > > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > > > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > > > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > > > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > > > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > > > #18 [88085c6dbd50] process_one_work at 81090be2 > > > #19 [88085c6dbe20] worker_thread at 81091b4d > > > #20 [88085c6dbeb0] kthread at 81096384 > > > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > > > > > after slogging through some dissasembly: > > > > > > 814b6720 : > > > 814b6720: 55 push %rbp > > > 814b6721: 48 89 e5mov%rsp,%rbp > > > 814b6724: 48 83 ec 20 sub$0x20,%rsp > > > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > > > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > > > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > > > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > > > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > > > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > > > 814b6747: 45 31 edxor%r13d,%r13d > > > 814b674a: 41 89 f6mov%esi,%r14d > > > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > > > 814b6754: 00 00 > > > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > > > 814b675d: 00 > > > 814b675e: 74 2f je 814b678f > > > > > > 814b6760: 48 89 dfmov%rbx,%rdi > > > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > > > <_raw_spin_lock_irqsave> > > > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > > > 814b676f: 00 > > > 814b6770: 89 ca mov%ecx,%edx > > > 814b6772: f7 d2 not%edx > > > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > > > 814b677b: 00 > > > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > > > 814b6782: 75 23 jne814b67a7 > > > > > > 814b6784: 48 89 c6mov%rax,%rsi > > > 814b6787: 48 89 dfmov%rbx,%rdi > > > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > > > <_raw_spin_unlock_irqrestore> > > > 814b678f: 44 89 e8mov%r13d,%eax > > > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > > > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > > > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > > > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > > > 814b67a5: c9 leaveq > > > 814b67a6: c3 retq > > > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > > > 814b67ae: 00 > > > 814b67af: 48 63 c9movslq %ecx,%rcx > > > 814b67b2: 41 b5 01
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 02:00:56PM -0600, Tycho Andersen wrote: > On Wed, Jul 11, 2018 at 02:49:08PM -0500, Serge E. Hallyn wrote: > > Quoting Tycho Andersen (ty...@tycho.ws): > > > We have reports of the following crash: > > > > > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > > > #0 [88085c6db710] machine_kexec at 81046239 > > > #1 [88085c6db760] crash_kexec at 810fc248 > > > #2 [88085c6db830] oops_end at 81008ae7 > > > #3 [88085c6db860] no_context at 81050b8f > > > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > > > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > > > #6 [88085c6db910] __do_page_fault at 8105132e > > > #7 [88085c6db9b0] do_page_fault at 8105152c > > > #8 [88085c6db9c0] page_fault at 81a3f122 > > > [exception RIP: uart_put_char+149] > > > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > > > RAX: 0292 RBX: 827c5120 RCX: 0081 > > > RDX: RSI: 005f RDI: 827c5120 > > > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > > > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > > > R13: 0001 R14: 005f R15: 0fba > > > ORIG_RAX: CS: 0010 SS: 0018 > > > #9 [88085c6dbaa0] tty_put_char at 81497544 > > > #10 [88085c6dbac0] do_output_char at 8149c91c > > > #11 [88085c6dbae0] __process_echoes at 8149cb8b > > > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > > > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > > > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > > > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > > > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > > > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > > > #18 [88085c6dbd50] process_one_work at 81090be2 > > > #19 [88085c6dbe20] worker_thread at 81091b4d > > > #20 [88085c6dbeb0] kthread at 81096384 > > > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > > > > > after slogging through some dissasembly: > > > > > > 814b6720 : > > > 814b6720: 55 push %rbp > > > 814b6721: 48 89 e5mov%rsp,%rbp > > > 814b6724: 48 83 ec 20 sub$0x20,%rsp > > > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > > > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > > > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > > > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > > > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > > > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > > > 814b6747: 45 31 edxor%r13d,%r13d > > > 814b674a: 41 89 f6mov%esi,%r14d > > > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > > > 814b6754: 00 00 > > > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > > > 814b675d: 00 > > > 814b675e: 74 2f je 814b678f > > > > > > 814b6760: 48 89 dfmov%rbx,%rdi > > > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > > > <_raw_spin_lock_irqsave> > > > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > > > 814b676f: 00 > > > 814b6770: 89 ca mov%ecx,%edx > > > 814b6772: f7 d2 not%edx > > > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > > > 814b677b: 00 > > > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > > > 814b6782: 75 23 jne814b67a7 > > > > > > 814b6784: 48 89 c6mov%rax,%rsi > > > 814b6787: 48 89 dfmov%rbx,%rdi > > > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > > > <_raw_spin_unlock_irqrestore> > > > 814b678f: 44 89 e8mov%r13d,%eax > > > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > > > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > > > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > > > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > > > 814b67a5: c9 leaveq > > > 814b67a6: c3 retq > > > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > > > 814b67ae: 00 > > > 814b67af: 48 63 c9movslq %ecx,%rcx > > > 814b67b2: 41 b5 01
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > + if (uport) > + spin_lock_irqsave(>lock, flags); That's the same thing as just calling uart_port_lock(), why aren't you doing that? thanks, greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > + if (uport) > + spin_lock_irqsave(>lock, flags); That's the same thing as just calling uart_port_lock(), why aren't you doing that? thanks, greg k-h
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
Hi Andy, On Thu, Jul 12, 2018 at 12:03:08PM +0300, Andy Shevchenko wrote: > On Wed, Jul 11, 2018 at 7:07 PM, Tycho Andersen wrote: > > > Anyway, since the lock is not acquired, if uart_shutdown() is called, the > > last chunk of that function may release state->xmit.buf before its assigned > > to null, and cause the race above. > > > > To fix it, let's lock uport->lock when allocating/deallocating > > state->xmit.buf in addition to the per-port mutex. > > > * use the result of uart_port_lock() in uart_shutdown() to avoid > > uninitialized warning > > * don't use the uart_port_lock/unlock macros in uart_port_startup, > > instead test against uport directly; the compiler can't seem to "see" > > through the macros/ref/unref calls to not warn about uninitialized > > flags. We don't need to do a ref here since we hold the per-port > > mutex anyway. > > > + if (uport) > > + spin_lock_irqsave(>lock, flags); > > > + if (uport) > > + spin_unlock_irqrestore(>lock, flags); > > At some point it It was uart_port_lock()/uart_port_unlock(), and you > changed to simple spin lock. The macro also take reference to the > port. Do we aware about that here? I don't think so, the commit message you quoted above says, > We don't need to do a ref here since we hold the per-port mutex > anyway. Cheers, Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
Hi Andy, On Thu, Jul 12, 2018 at 12:03:08PM +0300, Andy Shevchenko wrote: > On Wed, Jul 11, 2018 at 7:07 PM, Tycho Andersen wrote: > > > Anyway, since the lock is not acquired, if uart_shutdown() is called, the > > last chunk of that function may release state->xmit.buf before its assigned > > to null, and cause the race above. > > > > To fix it, let's lock uport->lock when allocating/deallocating > > state->xmit.buf in addition to the per-port mutex. > > > * use the result of uart_port_lock() in uart_shutdown() to avoid > > uninitialized warning > > * don't use the uart_port_lock/unlock macros in uart_port_startup, > > instead test against uport directly; the compiler can't seem to "see" > > through the macros/ref/unref calls to not warn about uninitialized > > flags. We don't need to do a ref here since we hold the per-port > > mutex anyway. > > > + if (uport) > > + spin_lock_irqsave(>lock, flags); > > > + if (uport) > > + spin_unlock_irqrestore(>lock, flags); > > At some point it It was uart_port_lock()/uart_port_unlock(), and you > changed to simple spin lock. The macro also take reference to the > port. Do we aware about that here? I don't think so, the commit message you quoted above says, > We don't need to do a ref here since we hold the per-port mutex > anyway. Cheers, Tycho
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 7:07 PM, Tycho Andersen wrote: > Anyway, since the lock is not acquired, if uart_shutdown() is called, the > last chunk of that function may release state->xmit.buf before its assigned > to null, and cause the race above. > > To fix it, let's lock uport->lock when allocating/deallocating > state->xmit.buf in addition to the per-port mutex. > * use the result of uart_port_lock() in uart_shutdown() to avoid > uninitialized warning > * don't use the uart_port_lock/unlock macros in uart_port_startup, > instead test against uport directly; the compiler can't seem to "see" > through the macros/ref/unref calls to not warn about uninitialized > flags. We don't need to do a ref here since we hold the per-port > mutex anyway. > + if (uport) > + spin_lock_irqsave(>lock, flags); > + if (uport) > + spin_unlock_irqrestore(>lock, flags); At some point it It was uart_port_lock()/uart_port_unlock(), and you changed to simple spin lock. The macro also take reference to the port. Do we aware about that here? -- With Best Regards, Andy Shevchenko
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 7:07 PM, Tycho Andersen wrote: > Anyway, since the lock is not acquired, if uart_shutdown() is called, the > last chunk of that function may release state->xmit.buf before its assigned > to null, and cause the race above. > > To fix it, let's lock uport->lock when allocating/deallocating > state->xmit.buf in addition to the per-port mutex. > * use the result of uart_port_lock() in uart_shutdown() to avoid > uninitialized warning > * don't use the uart_port_lock/unlock macros in uart_port_startup, > instead test against uport directly; the compiler can't seem to "see" > through the macros/ref/unref calls to not warn about uninitialized > flags. We don't need to do a ref here since we hold the per-port > mutex anyway. > + if (uport) > + spin_lock_irqsave(>lock, flags); > + if (uport) > + spin_unlock_irqrestore(>lock, flags); At some point it It was uart_port_lock()/uart_port_unlock(), and you changed to simple spin lock. The macro also take reference to the port. Do we aware about that here? -- With Best Regards, Andy Shevchenko
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 02:49:08PM -0500, Serge E. Hallyn wrote: > Quoting Tycho Andersen (ty...@tycho.ws): > > We have reports of the following crash: > > > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > > #0 [88085c6db710] machine_kexec at 81046239 > > #1 [88085c6db760] crash_kexec at 810fc248 > > #2 [88085c6db830] oops_end at 81008ae7 > > #3 [88085c6db860] no_context at 81050b8f > > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > > #6 [88085c6db910] __do_page_fault at 8105132e > > #7 [88085c6db9b0] do_page_fault at 8105152c > > #8 [88085c6db9c0] page_fault at 81a3f122 > > [exception RIP: uart_put_char+149] > > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > > RAX: 0292 RBX: 827c5120 RCX: 0081 > > RDX: RSI: 005f RDI: 827c5120 > > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > > R13: 0001 R14: 005f R15: 0fba > > ORIG_RAX: CS: 0010 SS: 0018 > > #9 [88085c6dbaa0] tty_put_char at 81497544 > > #10 [88085c6dbac0] do_output_char at 8149c91c > > #11 [88085c6dbae0] __process_echoes at 8149cb8b > > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > > #18 [88085c6dbd50] process_one_work at 81090be2 > > #19 [88085c6dbe20] worker_thread at 81091b4d > > #20 [88085c6dbeb0] kthread at 81096384 > > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > > > after slogging through some dissasembly: > > > > 814b6720 : > > 814b6720: 55 push %rbp > > 814b6721: 48 89 e5mov%rsp,%rbp > > 814b6724: 48 83 ec 20 sub$0x20,%rsp > > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > > 814b6747: 45 31 edxor%r13d,%r13d > > 814b674a: 41 89 f6mov%esi,%r14d > > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > > 814b6754: 00 00 > > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > > 814b675d: 00 > > 814b675e: 74 2f je 814b678f > > > > 814b6760: 48 89 dfmov%rbx,%rdi > > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > > <_raw_spin_lock_irqsave> > > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > > 814b676f: 00 > > 814b6770: 89 ca mov%ecx,%edx > > 814b6772: f7 d2 not%edx > > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > > 814b677b: 00 > > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > > 814b6782: 75 23 jne814b67a7 > > > > 814b6784: 48 89 c6mov%rax,%rsi > > 814b6787: 48 89 dfmov%rbx,%rdi > > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > > <_raw_spin_unlock_irqrestore> > > 814b678f: 44 89 e8mov%r13d,%eax > > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > > 814b67a5: c9 leaveq > > 814b67a6: c3 retq > > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > > 814b67ae: 00 > > 814b67af: 48 63 c9movslq %ecx,%rcx > > 814b67b2: 41 b5 01mov$0x1,%r13b > > 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) > > 814b67b9: 41 8b 94 24 78 01 00mov
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Wed, Jul 11, 2018 at 02:49:08PM -0500, Serge E. Hallyn wrote: > Quoting Tycho Andersen (ty...@tycho.ws): > > We have reports of the following crash: > > > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > > #0 [88085c6db710] machine_kexec at 81046239 > > #1 [88085c6db760] crash_kexec at 810fc248 > > #2 [88085c6db830] oops_end at 81008ae7 > > #3 [88085c6db860] no_context at 81050b8f > > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > > #6 [88085c6db910] __do_page_fault at 8105132e > > #7 [88085c6db9b0] do_page_fault at 8105152c > > #8 [88085c6db9c0] page_fault at 81a3f122 > > [exception RIP: uart_put_char+149] > > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > > RAX: 0292 RBX: 827c5120 RCX: 0081 > > RDX: RSI: 005f RDI: 827c5120 > > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > > R13: 0001 R14: 005f R15: 0fba > > ORIG_RAX: CS: 0010 SS: 0018 > > #9 [88085c6dbaa0] tty_put_char at 81497544 > > #10 [88085c6dbac0] do_output_char at 8149c91c > > #11 [88085c6dbae0] __process_echoes at 8149cb8b > > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > > #18 [88085c6dbd50] process_one_work at 81090be2 > > #19 [88085c6dbe20] worker_thread at 81091b4d > > #20 [88085c6dbeb0] kthread at 81096384 > > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > > > after slogging through some dissasembly: > > > > 814b6720 : > > 814b6720: 55 push %rbp > > 814b6721: 48 89 e5mov%rsp,%rbp > > 814b6724: 48 83 ec 20 sub$0x20,%rsp > > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > > 814b6747: 45 31 edxor%r13d,%r13d > > 814b674a: 41 89 f6mov%esi,%r14d > > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > > 814b6754: 00 00 > > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > > 814b675d: 00 > > 814b675e: 74 2f je 814b678f > > > > 814b6760: 48 89 dfmov%rbx,%rdi > > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > > <_raw_spin_lock_irqsave> > > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > > 814b676f: 00 > > 814b6770: 89 ca mov%ecx,%edx > > 814b6772: f7 d2 not%edx > > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > > 814b677b: 00 > > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > > 814b6782: 75 23 jne814b67a7 > > > > 814b6784: 48 89 c6mov%rax,%rsi > > 814b6787: 48 89 dfmov%rbx,%rdi > > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > > <_raw_spin_unlock_irqrestore> > > 814b678f: 44 89 e8mov%r13d,%eax > > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > > 814b67a5: c9 leaveq > > 814b67a6: c3 retq > > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > > 814b67ae: 00 > > 814b67af: 48 63 c9movslq %ecx,%rcx > > 814b67b2: 41 b5 01mov$0x1,%r13b > > 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) > > 814b67b9: 41 8b 94 24 78 01 00mov
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
Quoting Tycho Andersen (ty...@tycho.ws): > We have reports of the following crash: > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > #0 [88085c6db710] machine_kexec at 81046239 > #1 [88085c6db760] crash_kexec at 810fc248 > #2 [88085c6db830] oops_end at 81008ae7 > #3 [88085c6db860] no_context at 81050b8f > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > #6 [88085c6db910] __do_page_fault at 8105132e > #7 [88085c6db9b0] do_page_fault at 8105152c > #8 [88085c6db9c0] page_fault at 81a3f122 > [exception RIP: uart_put_char+149] > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > RAX: 0292 RBX: 827c5120 RCX: 0081 > RDX: RSI: 005f RDI: 827c5120 > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > R13: 0001 R14: 005f R15: 0fba > ORIG_RAX: CS: 0010 SS: 0018 > #9 [88085c6dbaa0] tty_put_char at 81497544 > #10 [88085c6dbac0] do_output_char at 8149c91c > #11 [88085c6dbae0] __process_echoes at 8149cb8b > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > #18 [88085c6dbd50] process_one_work at 81090be2 > #19 [88085c6dbe20] worker_thread at 81091b4d > #20 [88085c6dbeb0] kthread at 81096384 > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > after slogging through some dissasembly: > > 814b6720 : > 814b6720: 55 push %rbp > 814b6721: 48 89 e5mov%rsp,%rbp > 814b6724: 48 83 ec 20 sub$0x20,%rsp > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > 814b6747: 45 31 edxor%r13d,%r13d > 814b674a: 41 89 f6mov%esi,%r14d > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > 814b6754: 00 00 > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > 814b675d: 00 > 814b675e: 74 2f je 814b678f > > 814b6760: 48 89 dfmov%rbx,%rdi > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > <_raw_spin_lock_irqsave> > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > 814b676f: 00 > 814b6770: 89 ca mov%ecx,%edx > 814b6772: f7 d2 not%edx > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > 814b677b: 00 > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > 814b6782: 75 23 jne814b67a7 > > 814b6784: 48 89 c6mov%rax,%rsi > 814b6787: 48 89 dfmov%rbx,%rdi > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > <_raw_spin_unlock_irqrestore> > 814b678f: 44 89 e8mov%r13d,%eax > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > 814b67a5: c9 leaveq > 814b67a6: c3 retq > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > 814b67ae: 00 > 814b67af: 48 63 c9movslq %ecx,%rcx > 814b67b2: 41 b5 01mov$0x1,%r13b > 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) > 814b67b9: 41 8b 94 24 78 01 00mov0x178(%r12),%edx > 814b67c0: 00 > 814b67c1: 83 c2 01add$0x1,%edx > 814b67c4: 81 e2 ff 0f
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
Quoting Tycho Andersen (ty...@tycho.ws): > We have reports of the following crash: > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > #0 [88085c6db710] machine_kexec at 81046239 > #1 [88085c6db760] crash_kexec at 810fc248 > #2 [88085c6db830] oops_end at 81008ae7 > #3 [88085c6db860] no_context at 81050b8f > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > #6 [88085c6db910] __do_page_fault at 8105132e > #7 [88085c6db9b0] do_page_fault at 8105152c > #8 [88085c6db9c0] page_fault at 81a3f122 > [exception RIP: uart_put_char+149] > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > RAX: 0292 RBX: 827c5120 RCX: 0081 > RDX: RSI: 005f RDI: 827c5120 > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > R13: 0001 R14: 005f R15: 0fba > ORIG_RAX: CS: 0010 SS: 0018 > #9 [88085c6dbaa0] tty_put_char at 81497544 > #10 [88085c6dbac0] do_output_char at 8149c91c > #11 [88085c6dbae0] __process_echoes at 8149cb8b > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > #18 [88085c6dbd50] process_one_work at 81090be2 > #19 [88085c6dbe20] worker_thread at 81091b4d > #20 [88085c6dbeb0] kthread at 81096384 > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > after slogging through some dissasembly: > > 814b6720 : > 814b6720: 55 push %rbp > 814b6721: 48 89 e5mov%rsp,%rbp > 814b6724: 48 83 ec 20 sub$0x20,%rsp > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > 814b6747: 45 31 edxor%r13d,%r13d > 814b674a: 41 89 f6mov%esi,%r14d > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > 814b6754: 00 00 > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > 814b675d: 00 > 814b675e: 74 2f je 814b678f > > 814b6760: 48 89 dfmov%rbx,%rdi > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > <_raw_spin_lock_irqsave> > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > 814b676f: 00 > 814b6770: 89 ca mov%ecx,%edx > 814b6772: f7 d2 not%edx > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > 814b677b: 00 > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > 814b6782: 75 23 jne814b67a7 > > 814b6784: 48 89 c6mov%rax,%rsi > 814b6787: 48 89 dfmov%rbx,%rdi > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > <_raw_spin_unlock_irqrestore> > 814b678f: 44 89 e8mov%r13d,%eax > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > 814b67a5: c9 leaveq > 814b67a6: c3 retq > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > 814b67ae: 00 > 814b67af: 48 63 c9movslq %ecx,%rcx > 814b67b2: 41 b5 01mov$0x1,%r13b > 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) > 814b67b9: 41 8b 94 24 78 01 00mov0x178(%r12),%edx > 814b67c0: 00 > 814b67c1: 83 c2 01add$0x1,%edx > 814b67c4: 81 e2 ff 0f
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
Quoting Tycho Andersen (ty...@tycho.ws): > We have reports of the following crash: > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > #0 [88085c6db710] machine_kexec at 81046239 > #1 [88085c6db760] crash_kexec at 810fc248 > #2 [88085c6db830] oops_end at 81008ae7 > #3 [88085c6db860] no_context at 81050b8f > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > #6 [88085c6db910] __do_page_fault at 8105132e > #7 [88085c6db9b0] do_page_fault at 8105152c > #8 [88085c6db9c0] page_fault at 81a3f122 > [exception RIP: uart_put_char+149] > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > RAX: 0292 RBX: 827c5120 RCX: 0081 > RDX: RSI: 005f RDI: 827c5120 > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > R13: 0001 R14: 005f R15: 0fba > ORIG_RAX: CS: 0010 SS: 0018 > #9 [88085c6dbaa0] tty_put_char at 81497544 > #10 [88085c6dbac0] do_output_char at 8149c91c > #11 [88085c6dbae0] __process_echoes at 8149cb8b > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > #18 [88085c6dbd50] process_one_work at 81090be2 > #19 [88085c6dbe20] worker_thread at 81091b4d > #20 [88085c6dbeb0] kthread at 81096384 > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > after slogging through some dissasembly: > > 814b6720 : > 814b6720: 55 push %rbp > 814b6721: 48 89 e5mov%rsp,%rbp > 814b6724: 48 83 ec 20 sub$0x20,%rsp > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > 814b6747: 45 31 edxor%r13d,%r13d > 814b674a: 41 89 f6mov%esi,%r14d > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > 814b6754: 00 00 > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > 814b675d: 00 > 814b675e: 74 2f je 814b678f > > 814b6760: 48 89 dfmov%rbx,%rdi > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > <_raw_spin_lock_irqsave> > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > 814b676f: 00 > 814b6770: 89 ca mov%ecx,%edx > 814b6772: f7 d2 not%edx > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > 814b677b: 00 > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > 814b6782: 75 23 jne814b67a7 > > 814b6784: 48 89 c6mov%rax,%rsi > 814b6787: 48 89 dfmov%rbx,%rdi > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > <_raw_spin_unlock_irqrestore> > 814b678f: 44 89 e8mov%r13d,%eax > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > 814b67a5: c9 leaveq > 814b67a6: c3 retq > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > 814b67ae: 00 > 814b67af: 48 63 c9movslq %ecx,%rcx > 814b67b2: 41 b5 01mov$0x1,%r13b > 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) > 814b67b9: 41 8b 94 24 78 01 00mov0x178(%r12),%edx > 814b67c0: 00 > 814b67c1: 83 c2 01add$0x1,%edx > 814b67c4: 81 e2 ff 0f
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
Quoting Tycho Andersen (ty...@tycho.ws): > We have reports of the following crash: > > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" > #0 [88085c6db710] machine_kexec at 81046239 > #1 [88085c6db760] crash_kexec at 810fc248 > #2 [88085c6db830] oops_end at 81008ae7 > #3 [88085c6db860] no_context at 81050b8f > #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 > #5 [88085c6db900] bad_area_nosemaphore at 81050e83 > #6 [88085c6db910] __do_page_fault at 8105132e > #7 [88085c6db9b0] do_page_fault at 8105152c > #8 [88085c6db9c0] page_fault at 81a3f122 > [exception RIP: uart_put_char+149] > RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 > RAX: 0292 RBX: 827c5120 RCX: 0081 > RDX: RSI: 005f RDI: 827c5120 > RBP: 88085c6dba98 R8: 012c R9: 822ea320 > R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 > R13: 0001 R14: 005f R15: 0fba > ORIG_RAX: CS: 0010 SS: 0018 > #9 [88085c6dbaa0] tty_put_char at 81497544 > #10 [88085c6dbac0] do_output_char at 8149c91c > #11 [88085c6dbae0] __process_echoes at 8149cb8b > #12 [88085c6dbb30] commit_echoes at 8149cdc2 > #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b > #14 [88085c6dbbc0] __receive_buf at 8149ef5a > #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 > #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 > #17 [88085c6dbcb0] flush_to_ldisc at 814a238a > #18 [88085c6dbd50] process_one_work at 81090be2 > #19 [88085c6dbe20] worker_thread at 81091b4d > #20 [88085c6dbeb0] kthread at 81096384 > #21 [88085c6dbf50] ret_from_fork at 81a3d69f > > after slogging through some dissasembly: > > 814b6720 : > 814b6720: 55 push %rbp > 814b6721: 48 89 e5mov%rsp,%rbp > 814b6724: 48 83 ec 20 sub$0x20,%rsp > 814b6728: 48 89 1c 24 mov%rbx,(%rsp) > 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) > 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) > 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) > 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 > 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 > 814b6747: 45 31 edxor%r13d,%r13d > 814b674a: 41 89 f6mov%esi,%r14d > 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) > 814b6754: 00 00 > 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx > 814b675d: 00 > 814b675e: 74 2f je 814b678f > > 814b6760: 48 89 dfmov%rbx,%rdi > 814b6763: e8 a8 67 58 00 callq 81a3cf10 > <_raw_spin_lock_irqsave> > 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx > 814b676f: 00 > 814b6770: 89 ca mov%ecx,%edx > 814b6772: f7 d2 not%edx > 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx > 814b677b: 00 > 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx > 814b6782: 75 23 jne814b67a7 > > 814b6784: 48 89 c6mov%rax,%rsi > 814b6787: 48 89 dfmov%rbx,%rdi > 814b678a: e8 e1 64 58 00 callq 81a3cc70 > <_raw_spin_unlock_irqrestore> > 814b678f: 44 89 e8mov%r13d,%eax > 814b6792: 48 8b 1c 24 mov(%rsp),%rbx > 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 > 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 > 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 > 814b67a5: c9 leaveq > 814b67a6: c3 retq > 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx > 814b67ae: 00 > 814b67af: 48 63 c9movslq %ecx,%rcx > 814b67b2: 41 b5 01mov$0x1,%r13b > 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) > 814b67b9: 41 8b 94 24 78 01 00mov0x178(%r12),%edx > 814b67c0: 00 > 814b67c1: 83 c2 01add$0x1,%edx > 814b67c4: 81 e2 ff 0f
[PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
We have reports of the following crash: PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" #0 [88085c6db710] machine_kexec at 81046239 #1 [88085c6db760] crash_kexec at 810fc248 #2 [88085c6db830] oops_end at 81008ae7 #3 [88085c6db860] no_context at 81050b8f #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 #5 [88085c6db900] bad_area_nosemaphore at 81050e83 #6 [88085c6db910] __do_page_fault at 8105132e #7 [88085c6db9b0] do_page_fault at 8105152c #8 [88085c6db9c0] page_fault at 81a3f122 [exception RIP: uart_put_char+149] RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 RAX: 0292 RBX: 827c5120 RCX: 0081 RDX: RSI: 005f RDI: 827c5120 RBP: 88085c6dba98 R8: 012c R9: 822ea320 R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 R13: 0001 R14: 005f R15: 0fba ORIG_RAX: CS: 0010 SS: 0018 #9 [88085c6dbaa0] tty_put_char at 81497544 #10 [88085c6dbac0] do_output_char at 8149c91c #11 [88085c6dbae0] __process_echoes at 8149cb8b #12 [88085c6dbb30] commit_echoes at 8149cdc2 #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b #14 [88085c6dbbc0] __receive_buf at 8149ef5a #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 #17 [88085c6dbcb0] flush_to_ldisc at 814a238a #18 [88085c6dbd50] process_one_work at 81090be2 #19 [88085c6dbe20] worker_thread at 81091b4d #20 [88085c6dbeb0] kthread at 81096384 #21 [88085c6dbf50] ret_from_fork at 81a3d69f after slogging through some dissasembly: 814b6720 : 814b6720: 55 push %rbp 814b6721: 48 89 e5mov%rsp,%rbp 814b6724: 48 83 ec 20 sub$0x20,%rsp 814b6728: 48 89 1c 24 mov%rbx,(%rsp) 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 814b6747: 45 31 edxor%r13d,%r13d 814b674a: 41 89 f6mov%esi,%r14d 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) 814b6754: 00 00 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx 814b675d: 00 814b675e: 74 2f je 814b678f 814b6760: 48 89 dfmov%rbx,%rdi 814b6763: e8 a8 67 58 00 callq 81a3cf10 <_raw_spin_lock_irqsave> 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx 814b676f: 00 814b6770: 89 ca mov%ecx,%edx 814b6772: f7 d2 not%edx 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx 814b677b: 00 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx 814b6782: 75 23 jne814b67a7 814b6784: 48 89 c6mov%rax,%rsi 814b6787: 48 89 dfmov%rbx,%rdi 814b678a: e8 e1 64 58 00 callq 81a3cc70 <_raw_spin_unlock_irqrestore> 814b678f: 44 89 e8mov%r13d,%eax 814b6792: 48 8b 1c 24 mov(%rsp),%rbx 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 814b67a5: c9 leaveq 814b67a6: c3 retq 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx 814b67ae: 00 814b67af: 48 63 c9movslq %ecx,%rcx 814b67b2: 41 b5 01mov$0x1,%r13b 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) 814b67b9: 41 8b 94 24 78 01 00mov0x178(%r12),%edx 814b67c0: 00 814b67c1: 83 c2 01add$0x1,%edx 814b67c4: 81 e2 ff 0f 00 00 and$0xfff,%edx 814b67ca: 41 89 94 24 78 01 00mov%edx,0x178(%r12) 814b67d1:
[PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
We have reports of the following crash: PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" #0 [88085c6db710] machine_kexec at 81046239 #1 [88085c6db760] crash_kexec at 810fc248 #2 [88085c6db830] oops_end at 81008ae7 #3 [88085c6db860] no_context at 81050b8f #4 [88085c6db8b0] __bad_area_nosemaphore at 81050d75 #5 [88085c6db900] bad_area_nosemaphore at 81050e83 #6 [88085c6db910] __do_page_fault at 8105132e #7 [88085c6db9b0] do_page_fault at 8105152c #8 [88085c6db9c0] page_fault at 81a3f122 [exception RIP: uart_put_char+149] RIP: 814b67b5 RSP: 88085c6dba78 RFLAGS: 00010006 RAX: 0292 RBX: 827c5120 RCX: 0081 RDX: RSI: 005f RDI: 827c5120 RBP: 88085c6dba98 R8: 012c R9: 822ea320 R10: 88085fe4db04 R11: 0001 R12: 881059f9c000 R13: 0001 R14: 005f R15: 0fba ORIG_RAX: CS: 0010 SS: 0018 #9 [88085c6dbaa0] tty_put_char at 81497544 #10 [88085c6dbac0] do_output_char at 8149c91c #11 [88085c6dbae0] __process_echoes at 8149cb8b #12 [88085c6dbb30] commit_echoes at 8149cdc2 #13 [88085c6dbb60] n_tty_receive_buf_fast at 8149e49b #14 [88085c6dbbc0] __receive_buf at 8149ef5a #15 [88085c6dbc20] n_tty_receive_buf_common at 8149f016 #16 [88085c6dbca0] n_tty_receive_buf2 at 8149f194 #17 [88085c6dbcb0] flush_to_ldisc at 814a238a #18 [88085c6dbd50] process_one_work at 81090be2 #19 [88085c6dbe20] worker_thread at 81091b4d #20 [88085c6dbeb0] kthread at 81096384 #21 [88085c6dbf50] ret_from_fork at 81a3d69f after slogging through some dissasembly: 814b6720 : 814b6720: 55 push %rbp 814b6721: 48 89 e5mov%rsp,%rbp 814b6724: 48 83 ec 20 sub$0x20,%rsp 814b6728: 48 89 1c 24 mov%rbx,(%rsp) 814b672c: 4c 89 64 24 08 mov%r12,0x8(%rsp) 814b6731: 4c 89 6c 24 10 mov%r13,0x10(%rsp) 814b6736: 4c 89 74 24 18 mov%r14,0x18(%rsp) 814b673b: e8 b0 8e 58 00 callq 81a3f5f0 814b6740: 4c 8b a7 88 02 00 00mov0x288(%rdi),%r12 814b6747: 45 31 edxor%r13d,%r13d 814b674a: 41 89 f6mov%esi,%r14d 814b674d: 49 83 bc 24 70 01 00cmpq $0x0,0x170(%r12) 814b6754: 00 00 814b6756: 49 8b 9c 24 80 01 00mov0x180(%r12),%rbx 814b675d: 00 814b675e: 74 2f je 814b678f 814b6760: 48 89 dfmov%rbx,%rdi 814b6763: e8 a8 67 58 00 callq 81a3cf10 <_raw_spin_lock_irqsave> 814b6768: 41 8b 8c 24 78 01 00mov0x178(%r12),%ecx 814b676f: 00 814b6770: 89 ca mov%ecx,%edx 814b6772: f7 d2 not%edx 814b6774: 41 03 94 24 7c 01 00add0x17c(%r12),%edx 814b677b: 00 814b677c: 81 e2 ff 0f 00 00 and$0xfff,%edx 814b6782: 75 23 jne814b67a7 814b6784: 48 89 c6mov%rax,%rsi 814b6787: 48 89 dfmov%rbx,%rdi 814b678a: e8 e1 64 58 00 callq 81a3cc70 <_raw_spin_unlock_irqrestore> 814b678f: 44 89 e8mov%r13d,%eax 814b6792: 48 8b 1c 24 mov(%rsp),%rbx 814b6796: 4c 8b 64 24 08 mov0x8(%rsp),%r12 814b679b: 4c 8b 6c 24 10 mov0x10(%rsp),%r13 814b67a0: 4c 8b 74 24 18 mov0x18(%rsp),%r14 814b67a5: c9 leaveq 814b67a6: c3 retq 814b67a7: 49 8b 94 24 70 01 00mov0x170(%r12),%rdx 814b67ae: 00 814b67af: 48 63 c9movslq %ecx,%rcx 814b67b2: 41 b5 01mov$0x1,%r13b 814b67b5: 44 88 34 0a mov%r14b,(%rdx,%rcx,1) 814b67b9: 41 8b 94 24 78 01 00mov0x178(%r12),%edx 814b67c0: 00 814b67c1: 83 c2 01add$0x1,%edx 814b67c4: 81 e2 ff 0f 00 00 and$0xfff,%edx 814b67ca: 41 89 94 24 78 01 00mov%edx,0x178(%r12) 814b67d1:
