From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Tejun Heo <tj@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
AceLan Kao <acelan.kao@canonical.com>,
Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: System hangs if NVMe/SSD is removed during suspend
Date: Fri, 04 Oct 2019 11:59:26 +0200 [thread overview]
Message-ID: <2367934.HCQFgJ56tP@kreacher> (raw)
In-Reply-To: <20191004080340.GB2819@lahna.fi.intel.com>
On Friday, October 4, 2019 10:03:40 AM CEST Mika Westerberg wrote:
> On Thu, Oct 03, 2019 at 09:50:33AM -0700, Tejun Heo wrote:
> > Hello, Mika.
> >
> > On Wed, Oct 02, 2019 at 03:21:36PM +0300, Mika Westerberg wrote:
> > > but from that discussion I don't see more generic solution to be
> > > implemented.
> > >
> > > Any ideas we should fix this properly?
> >
> > Yeah, the only fix I can think of is not using freezable wq. It's
> > just not a good idea and not all that difficult to avoid using.
>
> OK, thanks.
>
> In that case I will just make a patch that removes WQ_FREEZABLE from
> bdi_wq and see what people think about it :)
I guess that depends on why WQ_FREEZABLE was added to it in the first place. :-)
The reason might be to avoid writes to persistent storage after creating an
image during hibernation, since wqs remain frozen throughout the entire
hibernation including the image saving phase.
Arguably, making the wq freezable is kind of a sledgehammer approach to that
particular issue, but in principle it may prevent data corruption from
occurring, so be careful there.
next prev parent reply other threads:[~2019-10-04 9:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-02 12:21 System hangs if NVMe/SSD is removed during suspend Mika Westerberg
2019-10-03 16:50 ` Tejun Heo
2019-10-04 8:03 ` Mika Westerberg
2019-10-04 9:59 ` Rafael J. Wysocki [this message]
2019-10-04 11:01 ` Mika Westerberg
2019-10-04 13:32 ` Jens Axboe
2019-10-07 10:08 ` Jan Kara
2019-10-09 13:22 ` Rafael J. Wysocki
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=2367934.HCQFgJ56tP@kreacher \
--to=rjw@rjwysocki.net \
--cc=acelan.kao@canonical.com \
--cc=axboe@kernel.dk \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=tj@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.