linux-kernel - Re: [PATCH 1/3] bdi: Use parent filesystem BDI for inodes not capable of writeback

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]

Message-ID: <20100729081210.GA395@infradead.org>
Date:	Thu, 29 Jul 2010 04:12:10 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Jan Kara <jack@...e.cz>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/3] bdi: Use parent filesystem BDI for inodes not
 capable of writeback

Given that we only need the per-mapping one for the bdev fs what about
doing:

/*
 * Return the writeback-relevant backing device for this inode.
 *
 * For a normal filesystem this must always be the bdi hanging off the
 * superblock, given that we only expect one bdi per filesystems in
 * the per-superblock sync functions.  But the block device special
 * filesystem requires a quick given that it contains the internal
 * I/O inodes for block devices on a single superblock.  This works
 * because the block deevice filesystem inodes are never user visible
 * and we will never do a per-superblock sync on it.
 */
static struct backing_dev_info *inode_to_bdi(struct inode *inode)
{
	if (inode->i_sb == blockdev_superblock)
		return inode->i_mapping->backing_dev_info;
	return inode->i_sb->s_bdi;
}

that also avoids the need for doing the bdi capabilities audit ASAP.
--
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/