linux-kernel - Re: [patch 3/7] fs, notify: Add file handle entry into inotify_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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Nov 2012 14:13:41 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Tvrtko Ursulin <tvrtko.ursulin@...lan.co.uk>
CC:	Cyrill Gorcunov <gorcunov@...nvz.org>,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Al Viro <viro@...iv.linux.org.uk>,
	Alexey Dobriyan <adobriyan@...il.com>,
	James Bottomley <jbottomley@...allels.com>,
	Matthew Helsley <matt.helsley@...il.com>,
	aneesh.kumar@...ux.vnet.ibm.com, bfields@...ldses.org
Subject: Re: [patch 3/7] fs, notify: Add file handle entry into inotify_inode_mark

On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
> On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
>> On Wed, Nov 14, 2012 at 09:50:55AM +0000, Tvrtko Ursulin wrote:
>>>>> You could not use a pointer and then allocate your buffers on the
>>>>> check
>>>>> point operation, freeing on restore?
>>>>
>>>> The problem is not allocating the memory itself but rather the time when
>>>> the information needed (ie the dentry) is available. The only moment
>>>> when we can use dentry of the target file/directory is at
>>>> inotify_new_watch, that's why i need to compose fhandle that early. At
>>>> any later point we simply have no dentry to use.
>>>
>>> But you do not fundamentally need the dentry to restore a watch, right?
>>
>> dentry only needed to encode the file handle.
>>
>>> Couldn't you restore, creating a new restore path if needed, using the
>>> inode which is pinned anyway while the watch exists?
>>
>> plain inode is not enough as far as i can tell, iow i don't see the way
>> to restore path from inode solely. or there something i miss?
> 
> I don't know, as I said I was not following this at all until now. Just 
> throwing in ideas.
> 
> I thought, since inotify does not use the path or dentry outside the system 
> call at all, perhaps you need a different entry point allowing you to restore 
> the watch using the inode or something. Assuming life time of objects and 
> stuff in C&R world would allow you that. Since you don't need the full path, 
> just something 64 bytes long, I assumed that could be the case.

Well, the kernel already has all the API we need but one -- it shows us _nothing_
about the inode being watched. And we'd appreciate any information about it. Even
the ino:dev pair would work. We propose to show the handle because we believe, that
such API is better that ino:dev. You can get the handle, call the open_by_handle_at
right at once and get much much more information about the inode with any other
API (e.g. calling fstat() will give you the ino:dev pair). Having just ino:dev
pair at hands is not that flexible.

> Regards,
> 
> Tvrtko
> 
> .
> 


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