Linux virtualization list
 help / color / mirror / Atom feed
From: Petr Mladek via Virtualization <virtualization@lists.linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Itay Aveksis <itayav@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>,
	John Ogness <john.ogness@linutronix.de>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Amit Shah <amit@kernel.org>,
	virtualization@lists.linux-foundation.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Ran Rozenstein <ranro@nvidia.com>
Subject: Re: netconsole deadlock with virtnet
Date: Thu, 19 Nov 2020 13:55:53 +0100	[thread overview]
Message-ID: <X7ZrWZ0UJoh+vQXm@alley> (raw)
In-Reply-To: <20201117093325.78f1486d@gandalf.local.home>

On Tue 2020-11-17 09:33:25, Steven Rostedt wrote:
> On Tue, 17 Nov 2020 12:23:41 +0200
> Leon Romanovsky <leon@kernel.org> wrote:
> 
> > Hi,
> > 
> > Approximately two weeks ago, our regression team started to experience those
> > netconsole splats. The tested code is Linus's master (-rc4) + netdev net-next
> > + netdev net-rc.
> > 
> > Such splats are random and we can't bisect because there is no stable reproducer.
> > 
> > Any idea, what is the root cause?
> > 
> > [   21.149739]                       __do_sys_finit_module+0xbc/0x12c
> > [   21.149740]                       __arm64_sys_finit_module+0x28/0x34
> > [   21.149741]                       el0_svc_common.constprop.0+0x84/0x200
> > [   21.149742]                       do_el0_svc+0x2c/0x90
> > [   21.149743]                       el0_svc+0x18/0x50
> > [   21.149744]                       el0_sync_handler+0xe0/0x350
> > [   21.149745]                       el0_sync+0x158/0x180
> > [   21.149746]  }
> > [   21.149747]  ... key      at: [<ffff8000093d4018>] target_list_lock+0x18/0xfffffffffffff000 [netconsole]
> > [   21.149748]  ..
> > [   21.149750] Lost 190 message(s)!
> 
> It really sucks that we lose 190 messages that would help to decipher this
> more. :-p

The message commes from the printk_safe code. The size can be
increased by CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT.

> Because I'm not sure where the xmit_lock is taken while holding the
> target_list_lock. But the above does show that printk() calls write_msg()
> while holding the console_lock, and write_msg() takes the target_list_lock.
> 
> Thus, the fix would ether require disabling interrupts every time the
> xmit_lock is taken, or to get it from being taken while holding the
> target_list_lock.

It seems that the missing messages might help to find the root of
the problem.

Best Regards,
Petr
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2020-11-19 12:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 10:23 netconsole deadlock with virtnet Leon Romanovsky
2020-11-17 14:33 ` Steven Rostedt
2020-11-17 18:12   ` Leon Romanovsky
2020-11-18  2:46   ` Sergey Senozhatsky
2020-11-18  3:15     ` Sergey Senozhatsky
2020-11-18  4:09       ` Jason Wang
2020-11-18 14:12         ` Steven Rostedt
2020-11-23 11:08           ` Leon Romanovsky
2020-11-23 14:31             ` Steven Rostedt
     [not found]               ` <20201123105252.1c295138@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
2020-11-23 19:09                 ` Steven Rostedt
     [not found]                   ` <20201123112130.759b9487@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
2020-11-24  3:22                     ` Jason Wang
2020-11-24  8:01                       ` Leon Romanovsky
2020-11-24  8:57                         ` Jason Wang
2020-11-24  9:26                           ` Leon Romanovsky
2020-11-24 14:31                       ` Steven Rostedt
2020-11-25  6:20                         ` Jason Wang
     [not found]                       ` <20201124082035.3e658fa4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
2020-11-25  6:21                         ` Jason Wang
2020-11-19 12:55   ` Petr Mladek via Virtualization [this message]
2020-11-22  8:41     ` Leon Romanovsky

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=X7ZrWZ0UJoh+vQXm@alley \
    --to=virtualization@lists.linux-foundation.org \
    --cc=amit@kernel.org \
    --cc=itayav@nvidia.com \
    --cc=john.ogness@linutronix.de \
    --cc=leon@kernel.org \
    --cc=mst@redhat.com \
    --cc=pmladek@suse.com \
    --cc=ranro@nvidia.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@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