[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121030205142.GB2616@ZenIV.linux.org.uk>
Date: Tue, 30 Oct 2012 20:51:42 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Jeff Moyer <jmoyer@...hat.com>
Cc: linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>,
Chris Mason <chris.mason@...ionio.com>,
Steve French <sfrench@...ba.org>,
Mark Fasheh <mfasheh@...e.com>,
Joel Becker <jlbec@...lplan.org>,
Matthew Wilcox <matthew@....cx>, linux-afs@...ts.infradead.org,
linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
ocfs2-devel@....oracle.com
Subject: Re: [patch 05/10] vfs: pass data to alloc_inode super operation
On Tue, Oct 30, 2012 at 04:14:39PM -0400, Jeff Moyer wrote:
> This patch passes a data pointer along to the alloc_inode
> super_operations function. The value will initially be used by
> bdev_alloc_inode to allocate the bdev_inode on the same numa
> node as the device to which it is tied.
Yecchhh...
> -static struct inode *bdev_alloc_inode(struct super_block *sb)
> +static struct inode *bdev_alloc_inode(struct super_block *sb, void *data)
> {
> - struct bdev_inode *ei = kmem_cache_alloc(bdev_cachep, GFP_KERNEL);
> + struct bdev_inode *ei;
> + int partno;
> + int node;
> +
> + if (data) {
> + struct gendisk *disk;
> + dev_t dev = *(dev_t *)data;
> + disk = get_gendisk(dev, &partno);
> + node = disk->node_id;
> + put_disk(disk);
Oh, _lovely_. Such a stunningly elegant idea. And why not pass the
sodding node_id directly, if I may ask?
[reads further]
[finds completely undocumented reason for that]
Take that crap out and don't bring it back. And consider this kludge NAKed
once and forever. It's unspeakably ugly, even if it didn't break just about
every fs out there (you do realize that almost all of them have ->alloc_inode(),
don't you? Use grep and see).
--
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