All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bryn M. Reeves <breeves@redhat.com>
To: lvm-devel@redhat.com
Subject: Need clarification
Date: Thu, 11 Nov 2021 16:22:13 +0000	[thread overview]
Message-ID: <YY1DNXFh+mmuHOCh@redhat.com> (raw)
In-Reply-To: <70b1de35-76e2-391d-9d8c-3752fb948f41@redhat.com>

On Thu, Nov 11, 2021 at 01:23:03PM +0100, Zdenek Kabelac wrote:
> Dne 10. 11. 21 v 14:11 Lakshmi Narasimhan Sundararajan napsal(a):
> > Hi LVM Team!
> > A very good day to you.
> > 
> > I have the following observation, and I need your inputs to understand behavior.
> > 
> > 1/ create a volume group on a single block device.
> > 2/ create a logical volume on the volume group.
> > 3/ pump IO to the dm device
> > 4/ while IOs are active, force kernel crash through the sysrq interface.
> > 
> > This results in a kernel hang. possibly because of IOs waiting to be
> > serviced still.
> > This behavior is seen over thin pool, thin device as well.
> > 
> > 1/ Is this behavior known or understood well as to why the kernel does
> > not complete a shutdown?
> > 2/ Is there any configuration with the lvm/dm layer that can allow the
> > kernel to proceed to complete shutdown and reboot failing those
> > incomplete IOs?
> > 
> > Please advise.
> 
> I'm pretty sure     'echo b > /proc/sysrq-trigger'  will reboot your kernel.

It sounds like they are using the 'c' sysrq command; this invokes a
crash (used to be just dereferencing a NULL pointer) and is commonly
used to test configurations like kdump, or automatic reboot on panic.

>From what the reporter is saying it sounds like that is not happening in
the described scenario although presumably it has been configured?

After the 'c' it's not possible to issue further sysrq commands via the
/proc interface, so the 'b' would have to be invoked via sysrq keyboard
commands.

> Other then that I'm not much sure I'm getting your point here.
> 
> You crash your kernel and then you are wondering why it's hang ??

If you have kdump enabled, or /proc/sys/kernel/panic is set to a value
that is > 0 then this is definitely not expected behaviour.

In this case it's often useful to enable keyboard sysrq (since those can
be issued following the 'echo c > /proc/sysrq-trigger'), and to carry
out a thread dump (sysrq-t) to print all stacks to the console. To be
useful this generally needs a serial console or some other mechanism to
capture the large volume of messages for analysis.

Regards,
Bryn.



  reply	other threads:[~2021-11-11 16:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 13:11 Need clarification Lakshmi Narasimhan Sundararajan
2021-11-11 12:23 ` Zdenek Kabelac
2021-11-11 16:22   ` Bryn M. Reeves [this message]
2021-11-12  8:16     ` Lakshmi Narasimhan Sundararajan

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=YY1DNXFh+mmuHOCh@redhat.com \
    --to=breeves@redhat.com \
    --cc=lvm-devel@redhat.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 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.