Messages in this thread Patch in this message | | | Date | Mon, 9 Jan 2012 10:11:29 -0500 | From | Ted Ts'o <> | Subject | Re: [git pull] vfs pile 1 |
| |
On Sun, Jan 08, 2012 at 11:50:40PM +0000, Al Viro wrote: > > WTF is ext4_symlink() doing in case of long symlinks? Look: > drop_nlink(inode); > err = ext4_orphan_add(handle, inode); > ext4_journal_stop(handle); > [write symlink body] > inc_nlink(inode); > err = ext4_orphan_del(handle, inode); > oh, I see... The comment above that re deadlocks and inability to do that > in a single transaction ;-/ > > OK, try this; that's equivalent to what they are doing and will not WARN_ON(); > I hadn't checked other filesystems for similar tricks yet, so this has a good > chance of being incomplete. > > diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c > index 86edc45..2043f48 100644 > --- a/fs/ext4/namei.c > +++ b/fs/ext4/namei.c > @@ -2315,7 +2315,7 @@ retry: > err = PTR_ERR(handle); > goto err_drop_inode; > } > - inc_nlink(inode); > + set_nlink(inode, 1); > err = ext4_orphan_del(handle, inode); > if (err) { > ext4_journal_stop(handle);
Thanks, looks good to me.
Acked-by: "Theodore Ts'o" <tytso@mit.edu>
What's there is a bit of kludge, granted. But an attempt to optimize out placing the inode on and off the orphan list (either by deferring the start of the ext3/4 journal handle, or by special casing the block used for the long symlink) would add a lot of complexity, and creating long symlinks is not common case in most workloads...
- Ted
| |