Re: Locking problem in 2.2.18/19-pre7? (fs/inode.c and fs/dcache.c)

2001-01-16 Thread Andrea Arcangeli
On Tue, Jan 16, 2001 at 12:10:31PM -0800, Theodore Y. Ts'o wrote: > Actually, looking at the fast path of down_trylock compared to huge mess > of code that's currently there, I actually suspect that using > down_trylock() would actually be faster, since in the fast path case > there would only two

Re: Locking problem in 2.2.18/19-pre7? (fs/inode.c and fs/dcache.c)

2001-01-16 Thread tytso
Date: Tue, 16 Jan 2001 20:33:34 +0100 From: Andrea Arcangeli <[EMAIL PROTECTED]> > Of course, this is utterly unsafe on an SMP machines, since access to > the "block" variable isn't protected at all. So the first question is Wrong, it's obviously protected by the inode_lock. And

Re: Locking problem in 2.2.18/19-pre7? (fs/inode.c and fs/dcache.c)

2001-01-16 Thread Andrea Arcangeli
On Tue, Jan 16, 2001 at 11:04:45AM -0800, Theodore Y. Ts'o wrote: > > HJ Lu recently pointed me at a potential locking problem > try_to_free_inodes(), and when I started proding at it, I found what > appears to be another set of SMP locking issues in the dcache code. > (But if that were the case,

Locking problem in 2.2.18/19-pre7? (fs/inode.c and fs/dcache.c)

2001-01-16 Thread tytso
HJ Lu recently pointed me at a potential locking problem try_to_free_inodes(), and when I started proding at it, I found what appears to be another set of SMP locking issues in the dcache code. (But if that were the case, why aren't we seeing huge numbers of complaints? So I'm wondering if I'm m