From: Petr Mladek <pmladek@suse.com>
To: Qian Cai <cai@lca.pw>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
sergey.senozhatsky.work@gmail.com, rostedt@goodmis.org,
peterz@infradead.org, Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org, john.ogness@linutronix.de,
akpm@linux-foundation.org, Vasily Gorbik <gor@linux.ibm.com>,
PeterOberparleiter <oberpar@linux.ibm.com>,
david@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk()
Date: Thu, 10 Oct 2019 09:57:56 +0200 [thread overview]
Message-ID: <20191010075756.nyix7l32ai6fylzn@pathway.suse.cz> (raw)
In-Reply-To: <1570632374.5937.8.camel@lca.pw>
On Wed 2019-10-09 10:46:14, Qian Cai wrote:
> On Wed, 2019-10-09 at 16:24 +0200, Petr Mladek wrote:
> > On Wed 2019-10-09 09:43:13, Qian Cai wrote:
> > > On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > > > On Wed 09-10-19 09:06:42, Qian Cai wrote:
> > > > [...]
> > > > > https://lore.kernel.org/linux-mm/1570460350.5576.290.camel@lca.pw/
> > > > >
> > > > > [ 297.425964] -> #1 (&port_lock_key){-.-.}:
> > > > > [ 297.425967] __lock_acquire+0x5b3/0xb40
> > > > > [ 297.425967] lock_acquire+0x126/0x280
> > > > > [ 297.425968] _raw_spin_lock_irqsave+0x3a/0x50
> > > > > [ 297.425969] serial8250_console_write+0x3e4/0x450
> > > > > [ 297.425970] univ8250_console_write+0x4b/0x60
> > > > > [ 297.425970] console_unlock+0x501/0x750
> > > > > [ 297.425971] vprintk_emit+0x10d/0x340
> > > > > [ 297.425972] vprintk_default+0x1f/0x30
> > > > > [ 297.425972] vprintk_func+0x44/0xd4
> > > > > [ 297.425973] printk+0x9f/0xc5
> > > > > [ 297.425974] register_console+0x39c/0x520
> > > > > [ 297.425975] univ8250_console_init+0x23/0x2d
> > > > > [ 297.425975] console_init+0x338/0x4cd
> > > > > [ 297.425976] start_kernel+0x534/0x724
> > > > > [ 297.425977] x86_64_start_reservations+0x24/0x26
> > > > > [ 297.425977] x86_64_start_kernel+0xf4/0xfb
> > > > > [ 297.425978] secondary_startup_64+0xb6/0xc0
> > > > >
> > > > > where the report again show the early boot call trace for the locking
> > > > > dependency,
> > > > >
> > > > > console_owner --> port_lock_key
> > > > >
> > > > > but that dependency clearly not only happen in the early boot.
> > > >
> > > > Can you provide an example of the runtime dependency without any early
> > > > boot artifacts? Because this discussion really doens't make much sense
> > > > without a clear example of a _real_ lockdep report that is not a false
> > > > possitive. All of them so far have been concluded to be false possitive
> > > > AFAIU.
> > >
> > > An obvious one is in the above link. Just replace the trace in #1 above with
> > > printk() from anywhere, i.e., just ignore the early boot calls there as they are
> > > not important.
> > >
> > > printk()
> > > console_unlock()
> > > console_lock_spinning_enable() --> console_owner_lock
> > > call_console_drivers()
> > > serial8250_console_write() --> port->lock
> >
> > Please, find the location where this really happens and then suggests
> > how the real deadlock could get fixed. So far, we have seen only
> > false positives and theoretical scenarios.
>
> Now the bar is higher again. You are now asking me to actually trigger this
> potential deadlock live. I am probably better off buying some lottery tickets
> then if I could be that lucky.
No, we just do not want to comlicate the code too much just to hide
false positives from lockdep.
I do not ask you to reproduce the deadlock. I ask you to find
a code path where the deadlock might really happen. It seems
that you actually found one in the tty code in the other mail.
Best Regards,
Petr
next prev parent reply other threads:[~2019-10-10 7:58 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 22:26 [PATCH v2] mm/page_isolation: fix a deadlock with printk() Qian Cai
2019-10-07 8:07 ` Michal Hocko
2019-10-07 9:05 ` Petr Mladek
2019-10-07 11:33 ` Michal Hocko
2019-10-07 12:34 ` Qian Cai
2019-10-07 11:04 ` Qian Cai
2019-10-07 11:37 ` Michal Hocko
2019-10-07 12:11 ` Qian Cai
2019-10-07 12:43 ` Michal Hocko
2019-10-07 13:07 ` Qian Cai
2019-10-07 14:10 ` Petr Mladek
2019-10-07 14:30 ` Petr Mladek
2019-10-07 14:49 ` Michal Hocko
2019-10-08 7:43 ` Petr Mladek
2019-10-08 8:27 ` Michal Hocko
2019-10-08 12:56 ` Christian Borntraeger
2019-10-08 16:08 ` Qian Cai
2019-10-08 18:35 ` Michal Hocko
2019-10-08 19:06 ` Qian Cai
2019-10-08 19:17 ` Michal Hocko
2019-10-08 19:35 ` Qian Cai
2019-10-09 11:49 ` Petr Mladek
2019-10-09 13:06 ` Qian Cai
2019-10-09 13:27 ` Michal Hocko
2019-10-09 13:43 ` Qian Cai
2019-10-09 13:51 ` Michal Hocko
2019-10-09 14:19 ` Qian Cai
2019-10-09 14:34 ` Michal Hocko
2019-10-09 15:08 ` Qian Cai
2019-10-09 16:23 ` Michal Hocko
2019-10-09 16:23 ` Michal Hocko
2019-10-10 9:01 ` Qian Cai
2019-10-10 10:59 ` Michal Hocko
2019-10-10 13:11 ` Qian Cai
2019-10-10 14:18 ` Michal Hocko
2019-10-10 14:47 ` Qian Cai
2019-10-10 17:30 ` Michal Hocko
2019-10-10 17:48 ` Qian Cai
2019-10-10 18:06 ` Michal Hocko
2019-10-10 18:59 ` David Hildenbrand
2019-10-09 14:24 ` Petr Mladek
2019-10-09 14:46 ` Qian Cai
2019-10-10 7:57 ` Petr Mladek [this message]
2019-10-09 11:39 ` Petr Mladek
2019-10-09 13:56 ` Peter Oberparleiter
2019-10-09 14:26 ` Michal Hocko
2019-10-10 5:12 ` Sergey Senozhatsky
2019-10-10 7:40 ` Michal Hocko
2019-10-10 8:16 ` Sergey Senozhatsky
2019-10-10 8:37 ` Michal Hocko
2019-10-10 8:21 ` Petr Mladek
2019-10-10 8:39 ` Sergey Senozhatsky
2019-10-10 11:11 ` Petr Mladek
2019-10-09 15:25 ` Qian Cai
2019-10-09 15:25 ` Qian Cai
2019-10-07 14:59 ` Qian Cai
2019-10-07 15:12 ` Michal Hocko
2019-10-07 15:33 ` Qian Cai
2019-10-08 8:15 ` Petr Mladek
2019-10-08 9:32 ` Qian Cai
2019-10-08 13:13 ` Steven Rostedt
2019-10-08 13:23 ` Qian Cai
2019-10-08 13:33 ` Steven Rostedt
2019-10-08 13:42 ` Petr Mladek
2019-10-08 13:48 ` Michal Hocko
2019-10-08 14:03 ` Qian Cai
2019-10-08 14:08 ` Michal Hocko
2019-10-08 8:40 ` Michal Hocko
2019-10-08 10:04 ` Qian Cai
2019-10-08 10:39 ` Michal Hocko
2019-10-08 12:00 ` Qian Cai
2019-10-08 12:39 ` Michal Hocko
2019-10-08 13:06 ` Qian Cai
2019-10-08 13:37 ` Michal Hocko
2019-10-08 13:08 ` Petr Mladek
2019-10-08 13:33 ` Qian Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191010075756.nyix7l32ai6fylzn@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=cai@lca.pw \
--cc=david@redhat.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).