From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [patch 3/7] fs, notify: Add file handle entry into inotify_inode_mark Date: Wed, 14 Nov 2012 14:13:41 +0400 Message-ID: <50A36ED5.4080505@parallels.com> References: <20121112101440.665694060@openvz.org> <19056257.kzSp6roqV4@deuteros> <20121114095812.GF16685@moon> <2105540.yeyMVrW4mH@deuteros> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cyrill Gorcunov , David Rientjes , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Al Viro , Alexey Dobriyan , James Bottomley , Matthew Helsley , aneesh.kumar@linux.vnet.ibm.com, bfields@fieldses.org To: Tvrtko Ursulin Return-path: In-Reply-To: <2105540.yeyMVrW4mH@deuteros> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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 > > . >