All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
To: Sinan Kaya <okaya@kernel.org>,
	linux-pci@vger.kernel.org, kexec@lists.infradead.org,
	x86@kernel.org
Cc: linux-kernel@vger.kernel.org, bhelgaas@google.com,
	dyoung@redhat.com, bhe@redhat.com, vgoyal@redhat.com,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	hpa@zytor.com, andi@firstfloor.org, lukas@wunner.de,
	billy.olsen@canonical.com, cascardo@canonical.com,
	ddstreet@canonical.com, fabiomirmar@canonical.com,
	gavin.guo@canonical.com, jay.vosburgh@canonical.com,
	kernel@gpiccoli.net, mfo@canonical.com,
	shan.gavin@linux.alibaba.com
Subject: Re: [PATCH 3/3] x86/quirks: Add parameter to clear MSIs early on boot
Date: Mon, 22 Oct 2018 16:44:04 -0300	[thread overview]
Message-ID: <92dc24c9-0963-e894-66fe-ad74bdbc0ac3@canonical.com> (raw)
In-Reply-To: <50d84d48-eebf-ed91-8148-be727f76883f@kernel.org>

On 18/10/2018 17:30, Sinan Kaya wrote:
> 
> AFAIK, all shutdown (not remove) routines are called before launching
> the next
> kernel even in crash scenario. It is not safe to start the new kernel while
> hardware is doing a DMA to the system memory and triggering interrupts.

Hi Sinan,

I agree with you, it's definitely not safe to start a new kernel with
in-flight DMA transactions, but in the crash scenario I think the
rationale was that running kernel is broken so it's even more unreliable
to try gracefully shutdown the devices than hope-for-the-best and start
the kdump kernel right away heheh

Fact is that the shutdown handlers are not called in the crash scenario.
They come from device_shutdown(), the code paths are as follow:

Regular kexec flow:

syscall_reboot()
  kernel_kexec()
    kernel_restart_prepare()
	  device_shutdown()
	machine_kexec()
	
Although if CONFIG_KEXEC_JUMP is set, it doesn't call device_shutdown()
either.


Crash kexec flow:
  __crash_kexec()
      machine_kexec()

There are some entry points to __crash_kexec(), like panic() or die() in
x86, for example.
To validate this, one can load a kernel with "initcall_debug" parameter,
and performs a kexec - if the shutdown handlers are called, there's a
dev_info() call that shows a message per device.


> Shutdown routine in PCI core used to disable MSI/MSI-x on behalf of all
> endpoints but it was later decided that this is the responsibility of the
> endpoint driver.
> 

This may be a good idea, using the pci layer to disable MSIs in the
quiesce path of the broken kernel. I'll follow-up this discussion in
Bjorn's reply.

Thanks,


Guilherme

WARNING: multiple messages have this Message-ID (diff)
From: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
To: Sinan Kaya <okaya@kernel.org>,
	linux-pci@vger.kernel.org, kexec@lists.infradead.org,
	x86@kernel.org
Cc: cascardo@canonical.com, andi@firstfloor.org, bhe@redhat.com,
	lukas@wunner.de, shan.gavin@linux.alibaba.com,
	kernel@gpiccoli.net, linux-kernel@vger.kernel.org,
	gavin.guo@canonical.com, ddstreet@canonical.com,
	mingo@redhat.com, bp@alien8.de, billy.olsen@canonical.com,
	mfo@canonical.com, hpa@zytor.com, bhelgaas@google.com,
	jay.vosburgh@canonical.com, tglx@linutronix.de,
	dyoung@redhat.com, fabiomirmar@canonical.com, vgoyal@redhat.com
Subject: Re: [PATCH 3/3] x86/quirks: Add parameter to clear MSIs early on boot
Date: Mon, 22 Oct 2018 16:44:04 -0300	[thread overview]
Message-ID: <92dc24c9-0963-e894-66fe-ad74bdbc0ac3@canonical.com> (raw)
In-Reply-To: <50d84d48-eebf-ed91-8148-be727f76883f@kernel.org>

On 18/10/2018 17:30, Sinan Kaya wrote:
> 
> AFAIK, all shutdown (not remove) routines are called before launching
> the next
> kernel even in crash scenario. It is not safe to start the new kernel while
> hardware is doing a DMA to the system memory and triggering interrupts.

Hi Sinan,

I agree with you, it's definitely not safe to start a new kernel with
in-flight DMA transactions, but in the crash scenario I think the
rationale was that running kernel is broken so it's even more unreliable
to try gracefully shutdown the devices than hope-for-the-best and start
the kdump kernel right away heheh

Fact is that the shutdown handlers are not called in the crash scenario.
They come from device_shutdown(), the code paths are as follow:

Regular kexec flow:

syscall_reboot()
  kernel_kexec()
    kernel_restart_prepare()
	  device_shutdown()
	machine_kexec()
	
Although if CONFIG_KEXEC_JUMP is set, it doesn't call device_shutdown()
either.


Crash kexec flow:
  __crash_kexec()
      machine_kexec()

There are some entry points to __crash_kexec(), like panic() or die() in
x86, for example.
To validate this, one can load a kernel with "initcall_debug" parameter,
and performs a kexec - if the shutdown handlers are called, there's a
dev_info() call that shows a message per device.


> Shutdown routine in PCI core used to disable MSI/MSI-x on behalf of all
> endpoints but it was later decided that this is the responsibility of the
> endpoint driver.
> 

This may be a good idea, using the pci layer to disable MSIs in the
quiesce path of the broken kernel. I'll follow-up this discussion in
Bjorn's reply.

