Re: Linux 2.4.33-rc1

[Grant Coady <gcoady.lk@gmail.com>]

On Wed, 21 Jun 2006 00:23:57 +0200, Willy Tarreau <w@1wt.eu> wrote:

>On Mon, Jun 19, 2006 at 08:45:06PM -0300, Marcelo Tosatti wrote:
>> > 
>> > ---- from here ----
>> > 
>> > 
>> > > +		inode = dentry->d_inode;
>> > > +		if (inode)
>> > > +			atomic_inc(&inode->i_count);
>> > >  		error = vfs_unlink(nd.dentry->d_inode, dentry);
>> > >  	exit2:
>> > >  		dput(dentry);
>> > >  	}
>> > >  	up(&nd.dentry->d_inode->i_sem);
>> > > +	if (inode)
>> > > +		iput(inode);
>> > 
>> > ---- to here ----
>> > 
>> > I believe that nd.dentry->d_inode cannot vanish because it is protected by the
>> > down(->i_sem) before and the up(->i_sem) after. Am I right or am I missing
>> > something important ?
>> 
>> Indeed it can't, but dentry->d_inode will be set to NULL by
>> nfs_unlink->nfs_safe_remove->d_delete. Thus the problem.
>
>What puzzles me is how are we supposed to up(&nd.dentry->d_inode->i_sem) if
>dentry->d_inode can become NULL ? simply by keeping a copy of it ? I thought
>that the down() protected the whole thing, but may be that's stupid anyway.
>I've been running rc1 without this patch for a few hours and during kernel
>compiles without a problem, so I'm not sure about what to think about the
>other changes which were apparently harmless too :-/

So what's the final fixup?  Last two patches don't seem to cause the 
problems previously reported by me.  They don't play together though, 
so I'll add my general sense of confusion to this issue ;)  

Should I run the thing (which patch?) and compile a hundred kernels 
or something to see what (if anything) breaks.  Shortest day of year 
here, I don't mind running the test box as part of room heating :o)

Thanks,
Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/