Hi,
On Tue, 2007-01-09 at 23:52 +0300, Sergey Vlasov wrote:
[snip excellent analysis]
> Seems that grabbing i_mutex in ntfs_put_inode() is not safe after all
> (and lockdep cannot see this deadlock possibility, because one of
> waits is __wait_on_freeing_inode - not a standard locking primitive).
Hi,
On Tue, 2007-01-09 at 23:52 +0300, Sergey Vlasov wrote:
[snip excellent analysis]
Seems that grabbing i_mutex in ntfs_put_inode() is not safe after all
(and lockdep cannot see this deadlock possibility, because one of
waits is __wait_on_freeing_inode - not a standard locking primitive).
Sergey Vlasov wrote:
Yep.
Hello!
I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).
The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:
kswapd0
Hello!
I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).
The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:
kswapd0 D 810005dea304 0
Hello!
I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).
The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:
kswapd0 D 810005dea304 0
Sergey Vlasov wrote:
Yep.
Hello!
I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).
The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:
kswapd0
6 matches
Mail list logo
