From: Sergey Senozhatsky on
Code with munmap produces:

[ 54.152356]
[ 54.152358] =======================================================
[ 54.152363] [ INFO: possible circular locking dependency detected ]
[ 54.152367] 2.6.35-rc3-dbg-git6-00502-g94feaba-dirty #65
[ 54.152371] -------------------------------------------------------
[ 54.152374] a.out/4044 is trying to acquire lock:
[ 54.152378] (&sb->s_type->i_mutex_key#10){+.+.+.}, at: [<c10f1d4e>] reiserfs_file_release+0x11d/0x344
[ 54.152394]
[ 54.152395] but task is already holding lock:
[ 54.152398] (&mm->mmap_sem){++++++}, at: [<c1091b7f>] sys_munmap+0x26/0x42
[ 54.152408]
[ 54.152409] which lock already depends on the new lock.
[ 54.152410]
[ 54.152413]
[ 54.152414] the existing dependency chain (in reverse order) is:
[ 54.152417]
[ 54.152418] -> #1 (&mm->mmap_sem){++++++}:
[ 54.152425] [<c104f566>] lock_acquire+0x59/0x70
[ 54.152433] [<c108cf70>] might_fault+0x53/0x70
[ 54.152439] [<c1185418>] copy_to_user+0x30/0x48
[ 54.152445] [<c10afaf9>] filldir64+0x95/0xc9
[ 54.152451] [<c10f255c>] reiserfs_readdir_dentry+0x35d/0x4d9
[ 54.152457] [<c10f26ea>] reiserfs_readdir+0x12/0x17
[ 54.152463] [<c10afd17>] vfs_readdir+0x6d/0x92
[ 54.152468] [<c10afe91>] sys_getdents64+0x63/0xa2
[ 54.152473] [<c10027d3>] sysenter_do_call+0x12/0x32
[ 54.152480]
[ 54.152481] -> #0 (&sb->s_type->i_mutex_key#10){+.+.+.}:
[ 54.152488] [<c104ef5c>] __lock_acquire+0x96d/0xbe1
[ 54.152494] [<c104f566>] lock_acquire+0x59/0x70
[ 54.152500] [<c12c5674>] __mutex_lock_common+0x39/0x36b
[ 54.152507] [<c12c59e0>] mutex_lock_nested+0x12/0x15
[ 54.152512] [<c10f1d4e>] reiserfs_file_release+0x11d/0x344
[ 54.152518] [<c10a5805>] fput+0xe0/0x16a
[ 54.152524] [<c1090c9e>] remove_vma+0x28/0x47
[ 54.152529] [<c1091a60>] do_munmap+0x1e8/0x200
[ 54.152535] [<c1091b8b>] sys_munmap+0x32/0x42
[ 54.152540] [<c10027d3>] sysenter_do_call+0x12/0x32
[ 54.152546]
[ 54.152546] other info that might help us debug this:
[ 54.152548]
[ 54.152552] 1 lock held by a.out/4044:
[ 54.152554] #0: (&mm->mmap_sem){++++++}, at: [<c1091b7f>] sys_munmap+0x26/0x42
[ 54.152563]
[ 54.152564] stack backtrace:
[ 54.152569] Pid: 4044, comm: a.out Not tainted 2.6.35-rc3-dbg-git6-00502-g94feaba-dirty #65
[ 54.152572] Call Trace:
[ 54.152577] [<c12c48f3>] ? printk+0xf/0x11
[ 54.152583] [<c104dc09>] print_circular_bug+0x8a/0x96
[ 54.152589] [<c104ef5c>] __lock_acquire+0x96d/0xbe1
[ 54.152595] [<c104e462>] ? mark_lock+0x26/0x1b3
[ 54.152601] [<c104f566>] lock_acquire+0x59/0x70
[ 54.152607] [<c10f1d4e>] ? reiserfs_file_release+0x11d/0x344
[ 54.152612] [<c12c5674>] __mutex_lock_common+0x39/0x36b
[ 54.152618] [<c10f1d4e>] ? reiserfs_file_release+0x11d/0x344
[ 54.152624] [<c12c59e0>] mutex_lock_nested+0x12/0x15
[ 54.152629] [<c10f1d4e>] ? reiserfs_file_release+0x11d/0x344
[ 54.152634] [<c10f1d4e>] reiserfs_file_release+0x11d/0x344
[ 54.152640] [<c108d77d>] ? free_pgd_range+0x96/0x12f
[ 54.152646] [<c10a57b5>] ? fput+0x90/0x16a
[ 54.152651] [<c10a5805>] fput+0xe0/0x16a
[ 54.152656] [<c1090c9e>] remove_vma+0x28/0x47
[ 54.152661] [<c1091811>] ? arch_unmap_area_topdown+0x0/0x18
[ 54.152666] [<c1091a60>] do_munmap+0x1e8/0x200
[ 54.152672] [<c1091b8b>] sys_munmap+0x32/0x42
[ 54.152677] [<c10027d3>] sysenter_do_call+0x12/0x32



Sergey
From: Frederic Weisbecker on
On Fri, Jul 02, 2010 at 12:34:51PM +0300, Sergey Senozhatsky wrote:
> Hello,
>
> I searched lkml and found the following report (titled reiserfs locking):
> http://lkml.org/lkml/2010/4/15/389 (Fri, 16 Apr 2010)
>
> I can see this backtrace while configuring emacs:
>
> [ 6136.579013]
> [ 6136.579015] =======================================================
> [ 6136.579021] [ INFO: possible circular locking dependency detected ]
> [ 6136.579025] 2.6.35-rc3-dbg-git3-00350-g94d119f #61
> [ 6136.579027] -------------------------------------------------------
> [ 6136.579031] conftest/13950 is trying to acquire lock:
> [ 6136.579034] (&sb->s_type->i_mutex_key#10){+.+.+.}, at: [<c10f1cf6>] reiserfs_file_release+0x11d/0x344
> [ 6136.579050]
> [ 6136.579051] but task is already holding lock:
> [ 6136.579054] (&mm->mmap_sem){++++++}, at: [<c1091b87>] sys_munmap+0x26/0x42
> [ 6136.579064]
> [ 6136.579065] which lock already depends on the new lock.
> [ 6136.579066]
> [ 6136.579069]
> [ 6136.579070] the existing dependency chain (in reverse order) is:
> [ 6136.579073]
> [ 6136.579074] -> #1 (&mm->mmap_sem){++++++}:
> [ 6136.579081] [<c104f53a>] lock_acquire+0x59/0x70
> [ 6136.579089] [<c108cf78>] might_fault+0x53/0x70
> [ 6136.579094] [<c11853b8>] copy_to_user+0x30/0x48
> [ 6136.579101] [<c10afaf9>] filldir64+0x95/0xc9
> [ 6136.579106] [<c10f2504>] reiserfs_readdir_dentry+0x35d/0x4d9
> [ 6136.579112] [<c10f2692>] reiserfs_readdir+0x12/0x17
> [ 6136.579117] [<c10afd17>] vfs_readdir+0x6d/0x92
> [ 6136.579122] [<c10afe91>] sys_getdents64+0x63/0xa2
> [ 6136.579127] [<c10027d3>] sysenter_do_call+0x12/0x32
> [ 6136.579134]
> [ 6136.579135] -> #0 (&sb->s_type->i_mutex_key#10){+.+.+.}:
> [ 6136.579142] [<c104ef30>] __lock_acquire+0x96d/0xbe1
> [ 6136.579148] [<c104f53a>] lock_acquire+0x59/0x70
> [ 6136.579153] [<c12c5614>] __mutex_lock_common+0x39/0x36b
> [ 6136.579160] [<c12c5980>] mutex_lock_nested+0x12/0x15
> [ 6136.579165] [<c10f1cf6>] reiserfs_file_release+0x11d/0x344
> [ 6136.579171] [<c10a580d>] fput+0xe0/0x16a
> [ 6136.579177] [<c1090ca6>] remove_vma+0x28/0x47
> [ 6136.579182] [<c1091a68>] do_munmap+0x1e8/0x200
> [ 6136.579188] [<c1091b93>] sys_munmap+0x32/0x42
> [ 6136.579193] [<c10027d3>] sysenter_do_call+0x12/0x32
> [ 6136.579198]
> [ 6136.579199] other info that might help us debug this:
> [ 6136.579200]
> [ 6136.579204] 1 lock held by conftest/13950:
> [ 6136.579207] #0: (&mm->mmap_sem){++++++}, at: [<c1091b87>] sys_munmap+0x26/0x42
> [ 6136.579216]
> [ 6136.579217] stack backtrace:
> [ 6136.579221] Pid: 13950, comm: conftest Not tainted 2.6.35-rc3-dbg-git3-00350-g94d119f #61
> [ 6136.579225] Call Trace:
> [ 6136.579230] [<c12c4893>] ? printk+0xf/0x11
> [ 6136.579235] [<c104dbdd>] print_circular_bug+0x8a/0x96
> [ 6136.579241] [<c104ef30>] __lock_acquire+0x96d/0xbe1
> [ 6136.579247] [<c104e436>] ? mark_lock+0x26/0x1b3
> [ 6136.579254] [<c104f53a>] lock_acquire+0x59/0x70
> [ 6136.579259] [<c10f1cf6>] ? reiserfs_file_release+0x11d/0x344
> [ 6136.579265] [<c12c5614>] __mutex_lock_common+0x39/0x36b
> [ 6136.579270] [<c10f1cf6>] ? reiserfs_file_release+0x11d/0x344
> [ 6136.579276] [<c1084375>] ? release_pages+0x55/0x116
> [ 6136.579282] [<c12c5980>] mutex_lock_nested+0x12/0x15
> [ 6136.579287] [<c10f1cf6>] ? reiserfs_file_release+0x11d/0x344
> [ 6136.579293] [<c10f1cf6>] reiserfs_file_release+0x11d/0x344
> [ 6136.579299] [<c10a57bd>] ? fput+0x90/0x16a
> [ 6136.579304] [<c10a580d>] fput+0xe0/0x16a
> [ 6136.579309] [<c1090ca6>] remove_vma+0x28/0x47
> [ 6136.579314] [<c1091819>] ? arch_unmap_area_topdown+0x0/0x18
> [ 6136.579319] [<c1091a68>] do_munmap+0x1e8/0x200
> [ 6136.579325] [<c1091b93>] sys_munmap+0x32/0x42
> [ 6136.579330] [<c10027d3>] sysenter_do_call+0x12/0x32
>



Right.


The problem is:

vfs_readdir() { do_munmap() {
mutex_lock(inode); read or write(don't know)_lock(mm->mmap_sem)
reiserfs_readdir() { reiserfs_file_release() {
read_lock(mm->mmap_sem) mutex_lock(inode);
} }
} }



I don't think the deadlock can really happen, as we can't release the directory while
we are reading it. Plus I guess we can't mmap a directory (someone correct me if
I'm wrong).

But still the warning is annoying. I suspect this was there for a while.
There are other known "inversions that can't happen" in reiserfs, one is
on the xattrs code (reiserfs/xattr.c:xattr_unlink()) which warning you
can trigger under testing pressure.

But this one looks easy to trigger, although I've never seen it, but I'll
try your testcase.

Anyway, we can't change the readdir path. mutex -> mm->mmap_sem is the correct
ordering, we need to call copy_to_user there anyway.

So the challenge is to look at this mutex_lock(&inode->i_mutex) in
reiserfs_file_release(). I really don't know what it is protecting.

Is there someone who could give me a hint here?



> As well as this:
>
> [ 202.300464] REISERFS error (device sda9): vs-2100 add_save_link:
> search_by_key ([-1 7812832 0x1 IND]) returned 1
> [ 202.300473] REISERFS (device sda9): Remounting filesystem read-only
> [ 202.301603] ------------[ cut here ]------------
> [ 202.301615] WARNING: at fs/reiserfs/journal.c:3436
> journal_end+0x5b/0xaf()
> [ 202.301619] Hardware name: F3JC
> [ 202.301622] Modules linked in: snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_hda_codec_si3054
> snd_hda_codec_realtek snd_hwdep snd_pcm_oss snd_mixer_oss asus_laptop
> sparse_keymap sdhci_pci sdhci snd_hda_intel mmc_core led_class snd_hda_codec
> rng_core snd_pcm snd_timer snd_page_alloc snd i2c_i801 soundcore psmouse sg
> evdev serio_raw r8169 mii usbhid hid uhci_hcd ehci_hcd sr_mod usbcore cdrom
> sd_mod ata_piix
> [ 202.301689] Pid: 5055, comm: a.out Not tainted
> 2.6.35-rc3-dbg-git6-00502-g94feaba-dirty #65
> [ 202.301693] Call Trace:
> [ 202.301701] [<c102e3a2>] warn_slowpath_common+0x65/0x7a
> [ 202.301707] [<c1102d95>] ? journal_end+0x5b/0xaf
> [ 202.301712] [<c102e3c6>] warn_slowpath_null+0xf/0x13
> [ 202.301718] [<c1102d95>] journal_end+0x5b/0xaf
> [ 202.301725] [<c10eebaa>] reiserfs_truncate_file+0x19f/0x233
> [ 202.301733] [<c10f1ba1>] reiserfs_vfs_truncate_file+0xd/0xf
> [ 202.301738] [<c1084883>] vmtruncate+0x23/0x29
> [ 202.301745] [<c10b4ad4>] inode_setattr+0x47/0x68
> [ 202.301751] [<c10f1b3f>] reiserfs_setattr+0x242/0x297
> [ 202.301758] [<c12c5d05>] ? down_write+0x22/0x2a
> [ 202.301764] [<c10b4d6f>] notify_change+0x15c/0x26b
> [ 202.301770] [<c10a35c7>] do_truncate+0x64/0x7d
> [ 202.301776] [<c12c69b0>] ? _raw_spin_unlock+0x33/0x3f
> [ 202.301783] [<c10ad892>] do_last+0x450/0x459
> [ 202.301789] [<c10ada5b>] do_filp_open+0x1c0/0x41a
> [ 202.301798] [<c1029081>] ? get_parent_ip+0xb/0x31
> [ 202.301804] [<c1029123>] ? sub_preempt_count+0x7c/0x89
> [ 202.301810] [<c10b5746>] ? alloc_fd+0xb4/0xbf
> [ 202.301816] [<c10a3f46>] do_sys_open+0x48/0xdf
> [ 202.301821] [<c10a3ffb>] sys_open+0x1e/0x26
> [ 202.301827] [<c10027d3>] sysenter_do_call+0x12/0x32
> [ 202.301833] ---[ end trace c4e3312bdadd2dc5 ]---



Ah that's wicked. I'll try your testcase for that too.

Thanks a lot for providing these!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on
On Fri, 2010-07-02 at 15:12 +0200, Frederic Weisbecker wrote:
>
> I don't think the deadlock can really happen, as we can't release the directory while
> we are reading it. Plus I guess we can't mmap a directory (someone correct me if
> I'm wrong).
>

> Is there someone who could give me a hint here?

If its purely directories you can try and give directory inode locks a
different class.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Sergey Senozhatsky on
On (07/02/10 15:12), Frederic Weisbecker wrote:
> > As well as this:
> >
> > [ 202.300464] REISERFS error (device sda9): vs-2100 add_save_link:
> > search_by_key ([-1 7812832 0x1 IND]) returned 1
> > [ 202.300473] REISERFS (device sda9): Remounting filesystem read-only
> > [ 202.301603] ------------[ cut here ]------------
> > [ 202.301615] WARNING: at fs/reiserfs/journal.c:3436
> > journal_end+0x5b/0xaf()
> > [ 202.301619] Hardware name: F3JC
> > [ 202.301622] Modules linked in: snd_seq_dummy snd_seq_oss
> > snd_seq_midi_event snd_seq snd_seq_device snd_hda_codec_si3054
> > snd_hda_codec_realtek snd_hwdep snd_pcm_oss snd_mixer_oss asus_laptop
> > sparse_keymap sdhci_pci sdhci snd_hda_intel mmc_core led_class snd_hda_codec
> > rng_core snd_pcm snd_timer snd_page_alloc snd i2c_i801 soundcore psmouse sg
> > evdev serio_raw r8169 mii usbhid hid uhci_hcd ehci_hcd sr_mod usbcore cdrom
> > sd_mod ata_piix
> > [ 202.301689] Pid: 5055, comm: a.out Not tainted
> > 2.6.35-rc3-dbg-git6-00502-g94feaba-dirty #65
> > [ 202.301693] Call Trace:
> > [ 202.301701] [<c102e3a2>] warn_slowpath_common+0x65/0x7a
> > [ 202.301707] [<c1102d95>] ? journal_end+0x5b/0xaf
> > [ 202.301712] [<c102e3c6>] warn_slowpath_null+0xf/0x13
> > [ 202.301718] [<c1102d95>] journal_end+0x5b/0xaf
> > [ 202.301725] [<c10eebaa>] reiserfs_truncate_file+0x19f/0x233
> > [ 202.301733] [<c10f1ba1>] reiserfs_vfs_truncate_file+0xd/0xf
> > [ 202.301738] [<c1084883>] vmtruncate+0x23/0x29
> > [ 202.301745] [<c10b4ad4>] inode_setattr+0x47/0x68
> > [ 202.301751] [<c10f1b3f>] reiserfs_setattr+0x242/0x297
> > [ 202.301758] [<c12c5d05>] ? down_write+0x22/0x2a
> > [ 202.301764] [<c10b4d6f>] notify_change+0x15c/0x26b
> > [ 202.301770] [<c10a35c7>] do_truncate+0x64/0x7d
> > [ 202.301776] [<c12c69b0>] ? _raw_spin_unlock+0x33/0x3f
> > [ 202.301783] [<c10ad892>] do_last+0x450/0x459
> > [ 202.301789] [<c10ada5b>] do_filp_open+0x1c0/0x41a
> > [ 202.301798] [<c1029081>] ? get_parent_ip+0xb/0x31
> > [ 202.301804] [<c1029123>] ? sub_preempt_count+0x7c/0x89
> > [ 202.301810] [<c10b5746>] ? alloc_fd+0xb4/0xbf
> > [ 202.301816] [<c10a3f46>] do_sys_open+0x48/0xdf
> > [ 202.301821] [<c10a3ffb>] sys_open+0x1e/0x26
> > [ 202.301827] [<c10027d3>] sysenter_do_call+0x12/0x32
> > [ 202.301833] ---[ end trace c4e3312bdadd2dc5 ]---
>
>
>
> Ah that's wicked. I'll try your testcase for that too.
>
> Thanks a lot for providing these!
>

I'm not very lucky at hitting this. Saw it several times (may be 3).


Sergey
From: Edward Shishkin on
Frederic Weisbecker wrote:
> On Fri, Jul 02, 2010 at 12:34:51PM +0300, Sergey Senozhatsky wrote:
>
>> Hello,
>>
>> I searched lkml and found the following report (titled reiserfs locking):
>> http://lkml.org/lkml/2010/4/15/389 (Fri, 16 Apr 2010)
>>
>> I can see this backtrace while configuring emacs:
>>
>> [ 6136.579013]
>> [ 6136.579015] =======================================================
>> [ 6136.579021] [ INFO: possible circular locking dependency detected ]
>> [ 6136.579025] 2.6.35-rc3-dbg-git3-00350-g94d119f #61
>> [ 6136.579027] -------------------------------------------------------
>> [ 6136.579031] conftest/13950 is trying to acquire lock:
>> [ 6136.579034] (&sb->s_type->i_mutex_key#10){+.+.+.}, at: [<c10f1cf6>] reiserfs_file_release+0x11d/0x344
>> [ 6136.579050]
>> [ 6136.579051] but task is already holding lock:
>> [ 6136.579054] (&mm->mmap_sem){++++++}, at: [<c1091b87>] sys_munmap+0x26/0x42
>> [ 6136.579064]
>> [ 6136.579065] which lock already depends on the new lock.
>> [ 6136.579066]
>> [ 6136.579069]
>> [ 6136.579070] the existing dependency chain (in reverse order) is:
>> [ 6136.579073]
>> [ 6136.579074] -> #1 (&mm->mmap_sem){++++++}:
>> [ 6136.579081] [<c104f53a>] lock_acquire+0x59/0x70
>> [ 6136.579089] [<c108cf78>] might_fault+0x53/0x70
>> [ 6136.579094] [<c11853b8>] copy_to_user+0x30/0x48
>> [ 6136.579101] [<c10afaf9>] filldir64+0x95/0xc9
>> [ 6136.579106] [<c10f2504>] reiserfs_readdir_dentry+0x35d/0x4d9
>> [ 6136.579112] [<c10f2692>] reiserfs_readdir+0x12/0x17
>> [ 6136.579117] [<c10afd17>] vfs_readdir+0x6d/0x92
>> [ 6136.579122] [<c10afe91>] sys_getdents64+0x63/0xa2
>> [ 6136.579127] [<c10027d3>] sysenter_do_call+0x12/0x32
>> [ 6136.579134]
>> [ 6136.579135] -> #0 (&sb->s_type->i_mutex_key#10){+.+.+.}:
>> [ 6136.579142] [<c104ef30>] __lock_acquire+0x96d/0xbe1
>> [ 6136.579148] [<c104f53a>] lock_acquire+0x59/0x70
>> [ 6136.579153] [<c12c5614>] __mutex_lock_common+0x39/0x36b
>> [ 6136.579160] [<c12c5980>] mutex_lock_nested+0x12/0x15
>> [ 6136.579165] [<c10f1cf6>] reiserfs_file_release+0x11d/0x344
>> [ 6136.579171] [<c10a580d>] fput+0xe0/0x16a
>> [ 6136.579177] [<c1090ca6>] remove_vma+0x28/0x47
>> [ 6136.579182] [<c1091a68>] do_munmap+0x1e8/0x200
>> [ 6136.579188] [<c1091b93>] sys_munmap+0x32/0x42
>> [ 6136.579193] [<c10027d3>] sysenter_do_call+0x12/0x32
>> [ 6136.579198]
>> [ 6136.579199] other info that might help us debug this:
>> [ 6136.579200]
>> [ 6136.579204] 1 lock held by conftest/13950:
>> [ 6136.579207] #0: (&mm->mmap_sem){++++++}, at: [<c1091b87>] sys_munmap+0x26/0x42
>> [ 6136.579216]
>> [ 6136.579217] stack backtrace:
>> [ 6136.579221] Pid: 13950, comm: conftest Not tainted 2.6.35-rc3-dbg-git3-00350-g94d119f #61
>> [ 6136.579225] Call Trace:
>> [ 6136.579230] [<c12c4893>] ? printk+0xf/0x11
>> [ 6136.579235] [<c104dbdd>] print_circular_bug+0x8a/0x96
>> [ 6136.579241] [<c104ef30>] __lock_acquire+0x96d/0xbe1
>> [ 6136.579247] [<c104e436>] ? mark_lock+0x26/0x1b3
>> [ 6136.579254] [<c104f53a>] lock_acquire+0x59/0x70
>> [ 6136.579259] [<c10f1cf6>] ? reiserfs_file_release+0x11d/0x344
>> [ 6136.579265] [<c12c5614>] __mutex_lock_common+0x39/0x36b
>> [ 6136.579270] [<c10f1cf6>] ? reiserfs_file_release+0x11d/0x344
>> [ 6136.579276] [<c1084375>] ? release_pages+0x55/0x116
>> [ 6136.579282] [<c12c5980>] mutex_lock_nested+0x12/0x15
>> [ 6136.579287] [<c10f1cf6>] ? reiserfs_file_release+0x11d/0x344
>> [ 6136.579293] [<c10f1cf6>] reiserfs_file_release+0x11d/0x344
>> [ 6136.579299] [<c10a57bd>] ? fput+0x90/0x16a
>> [ 6136.579304] [<c10a580d>] fput+0xe0/0x16a
>> [ 6136.579309] [<c1090ca6>] remove_vma+0x28/0x47
>> [ 6136.579314] [<c1091819>] ? arch_unmap_area_topdown+0x0/0x18
>> [ 6136.579319] [<c1091a68>] do_munmap+0x1e8/0x200
>> [ 6136.579325] [<c1091b93>] sys_munmap+0x32/0x42
>> [ 6136.579330] [<c10027d3>] sysenter_do_call+0x12/0x32
>>
>>
>
>
>
> Right.
>
>
> The problem is:
>
> vfs_readdir() { do_munmap() {
> mutex_lock(inode); read or write(don't know)_lock(mm->mmap_sem)
> reiserfs_readdir() { reiserfs_file_release() {
> read_lock(mm->mmap_sem) mutex_lock(inode);
> } }
> } }
>
>
>
> I don't think the deadlock can really happen, as we can't release the directory while
> we are reading it. Plus I guess we can't mmap a directory (someone correct me if
> I'm wrong).
>
> But still the warning is annoying. I suspect this was there for a while.
> There are other known "inversions that can't happen" in reiserfs, one is
> on the xattrs code (reiserfs/xattr.c:xattr_unlink()) which warning you
> can trigger under testing pressure.
>
> But this one looks easy to trigger, although I've never seen it, but I'll
> try your testcase.
>
> Anyway, we can't change the readdir path. mutex -> mm->mmap_sem is the correct
> ordering, we need to call copy_to_user there anyway.
>
> So the challenge is to look at this mutex_lock(&inode->i_mutex) in
> reiserfs_file_release(). I really don't know what it is protecting.
>
> Is there someone who could give me a hint here?
>

I guess this protects file's data during so-called tail conversions.
This is a comment in indirect2direct():

// we are protected by i_mutex. The tail can not disapper, not
// append can be done either
// we are in truncate or packing tail in file_release


Edward.
>
>
>> As well as this:
>>
>> [ 202.300464] REISERFS error (device sda9): vs-2100 add_save_link:
>> search_by_key ([-1 7812832 0x1 IND]) returned 1
>> [ 202.300473] REISERFS (device sda9): Remounting filesystem read-only
>> [ 202.301603] ------------[ cut here ]------------
>> [ 202.301615] WARNING: at fs/reiserfs/journal.c:3436
>> journal_end+0x5b/0xaf()
>> [ 202.301619] Hardware name: F3JC
>> [ 202.301622] Modules linked in: snd_seq_dummy snd_seq_oss
>> snd_seq_midi_event snd_seq snd_seq_device snd_hda_codec_si3054
>> snd_hda_codec_realtek snd_hwdep snd_pcm_oss snd_mixer_oss asus_laptop
>> sparse_keymap sdhci_pci sdhci snd_hda_intel mmc_core led_class snd_hda_codec
>> rng_core snd_pcm snd_timer snd_page_alloc snd i2c_i801 soundcore psmouse sg
>> evdev serio_raw r8169 mii usbhid hid uhci_hcd ehci_hcd sr_mod usbcore cdrom
>> sd_mod ata_piix
>> [ 202.301689] Pid: 5055, comm: a.out Not tainted
>> 2.6.35-rc3-dbg-git6-00502-g94feaba-dirty #65
>> [ 202.301693] Call Trace:
>> [ 202.301701] [<c102e3a2>] warn_slowpath_common+0x65/0x7a
>> [ 202.301707] [<c1102d95>] ? journal_end+0x5b/0xaf
>> [ 202.301712] [<c102e3c6>] warn_slowpath_null+0xf/0x13
>> [ 202.301718] [<c1102d95>] journal_end+0x5b/0xaf
>> [ 202.301725] [<c10eebaa>] reiserfs_truncate_file+0x19f/0x233
>> [ 202.301733] [<c10f1ba1>] reiserfs_vfs_truncate_file+0xd/0xf
>> [ 202.301738] [<c1084883>] vmtruncate+0x23/0x29
>> [ 202.301745] [<c10b4ad4>] inode_setattr+0x47/0x68
>> [ 202.301751] [<c10f1b3f>] reiserfs_setattr+0x242/0x297
>> [ 202.301758] [<c12c5d05>] ? down_write+0x22/0x2a
>> [ 202.301764] [<c10b4d6f>] notify_change+0x15c/0x26b
>> [ 202.301770] [<c10a35c7>] do_truncate+0x64/0x7d
>> [ 202.301776] [<c12c69b0>] ? _raw_spin_unlock+0x33/0x3f
>> [ 202.301783] [<c10ad892>] do_last+0x450/0x459
>> [ 202.301789] [<c10ada5b>] do_filp_open+0x1c0/0x41a
>> [ 202.301798] [<c1029081>] ? get_parent_ip+0xb/0x31
>> [ 202.301804] [<c1029123>] ? sub_preempt_count+0x7c/0x89
>> [ 202.301810] [<c10b5746>] ? alloc_fd+0xb4/0xbf
>> [ 202.301816] [<c10a3f46>] do_sys_open+0x48/0xdf
>> [ 202.301821] [<c10a3ffb>] sys_open+0x1e/0x26
>> [ 202.301827] [<c10027d3>] sysenter_do_call+0x12/0x32
>> [ 202.301833] ---[ end trace c4e3312bdadd2dc5 ]---
>>
>
>
>
> Ah that's wicked. I'll try your testcase for that too.
>
> Thanks a lot for providing these!
>
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>

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