lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