[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52AB8E27.90308@nigelcunningham.com.au>
Date: Sat, 14 Dec 2013 09:45:59 +1100
From: Nigel Cunningham <nigel@...elcunningham.com.au>
To: Tejun Heo <tj@...nel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Jens Axboe <axboe@...nel.dk>
CC: tomaz.solc@...lix.org, aaron.lu@...el.com,
linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [PATCH] libata, freezer: avoid block device removal while system
is frozen
Hi Tejun.
Thanks for your work on this.
In your first email, in the first substantial paragraph (starting "Now,
if the rest.."), you say "libata device removal waits for the scheduled
writeback work item to finish". I wonder if that's the lynchpin. If we
know the device is gone, why are we trying to write to it?
All pending I/O should have been flushed when suspend/hibernate started,
and there's no point in trying to update metadata on a device we can't
access, so there should be no writeback needed (and anything that does
somehow get there should just be discarded since it will never succeed
anyway).
Or am I missing something?
Having said the above, I agree that we shouldn't need to freeze kernel
threads and workqueues themselves. I think we should be giving the
producers of I/O the nous needed to avoid producing I/O during
suspend/hibernate. But perhaps I'm missing something here, too.
Regards,
Nigel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists