linux-kernel - Re: [PATCH 0/4 v3] fs: Remove i

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:	Tue, 04 Nov 2014 11:47:21 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Al Viro <viro@...IV.linux.org.uk>, Jan Kara <jack@...e.cz>
CC:	Christoph Hellwig <hch@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/4 v3] fs: Remove i_devices from struct inode

On 11/04/2014 07:39 AM, Al Viro wrote:
> On Tue, Nov 04, 2014 at 11:27:27AM +0100, Jan Kara wrote:
>>   Hello,
>>
>>   this patch set removes use of i_devices from block and character device
>> code and thus we can remove the list head from struct inode thus saving two
>> pointers in it. As Christoph has reviewed the series, can you please merge
>> it Al? Thanks!
>>
>> Since v2 I've added reviewed-by tags from Christoph and changed one variable
>> name in cdev_forget().
>>
>> Since v1 I have split the patches and properly handled character devices (I
>> broke them last time as Christoph pointed out).
> 
> My problem with that is in buggered module refcounts (which was the reason
> for doing those non-counting references back then).  Suppose you open
> /dev/some_char_device and close it; having the module pinned down until
> the inode of that sucker gets evicted by dcache/icache memory pressure
> would be wrong - it _isn't_ in use, and there's no way short of forcing
> the full eviction of VFS caches to get it possible to unload...
> 

At the risk of asking what may be a rather dumb question...

Why do device node inodes need to be cached at all?  In other words,
when you try open a device node, can't the kernel materialize the inode
from just information that's in the dentry without touching the
filesystem at all?  If that's true, couldn't all device inodes be
dropped from icache as soon as they're unreferenced?

(Yes, there's mtime, but I never understood why tracking mtime on device
nodes made any sense in the first place.)

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