Thanks,


Guilherme

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2018-10-22 19:44 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 18:37 [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks Guilherme G. Piccoli
2018-10-18 18:37 ` Guilherme G. Piccoli
2018-10-18 18:37 ` [PATCH 2/3] x86/PCI: Export find_cap() to be used in early PCI code Guilherme G. Piccoli
2018-10-18 18:37   ` Guilherme G. Piccoli
2018-10-18 18:37 ` [PATCH 3/3] x86/quirks: Add parameter to clear MSIs early on boot Guilherme G. Piccoli
2018-10-18 18:37   ` Guilherme G. Piccoli
2018-10-18 20:08   ` Sinan Kaya
2018-10-18 20:08     ` Sinan Kaya
2018-10-18 20:13     ` Guilherme G. Piccoli
2018-10-18 20:13       ` Guilherme G. Piccoli
2018-10-18 20:30       ` Sinan Kaya
2018-10-18 20:30         ` Sinan Kaya
2018-10-22 19:44         ` Guilherme G. Piccoli [this message]
2018-10-22 19:44           ` Guilherme G. Piccoli
2018-10-18 22:15 ` [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks Bjorn Helgaas
2018-10-18 22:15   ` Bjorn Helgaas
2018-10-22 20:35   ` Guilherme G. Piccoli
2018-10-22 20:35     ` Guilherme G. Piccoli
2018-10-23 17:03     ` Bjorn Helgaas
2018-10-23 17:03       ` Bjorn Helgaas
2020-11-06 13:14       ` Guilherme G. Piccoli
2020-11-06 13:14         ` Guilherme G. Piccoli
2020-11-13 16:46         ` Bjorn Helgaas
2020-11-13 16:46           ` Bjorn Helgaas
2020-11-13 23:31           ` Thomas Gleixner
2020-11-13 23:31             ` Thomas Gleixner
2020-11-13 23:40             ` Thomas Gleixner
2020-11-13 23:40               ` Thomas Gleixner
2020-11-14 20:39               ` Bjorn Helgaas
2020-11-14 20:39                 ` Bjorn Helgaas
2020-11-14 20:58                 ` Thomas Gleixner
2020-11-14 20:58                   ` Thomas Gleixner
2020-11-14 21:22                   ` Bjorn Helgaas
2020-11-14 21:22                     ` Bjorn Helgaas
2020-11-15 14:05                     ` Eric W. Biederman
2020-11-15 14:05                       ` Eric W. Biederman
2020-11-15 14:29                       ` Eric W. Biederman
2020-11-15 14:29                         ` Eric W. Biederman
2020-11-15 15:11                         ` Thomas Gleixner
2020-11-15 15:11                           ` Thomas Gleixner
2020-11-15 17:01                           ` Lukas Wunner
2020-11-15 19:18                             ` Thomas Gleixner
2020-11-15 19:18                               ` Thomas Gleixner
2020-11-15 20:46                           ` Eric W. Biederman
2020-11-15 20:46                             ` Eric W. Biederman
2020-11-16 20:31                             ` Guilherme G. Piccoli
2020-11-16 20:31                               ` Guilherme G. Piccoli
2020-11-16 21:45                               ` Eric W. Biederman
2020-11-16 21:45                                 ` Eric W. Biederman
2020-11-16 21:49                                 ` Guilherme Piccoli
2020-11-16 21:49                                   ` Guilherme Piccoli
2020-11-17  0:19                               ` Bjorn Helgaas
2020-11-17  0:19                                 ` Bjorn Helgaas
2020-11-17  1:06                                 ` Eric W. Biederman
2020-11-17  1:06                                   ` Eric W. Biederman
2020-11-17  9:53                                   ` Thomas Gleixner
2020-11-17  9:53                                     ` Thomas Gleixner
2020-11-17 12:19                                     ` David Woodhouse
2020-11-17 12:19                                       ` David Woodhouse
2020-11-17 19:34                                       ` Thomas Gleixner
2020-11-17 19:34                                         ` Thomas Gleixner
2020-11-17 22:25                                         ` Eric W. Biederman
2020-11-17 22:25                                           ` Eric W. Biederman
2020-11-17 12:04                                   ` Guilherme Piccoli
2020-11-17 12:04                                     ` Guilherme Piccoli
2020-11-18 21:05                                     ` Bjorn Helgaas
2020-11-18 21:05                                       ` Bjorn Helgaas
2020-11-18 22:36                                       ` Guilherme Piccoli
2020-11-18 22:36                                         ` Guilherme Piccoli
2020-11-30 20:20                                         ` Bjorn Helgaas
2020-11-30 20:20                                           ` Bjorn Helgaas
2020-12-14 18:32                                           ` Guilherme Piccoli
2020-12-14 18:32                                             ` Guilherme Piccoli

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=92dc24c9-0963-e894-66fe-ad74bdbc0ac3@canonical.com \
    --to=gpiccoli@canonical.com \
    --cc=andi@firstfloor.org \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=billy.olsen@canonical.com \
    --cc=bp@alien8.de \
    --cc=cascardo@canonical.com \
    --cc=ddstreet@canonical.com \
    --cc=dyoung@redhat.com \
    --cc=fabiomirmar@canonical.com \
    --cc=gavin.guo@canonical.com \
    --cc=hpa@zytor.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=kernel@gpiccoli.net \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mfo@canonical.com \
    --cc=mingo@redhat.com \
    --cc=okaya@kernel.org \
    --cc=shan.gavin@linux.alibaba.com \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.