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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Feb 2010 10:51:38 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jens Axboe <jens.axboe@...cle.com>
cc:	linux-pm <linux-pm@...ts.linux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Testing for dirty buffers on a block device

On Tue, 23 Feb 2010, Jens Axboe wrote:

> > That's not what I meant.  Dirty buffers on a filesystem make no 
> > difference because they always get written out when the filesystem is 
> > unmounted.  The device file remains open as long as the filesystem 
> > is mounted, which would prevent the device from being powered down.
> > 
> > I was asking about dirty buffers on a block device that isn't holding a 
> > filesystem -- where the raw device is being used directly for I/O.
> 
> OK, so just specifically the page cache of the device. Is that really
> enough of an issue to warrant special checking? I mean, what normal
> setup would even use buffer raw device access?

Doesn't fdisk use it?  There might be other applications too.

> But if you wanted, I guess the only way would be to lookup
> dirty/writeback pages on the bdev inode mapping. For that you'd need the
> bdev, not the gendisk or the queue though.

I can get the bdev from the gendisk by calling bdget_disk() with a 
partition number of 0, right?  What would the next step be?  Would this 
check for dirty pages associated with any of the partitions or would it 
only look at pages associated with the inode for the entire disk?

Alan Stern

--
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