Re: Linux 2.4.33-rc1

Grant Coady
2006-06-19T05:04:08Z

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

On Mon, 19 Jun 2006 06:01:52 +0200, Willy Tarreau <w@1wt.eu> wrote:

>On Mon, Jun 19, 2006 at 09:07:03AM +1000, Grant Coady wrote:
>> On Mon, 19 Jun 2006 00:37:36 +0200, Willy Tarreau <w@1wt.eu> wrote:
>>
>> >Hi Grant,
>> >
>> >On Mon, Jun 19, 2006 at 08:25:06AM +1000, Grant Coady wrote:
>> >> On Sun, 18 Jun 2006 10:37:18 -0300, Marcelo Tosatti <marcelo@kvack.org> wrote:
>> >>
>> >> >Can you please try the attached patch.
>> >> >
>> >> >Grab a reference to the victim inode before calling vfs_unlink() to avoid
>> >> >it vanishing under us.
>> >> >
>> >> >diff --git a/fs/namei.c b/fs/namei.c
>> >> >index 42cce98..7993283 100644
>> >> >--- a/fs/namei.c
>> >> >+++ b/fs/namei.c
>> >> >@@ -1509,6 +1509,7 @@ asmlinkage long sys_unlink(const char *
>> >> > char * name;
>> >> > struct dentry *dentry;
>> >> > struct nameidata nd;
>> >> >+ struct inode *inode = NULL;
>> >> >
>> >> > name = getname(pathname);
>> >> > if(IS_ERR(name))
>> >> >@@ -1527,11 +1528,16 @@ asmlinkage long sys_unlink(const char *
>> >> > /* Why not before? Because we want correct error value */
>> >> > if (nd.last.name[nd.last.len])
>> >> > goto slashes;
>> >> >+ inode = dentry->d_inode;
>> >> >+ if (inode)
>> >> >+ atomic_inc(&inode->i_count);
>> >> > error = vfs_unlink(nd.dentry->d_inode, dentry);
>> >> > exit2:
>> >> > dput(dentry);
>> >> > }
>> >
>> >Could you add this line here, because your oops still looks like the NULL
>> >is close to this area :
>> >
>> >+ printk(KERN_DEBUG "nd.dentry->d_inode = %p\n", nd.dentry->d_inode);
>>
>> It didn't get there for the segfault case, gets there for local file
>> delete
>>
>> After:
>> grant@sempro:~$ dmesg >dmesg
>> grant@sempro:~$ rm dmesg
>>
>> Jun 19 08:49:17 sempro kernel: nd.dentry->d_inode = f73f4b80
>>
>> After:
>> grant@sempro:~$ dmesg >/home/share/dmesg-test
>> grant@sempro:~$ rm /home/share/dmesg-test
>> Segmentation fault
>>
>> Nothing reported by debug or syslog, oops in messages.
>
>Thanks. Then, could you send us your 'namei.o' file please ? Mine does
>not produce the same content as yours and it makes it difficult to find
>the exact position in the code.

gzipped, attached.

Cheers,
Grant.

[-- Attachment #2: fs-namei.o.gz --]
[-- Type: application/octet-stream, Size: 9529 bytes --]