All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Christian Brauner <brauner@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Bill O'Donnell <billodo@redhat.com>,
	Rob Barnes <robbarnes@google.com>,
	bleung@chromium.org, linux-fsdevel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs: export emergency_sync
Date: Wed, 19 Jul 2023 13:51:25 -0700	[thread overview]
Message-ID: <ZLhMzQWUS0htHEdb@google.com> (raw)
In-Reply-To: <ZLeDVcQrFft8FYle@infradead.org>

On Tue, Jul 18, 2023 at 11:31:49PM -0700, Christoph Hellwig wrote:
> On Wed, Jul 19, 2023 at 07:53:32AM +0200, Christian Brauner wrote:
> > On vacation until next. Please add a proper rationale why and who this
> > export is needed by in the commit message. As right now it looks like
> > someone thought it would be good to have which is not enough for
> > something to become an export.
> 
> emergency_sync is a relaly bad idea and has all kinds of issues.
> It should go away and not grow more users outside of core code,
> and the one Guenther points to should never have been added.
> 
> If we want to allow emergency shutdowns it needs a proper interface
> and not a remount read-only ignoring some rules that tends to make
> things worse and instad of better, and even for that I'm not sure
> I want modules to be able to drive it.

I am not sure why you would not want modules to use it - in the case we
have here we detect a catastrophic failure in a critical system
component (embedded controller crashed) and would like to have as much
of the logs saved as possible. It is a module because this kind of EC
may not be present on every system, but when it is present it is very
much a core component.

Thanks.

-- 
Dmitry

  reply	other threads:[~2023-07-19 20:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 21:45 [PATCH] fs: export emergency_sync Rob Barnes
2023-07-18 22:13 ` Bill O'Donnell
2023-07-18 22:18   ` Rob Barnes
2023-07-19  4:08   ` Guenter Roeck
2023-07-19  5:53     ` Christian Brauner
2023-07-19  6:31       ` Christoph Hellwig
2023-07-19 20:51         ` Dmitry Torokhov [this message]
2023-07-31  7:23           ` Christoph Hellwig
2023-07-19 13:21       ` Guenter Roeck
2023-07-31 19:18         ` Christian Brauner

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=ZLhMzQWUS0htHEdb@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=billodo@redhat.com \
    --cc=bleung@chromium.org \
    --cc=brauner@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robbarnes@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.