Re: fishy -put_inode usage in ntfs
On Tue, 2005-03-01 at 23:17 +, David Woodhouse wrote: On Mon, 2005-02-14 at 20:44 +, Anton Altaparmakov wrote: So every time we get a concurrent clear_inode() and iget() for the same inode what happens? We get your Failed to get bitmap attribute. every time? Or can clear_inode only be called once the inode is removed from icache? I thought we declared that the concurrent clear_inode() and read_inode() were a VFS bug, and fixed it? It's even fixed in 2.4 now isn't it? Is it? I must have missed this discussion. )-: Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fishy -put_inode usage in ntfs
On Wed, 2005-03-02 at 08:43 +, Anton Altaparmakov wrote: I thought we declared that the concurrent clear_inode() and read_inode() were a VFS bug, and fixed it? It's even fixed in 2.4 now isn't it? Is it? I must have missed this discussion. )-: Wasn't that why we backported __wait_on_freeing_inode() to 2.4? -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fishy -put_inode usage in ntfs
On Thu, Oct 14, 2004 at 02:26:45PM +0100, Anton Altaparmakov wrote: I don't like filesystem doings things like this in -put_inode at all, and indeed the plan is to get rid of -put_inode completely. Why do you need to hold an additional reference anyway? What's so special about the relation of these two inodes? The bmp_ino is a virtual inode. It doesn't exist on disk as an inode. It is an NTFS attribute of the base inode. It cannot exist without the base inode there. You could neither read from nor write to this inode without its base inode being there and you couldn't even clear_inode() this inode without the base inode being there. The reference is essential I am afraid. If -put_inode is removed then I will have to switch to using ntfs_attr_iget() each time or I will have to attach the inode in some other much hackier way that doesn't use the i_count and uses my ntfs private counter instead. Coming back to this issue. Why do you need to refcount bmp_ino at all? Can someone ever grab a reference separate from it's master inode? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fishy -put_inode usage in ntfs
On Thu, Feb 10, 2005 at 02:48:26PM +, Anton Altaparmakov wrote: If the igrab() were not done, it would be possible for clear_inode to be called on the 'parent' inode whilst at the same time one or more attr inodes (belonging to this 'parent') are in use and Bad Things(TM) would happen... What bad thing specificly? If there's shared information we should probably refcount them separately. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fishy -put_inode usage in ntfs
On Thu, 2005-02-10 at 14:48 +, Anton Altaparmakov wrote: On Thu, 2005-02-10 at 15:42 +0100, Christoph Hellwig wrote: On Thu, Feb 10, 2005 at 02:40:39PM +, Anton Altaparmakov wrote: I am not sure what you mean. The VFS layer does reference counting on inodes. I have no choice in the matter. Can someone ever grab a reference separate from it's master inode? Again, not sure what you mean. Could you elaborate? ntfs_read_locked_attr_inode() does igrab on the 'parent' inode currently. What do you need this for exactly - the attr inode goes away anyway when clear_inode is called on that 'parent' inode (in my scheme). If the igrab() were not done, it would be possible for clear_inode to be called on the 'parent' inode whilst at the same time one or more attr inodes (belonging to this 'parent') are in use and Bad Things(TM) would happen... The igrab() effectively guarantees that iput() is called on all attr inodes before clear_inode on the 'parent' can be invoked. Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fishy -put_inode usage in ntfs
On Thu, Feb 10, 2005 at 02:50:02PM +, Anton Altaparmakov wrote: If the igrab() were not done, it would be possible for clear_inode to be called on the 'parent' inode whilst at the same time one or more attr inodes (belonging to this 'parent') are in use and Bad Things(TM) would happen... The igrab() effectively guarantees that iput() is called on all attr inodes before clear_inode on the 'parent' can be invoked. Yes, but why exactly is this important. It looks like you're absuing the refcount on the 'parent' inode for some shared data? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fishy -put_inode usage in ntfs
On Thu, 2005-02-10 at 15:50 +0100, Christoph Hellwig wrote: On Thu, Feb 10, 2005 at 02:48:26PM +, Anton Altaparmakov wrote: If the igrab() were not done, it would be possible for clear_inode to be called on the 'parent' inode whilst at the same time one or more attr inodes (belonging to this 'parent') are in use and Bad Things(TM) would happen... What bad thing specificly? If there's shared information we should probably refcount them separately. Each attr inode stores a pointer to its parent inode in NTFS_I(struct inode *vi)-ext.base_ntfs_ino. This pointer would point to random memory if clear_inode is called on the parent whilst the attr inode is still in use. Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
