linux-kernel - Re: [PATCH v1 03/19] fs/anon_inodes: new interface to create new inode

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:	Fri, 11 Mar 2016 15:24:36 +0100
From:	Gioh Kim <gi-oh.kim@...fitbricks.com>
To:	Al Viro <viro@...IV.linux.org.uk>, Minchan Kim <minchan@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, jlayton@...chiereds.net,
	bfields@...ldses.org, Vlastimil Babka <vbabka@...e.cz>,
	Joonsoo Kim <iamjoonsoo.kim@....com>, koct9i@...il.com,
	aquini@...hat.com, virtualization@...ts.linux-foundation.org,
	Mel Gorman <mgorman@...e.de>, Hugh Dickins <hughd@...gle.com>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	rknize@...orola.com, Rik van Riel <riel@...hat.com>,
	Gioh Kim <gurugio@...mail.net>
Subject: Re: [PATCH v1 03/19] fs/anon_inodes: new interface to create new
 inode



On 11.03.2016 09:05, Al Viro wrote:
> On Fri, Mar 11, 2016 at 04:30:07PM +0900, Minchan Kim wrote:
>> From: Gioh Kim <gurugio@...mail.net>
>>
>> The anon_inodes has already complete interfaces to create manage
>> many anonymous inodes but don't have interface to get
>> new inode. Other sub-modules can create anonymous inode
>> without creating and mounting it's own pseudo filesystem.
> IMO that's a bad idea.  In case of aio "creating and mounting" takes this:
> static struct dentry *aio_mount(struct file_system_type *fs_type,
>                                  int flags, const char *dev_name, void *data)
> {
>          static const struct dentry_operations ops = {
>                  .d_dname        = simple_dname,
>          };
>          return mount_pseudo(fs_type, "aio:", NULL, &ops, AIO_RING_MAGIC);
> }
> and
>          static struct file_system_type aio_fs = {
>                  .name           = "aio",
>                  .mount          = aio_mount,
>                  .kill_sb        = kill_anon_super,
>          };
>          aio_mnt = kern_mount(&aio_fs);
>
> All of 12 lines.  Your export is not much shorter.  To quote old mail on
> the same topic:
I know what aio_setup() does. It can be a solution.
But I thought creating anon_inode_new() is simpler than several drivers 
create its own pseudo filesystem.
Creating a filesystem requires memory allocation and locking some lists 
even though it is pseudo.

Could you inform me if there is a reason we should avoid creating 
anonymous inode?

>
>> Note that anon_inodes.c reason to exist was "it's for situations where
>> all context lives on struct file and we don't need separate inode for
>> them".  Going from that to "it happens to contain a handy function for inode
>> allocation"...


-- 
Best regards,
Gioh Kim