diff for duplicates of <20090415233533.GA5962@nowhere> diff --git a/a/1.txt b/N1/1.txt index 0836619..9fdfd25 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,44 +1,36 @@ On Thu, Apr 16, 2009 at 01:07:36AM +0200, Ingo Molnar wrote: ->=20 +> > * Alexander Beregalov <a.beregalov@gmail.com> wrote: ->=20 +> > > 2009/4/14 Ingo Molnar <mingo@elte.hu>: > > > > > > * Alexander Beregalov <a.beregalov@gmail.com> wrote: > > > -> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wr= -ote: +> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wrote: > > >> > Ingo, > > >> > -> > >> > This small patchset fixes some deadlocks I've faced after tryi= -ng +> > >> > This small patchset fixes some deadlocks I've faced after trying > > >> > some pressures with dbench on a reiserfs partition. > > >> > -> > >> > There is still some work pending such as adding some checks to= - ensure we +> > >> > There is still some work pending such as adding some checks to ensure we > > >> > _always_ release the lock before sleeping, as you suggested. -> > >> > Also I have to fix a lockdep warning reported by Alessio Igor = -Bogani. +> > >> > Also I have to fix a lockdep warning reported by Alessio Igor Bogani. > > >> > And also some optimizations.... > > >> > > > >> > Thanks, > > >> > Frederic. > > >> > > > >> > Frederic Weisbecker (3): -> > >> > =A0 kill-the-BKL/reiserfs: provide a tool to lock only once th= -e write lock -> > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_truncate= -_file -> > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock once in -> > >> > =A0 =A0 reiserfs_dirty_inode +> > >> > kill-the-BKL/reiserfs: provide a tool to lock only once the write lock +> > >> > kill-the-BKL/reiserfs: lock only once in reiserfs_truncate_file +> > >> > kill-the-BKL/reiserfs: only acquire the write lock once in +> > >> > reiserfs_dirty_inode > > >> > -> > >> > =A0fs/reiserfs/inode.c =A0 =A0 =A0 =A0 | =A0 10 +++++++--- -> > >> > =A0fs/reiserfs/lock.c =A0 =A0 =A0 =A0 =A0| =A0 26 ++++++++++++= -++++++++++++++ -> > >> > =A0fs/reiserfs/super.c =A0 =A0 =A0 =A0 | =A0 15 +++++++++-----= -- -> > >> > =A0include/linux/reiserfs_fs.h | =A0 =A02 ++ -> > >> > =A04 files changed, 44 insertions(+), 9 deletions(-) +> > >> > fs/reiserfs/inode.c | 10 +++++++--- +> > >> > fs/reiserfs/lock.c | 26 ++++++++++++++++++++++++++ +> > >> > fs/reiserfs/super.c | 15 +++++++++------ +> > >> > include/linux/reiserfs_fs.h | 2 ++ +> > >> > 4 files changed, 44 insertions(+), 9 deletions(-) > > >> > > > >> > > >> Hi @@ -50,23 +42,21 @@ _file > > > > > > I'm wondering ... your version hash suggests you used vanilla > > > upstream as a base for your test. There's a string of other fixes -> > > from Frederic in tip:core/kill-the-BKL branch, have you picked th= -em +> > > from Frederic in tip:core/kill-the-BKL branch, have you picked them > > > all up when you did your testing? > > > > > > The most coherent way to test this would be to pick up the latest > > > core/kill-the-BKL git tree from: > > > -> > > =A0 git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-t= -ip.git core/kill-the-BKL +> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core/kill-the-BKL > > > -> >=20 -> > I did not know about this branch, now I am testing it and there is=20 +> > +> > I did not know about this branch, now I am testing it and there is > > no more problem with that testcase (dbench). -> >=20 +> > > > I will continue testing. ->=20 -> thanks for testing it! It seems reiserfs with Frederic's changes=20 +> +> thanks for testing it! It seems reiserfs with Frederic's changes > appears to be more stable now on your system. @@ -75,50 +65,44 @@ ip.git core/kill-the-BKL Yeah, thanks a lot for this testing! -=20 -> I saw your NFS circular locking kill-the-BKL problem report on LKML=20 + +> I saw your NFS circular locking kill-the-BKL problem report on LKML > - also attached below. ->=20 -> Hopefully someone on the Cc: list with NFS experience can point out=20 +> +> Hopefully someone on the Cc: list with NFS experience can point out > the BKL assumption that is causing this. ->=20 +> > Ingo ->=20 -> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.c= -om> ----- ->=20 +> +> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.com> ----- +> > Date: Wed, 15 Apr 2009 22:08:01 +0400 > From: Alexander Beregalov <a.beregalov@gmail.com> > To: linux-kernel <linux-kernel@vger.kernel.org>, > Ingo Molnar <mingo@elte.hu>, linux-nfs@vger.kernel.org -> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependen= -cy ->=20 +> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependency +> > Hi ->=20 +> > I have pulled core/kill-the-BKL on top of 2.6.30-rc2. ->=20 +> > device: '0:18': device_add ->=20 -> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= -=3D=3D=3D=3D=3D=3D=3D=3D +> +> ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.30-rc2-00057-g30aa902-dirty #5 > ------------------------------------------------------- > mount.nfs/1740 is trying to acquire lock: -> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x= -3c ->=20 +> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x3c +> > but task is already holding lock: -> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x= -228/0x36c ->=20 +> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x228/0x36c +> > which lock already depends on the new lock. ->=20 ->=20 +> +> > the existing dependency chain (in reverse order) is: ->=20 +> > -> #1 (&type->s_umount_key#24/1){+.+.+.}: > [<00000000004776d0>] lock_acquire+0x5c/0x74 > [<0000000000469f5c>] down_write_nested+0x38/0x50 @@ -129,7 +113,7 @@ cy > [<00000000004cf300>] do_mount+0x7c8/0x80c > [<00000000004ed2a4>] compat_sys_mount+0x224/0x274 > [<0000000000406154>] linux_sparc_syscall32+0x34/0x40 ->=20 +> > -> #0 (kernel_mutex){+.+.+.}: > [<00000000004776d0>] lock_acquire+0x5c/0x74 > [<00000000006f0ebc>] mutex_lock_nested+0x48/0x380 @@ -163,13 +147,13 @@ Thanks. -=20 + > other info that might help us debug this: ->=20 +> > 1 lock held by mount.nfs/1740: > #0: (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] > sget+0x228/0x36c ->=20 +> > stack backtrace: > Call Trace: > [00000000004755ac] print_circular_bug_tail+0xfc/0x10c @@ -189,11 +173,10 @@ Thanks. > [00000000005720dc] nfs3_proc_get_root+0x18/0x5c > [000000000056401c] nfs_get_root+0x34/0x17c > device: '0:19': device_add ->=20 +> > ----- End forwarded message ----- -- -To unsubscribe from this list: send the line "unsubscribe reiserfs-deve= -l" in +To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 9eddad1..a5b8bf1 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,46 +19,38 @@ "\00:1\0" "b\0" "On Thu, Apr 16, 2009 at 01:07:36AM +0200, Ingo Molnar wrote:\n" - ">=20\n" + "> \n" "> * Alexander Beregalov <a.beregalov@gmail.com> wrote:\n" - ">=20\n" + "> \n" "> > 2009/4/14 Ingo Molnar <mingo@elte.hu>:\n" "> > >\n" "> > > * Alexander Beregalov <a.beregalov@gmail.com> wrote:\n" "> > >\n" - "> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wr=\n" - "ote:\n" + "> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wrote:\n" "> > >> > Ingo,\n" "> > >> >\n" - "> > >> > This small patchset fixes some deadlocks I've faced after tryi=\n" - "ng\n" + "> > >> > This small patchset fixes some deadlocks I've faced after trying\n" "> > >> > some pressures with dbench on a reiserfs partition.\n" "> > >> >\n" - "> > >> > There is still some work pending such as adding some checks to=\n" - " ensure we\n" + "> > >> > There is still some work pending such as adding some checks to ensure we\n" "> > >> > _always_ release the lock before sleeping, as you suggested.\n" - "> > >> > Also I have to fix a lockdep warning reported by Alessio Igor =\n" - "Bogani.\n" + "> > >> > Also I have to fix a lockdep warning reported by Alessio Igor Bogani.\n" "> > >> > And also some optimizations....\n" "> > >> >\n" "> > >> > Thanks,\n" "> > >> > Frederic.\n" "> > >> >\n" "> > >> > Frederic Weisbecker (3):\n" - "> > >> > =A0 kill-the-BKL/reiserfs: provide a tool to lock only once th=\n" - "e write lock\n" - "> > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_truncate=\n" - "_file\n" - "> > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock once in\n" - "> > >> > =A0 =A0 reiserfs_dirty_inode\n" + "> > >> > \302\240 kill-the-BKL/reiserfs: provide a tool to lock only once the write lock\n" + "> > >> > \302\240 kill-the-BKL/reiserfs: lock only once in reiserfs_truncate_file\n" + "> > >> > \302\240 kill-the-BKL/reiserfs: only acquire the write lock once in\n" + "> > >> > \302\240 \302\240 reiserfs_dirty_inode\n" "> > >> >\n" - "> > >> > =A0fs/reiserfs/inode.c =A0 =A0 =A0 =A0 | =A0 10 +++++++---\n" - "> > >> > =A0fs/reiserfs/lock.c =A0 =A0 =A0 =A0 =A0| =A0 26 ++++++++++++=\n" - "++++++++++++++\n" - "> > >> > =A0fs/reiserfs/super.c =A0 =A0 =A0 =A0 | =A0 15 +++++++++-----=\n" - "-\n" - "> > >> > =A0include/linux/reiserfs_fs.h | =A0 =A02 ++\n" - "> > >> > =A04 files changed, 44 insertions(+), 9 deletions(-)\n" + "> > >> > \302\240fs/reiserfs/inode.c \302\240 \302\240 \302\240 \302\240 | \302\240 10 +++++++---\n" + "> > >> > \302\240fs/reiserfs/lock.c \302\240 \302\240 \302\240 \302\240 \302\240| \302\240 26 ++++++++++++++++++++++++++\n" + "> > >> > \302\240fs/reiserfs/super.c \302\240 \302\240 \302\240 \302\240 | \302\240 15 +++++++++------\n" + "> > >> > \302\240include/linux/reiserfs_fs.h | \302\240 \302\2402 ++\n" + "> > >> > \302\2404 files changed, 44 insertions(+), 9 deletions(-)\n" "> > >> >\n" "> > >>\n" "> > >> Hi\n" @@ -70,23 +62,21 @@ "> > >\n" "> > > I'm wondering ... your version hash suggests you used vanilla\n" "> > > upstream as a base for your test. There's a string of other fixes\n" - "> > > from Frederic in tip:core/kill-the-BKL branch, have you picked th=\n" - "em\n" + "> > > from Frederic in tip:core/kill-the-BKL branch, have you picked them\n" "> > > all up when you did your testing?\n" "> > >\n" "> > > The most coherent way to test this would be to pick up the latest\n" "> > > core/kill-the-BKL git tree from:\n" "> > >\n" - "> > > =A0 git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-t=\n" - "ip.git core/kill-the-BKL\n" + "> > > \302\240 git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core/kill-the-BKL\n" "> > >\n" - "> >=20\n" - "> > I did not know about this branch, now I am testing it and there is=20\n" + "> > \n" + "> > I did not know about this branch, now I am testing it and there is \n" "> > no more problem with that testcase (dbench).\n" - "> >=20\n" + "> > \n" "> > I will continue testing.\n" - ">=20\n" - "> thanks for testing it! It seems reiserfs with Frederic's changes=20\n" + "> \n" + "> thanks for testing it! It seems reiserfs with Frederic's changes \n" "> appears to be more stable now on your system.\n" "\n" "\n" @@ -95,50 +85,44 @@ "Yeah, thanks a lot for this testing!\n" "\n" "\n" - "=20\n" - "> I saw your NFS circular locking kill-the-BKL problem report on LKML=20\n" + " \n" + "> I saw your NFS circular locking kill-the-BKL problem report on LKML \n" "> - also attached below.\n" - ">=20\n" - "> Hopefully someone on the Cc: list with NFS experience can point out=20\n" + "> \n" + "> Hopefully someone on the Cc: list with NFS experience can point out \n" "> the BKL assumption that is causing this.\n" - ">=20\n" + "> \n" "> \tIngo\n" - ">=20\n" - "> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.c=\n" - "om> -----\n" - ">=20\n" + "> \n" + "> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.com> -----\n" + "> \n" "> Date: Wed, 15 Apr 2009 22:08:01 +0400\n" "> From: Alexander Beregalov <a.beregalov@gmail.com>\n" "> To: linux-kernel <linux-kernel@vger.kernel.org>,\n" "> \tIngo Molnar <mingo@elte.hu>, linux-nfs@vger.kernel.org\n" - "> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependen=\n" - "cy\n" - ">=20\n" + "> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependency\n" + "> \n" "> Hi\n" - ">=20\n" + "> \n" "> I have pulled core/kill-the-BKL on top of 2.6.30-rc2.\n" - ">=20\n" + "> \n" "> device: '0:18': device_add\n" - ">=20\n" - "> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=\n" - "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=\n" - "=3D=3D=3D=3D=3D=3D=3D=3D\n" + "> \n" + "> =======================================================\n" "> [ INFO: possible circular locking dependency detected ]\n" "> 2.6.30-rc2-00057-g30aa902-dirty #5\n" "> -------------------------------------------------------\n" "> mount.nfs/1740 is trying to acquire lock:\n" - "> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x=\n" - "3c\n" - ">=20\n" + "> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x3c\n" + "> \n" "> but task is already holding lock:\n" - "> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x=\n" - "228/0x36c\n" - ">=20\n" + "> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x228/0x36c\n" + "> \n" "> which lock already depends on the new lock.\n" - ">=20\n" - ">=20\n" + "> \n" + "> \n" "> the existing dependency chain (in reverse order) is:\n" - ">=20\n" + "> \n" "> -> #1 (&type->s_umount_key#24/1){+.+.+.}:\n" "> [<00000000004776d0>] lock_acquire+0x5c/0x74\n" "> [<0000000000469f5c>] down_write_nested+0x38/0x50\n" @@ -149,7 +133,7 @@ "> [<00000000004cf300>] do_mount+0x7c8/0x80c\n" "> [<00000000004ed2a4>] compat_sys_mount+0x224/0x274\n" "> [<0000000000406154>] linux_sparc_syscall32+0x34/0x40\n" - ">=20\n" + "> \n" "> -> #0 (kernel_mutex){+.+.+.}:\n" "> [<00000000004776d0>] lock_acquire+0x5c/0x74\n" "> [<00000000006f0ebc>] mutex_lock_nested+0x48/0x380\n" @@ -183,13 +167,13 @@ "\n" "\n" "\n" - "=20\n" + " \n" "> other info that might help us debug this:\n" - ">=20\n" + "> \n" "> 1 lock held by mount.nfs/1740:\n" "> #0: (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>]\n" "> sget+0x228/0x36c\n" - ">=20\n" + "> \n" "> stack backtrace:\n" "> Call Trace:\n" "> [00000000004755ac] print_circular_bug_tail+0xfc/0x10c\n" @@ -209,13 +193,12 @@ "> [00000000005720dc] nfs3_proc_get_root+0x18/0x5c\n" "> [000000000056401c] nfs_get_root+0x34/0x17c\n" "> device: '0:19': device_add\n" - ">=20\n" + "> \n" "> ----- End forwarded message -----\n" "\n" "--\n" - "To unsubscribe from this list: send the line \"unsubscribe reiserfs-deve=\n" - "l\" in\n" + "To unsubscribe from this list: send the line \"unsubscribe reiserfs-devel\" in\n" "the body of a message to majordomo@vger.kernel.org\n" More majordomo info at http://vger.kernel.org/majordomo-info.html -efb958f0afce7ba3d8a99303e49be2fa48c418189ad02c81bbd03f7aff4fc0a9 +ff36d3f8a23ef2fb5f7f0e41be51e89b5de43fed4185e43ec328ed0837f2c70f
diff --git a/a/1.txt b/N2/1.txt index 0836619..347f014 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,44 +1,36 @@ On Thu, Apr 16, 2009 at 01:07:36AM +0200, Ingo Molnar wrote: ->=20 +> > * Alexander Beregalov <a.beregalov@gmail.com> wrote: ->=20 +> > > 2009/4/14 Ingo Molnar <mingo@elte.hu>: > > > > > > * Alexander Beregalov <a.beregalov@gmail.com> wrote: > > > -> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wr= -ote: +> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wrote: > > >> > Ingo, > > >> > -> > >> > This small patchset fixes some deadlocks I've faced after tryi= -ng +> > >> > This small patchset fixes some deadlocks I've faced after trying > > >> > some pressures with dbench on a reiserfs partition. > > >> > -> > >> > There is still some work pending such as adding some checks to= - ensure we +> > >> > There is still some work pending such as adding some checks to ensure we > > >> > _always_ release the lock before sleeping, as you suggested. -> > >> > Also I have to fix a lockdep warning reported by Alessio Igor = -Bogani. +> > >> > Also I have to fix a lockdep warning reported by Alessio Igor Bogani. > > >> > And also some optimizations.... > > >> > > > >> > Thanks, > > >> > Frederic. > > >> > > > >> > Frederic Weisbecker (3): -> > >> > =A0 kill-the-BKL/reiserfs: provide a tool to lock only once th= -e write lock -> > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_truncate= -_file -> > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock once in -> > >> > =A0 =A0 reiserfs_dirty_inode +> > >> > kill-the-BKL/reiserfs: provide a tool to lock only once the write lock +> > >> > kill-the-BKL/reiserfs: lock only once in reiserfs_truncate_file +> > >> > kill-the-BKL/reiserfs: only acquire the write lock once in +> > >> > reiserfs_dirty_inode > > >> > -> > >> > =A0fs/reiserfs/inode.c =A0 =A0 =A0 =A0 | =A0 10 +++++++--- -> > >> > =A0fs/reiserfs/lock.c =A0 =A0 =A0 =A0 =A0| =A0 26 ++++++++++++= -++++++++++++++ -> > >> > =A0fs/reiserfs/super.c =A0 =A0 =A0 =A0 | =A0 15 +++++++++-----= -- -> > >> > =A0include/linux/reiserfs_fs.h | =A0 =A02 ++ -> > >> > =A04 files changed, 44 insertions(+), 9 deletions(-) +> > >> > fs/reiserfs/inode.c | 10 +++++++--- +> > >> > fs/reiserfs/lock.c | 26 ++++++++++++++++++++++++++ +> > >> > fs/reiserfs/super.c | 15 +++++++++------ +> > >> > include/linux/reiserfs_fs.h | 2 ++ +> > >> > 4 files changed, 44 insertions(+), 9 deletions(-) > > >> > > > >> > > >> Hi @@ -50,23 +42,21 @@ _file > > > > > > I'm wondering ... your version hash suggests you used vanilla > > > upstream as a base for your test. There's a string of other fixes -> > > from Frederic in tip:core/kill-the-BKL branch, have you picked th= -em +> > > from Frederic in tip:core/kill-the-BKL branch, have you picked them > > > all up when you did your testing? > > > > > > The most coherent way to test this would be to pick up the latest > > > core/kill-the-BKL git tree from: > > > -> > > =A0 git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-t= -ip.git core/kill-the-BKL +> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core/kill-the-BKL > > > -> >=20 -> > I did not know about this branch, now I am testing it and there is=20 +> > +> > I did not know about this branch, now I am testing it and there is > > no more problem with that testcase (dbench). -> >=20 +> > > > I will continue testing. ->=20 -> thanks for testing it! It seems reiserfs with Frederic's changes=20 +> +> thanks for testing it! It seems reiserfs with Frederic's changes > appears to be more stable now on your system. @@ -75,50 +65,44 @@ ip.git core/kill-the-BKL Yeah, thanks a lot for this testing! -=20 -> I saw your NFS circular locking kill-the-BKL problem report on LKML=20 + +> I saw your NFS circular locking kill-the-BKL problem report on LKML > - also attached below. ->=20 -> Hopefully someone on the Cc: list with NFS experience can point out=20 +> +> Hopefully someone on the Cc: list with NFS experience can point out > the BKL assumption that is causing this. ->=20 +> > Ingo ->=20 -> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.c= -om> ----- ->=20 +> +> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.com> ----- +> > Date: Wed, 15 Apr 2009 22:08:01 +0400 > From: Alexander Beregalov <a.beregalov@gmail.com> > To: linux-kernel <linux-kernel@vger.kernel.org>, > Ingo Molnar <mingo@elte.hu>, linux-nfs@vger.kernel.org -> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependen= -cy ->=20 +> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependency +> > Hi ->=20 +> > I have pulled core/kill-the-BKL on top of 2.6.30-rc2. ->=20 +> > device: '0:18': device_add ->=20 -> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= -=3D=3D=3D=3D=3D=3D=3D=3D +> +> ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.30-rc2-00057-g30aa902-dirty #5 > ------------------------------------------------------- > mount.nfs/1740 is trying to acquire lock: -> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x= -3c ->=20 +> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x3c +> > but task is already holding lock: -> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x= -228/0x36c ->=20 +> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x228/0x36c +> > which lock already depends on the new lock. ->=20 ->=20 +> +> > the existing dependency chain (in reverse order) is: ->=20 +> > -> #1 (&type->s_umount_key#24/1){+.+.+.}: > [<00000000004776d0>] lock_acquire+0x5c/0x74 > [<0000000000469f5c>] down_write_nested+0x38/0x50 @@ -129,7 +113,7 @@ cy > [<00000000004cf300>] do_mount+0x7c8/0x80c > [<00000000004ed2a4>] compat_sys_mount+0x224/0x274 > [<0000000000406154>] linux_sparc_syscall32+0x34/0x40 ->=20 +> > -> #0 (kernel_mutex){+.+.+.}: > [<00000000004776d0>] lock_acquire+0x5c/0x74 > [<00000000006f0ebc>] mutex_lock_nested+0x48/0x380 @@ -163,13 +147,13 @@ Thanks. -=20 + > other info that might help us debug this: ->=20 +> > 1 lock held by mount.nfs/1740: > #0: (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] > sget+0x228/0x36c ->=20 +> > stack backtrace: > Call Trace: > [00000000004755ac] print_circular_bug_tail+0xfc/0x10c @@ -189,11 +173,5 @@ Thanks. > [00000000005720dc] nfs3_proc_get_root+0x18/0x5c > [000000000056401c] nfs_get_root+0x34/0x17c > device: '0:19': device_add ->=20 +> > ----- End forwarded message ----- - --- -To unsubscribe from this list: send the line "unsubscribe reiserfs-deve= -l" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index 9eddad1..4ff5634 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -19,46 +19,38 @@ "\00:1\0" "b\0" "On Thu, Apr 16, 2009 at 01:07:36AM +0200, Ingo Molnar wrote:\n" - ">=20\n" + "> \n" "> * Alexander Beregalov <a.beregalov@gmail.com> wrote:\n" - ">=20\n" + "> \n" "> > 2009/4/14 Ingo Molnar <mingo@elte.hu>:\n" "> > >\n" "> > > * Alexander Beregalov <a.beregalov@gmail.com> wrote:\n" "> > >\n" - "> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wr=\n" - "ote:\n" + "> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wrote:\n" "> > >> > Ingo,\n" "> > >> >\n" - "> > >> > This small patchset fixes some deadlocks I've faced after tryi=\n" - "ng\n" + "> > >> > This small patchset fixes some deadlocks I've faced after trying\n" "> > >> > some pressures with dbench on a reiserfs partition.\n" "> > >> >\n" - "> > >> > There is still some work pending such as adding some checks to=\n" - " ensure we\n" + "> > >> > There is still some work pending such as adding some checks to ensure we\n" "> > >> > _always_ release the lock before sleeping, as you suggested.\n" - "> > >> > Also I have to fix a lockdep warning reported by Alessio Igor =\n" - "Bogani.\n" + "> > >> > Also I have to fix a lockdep warning reported by Alessio Igor Bogani.\n" "> > >> > And also some optimizations....\n" "> > >> >\n" "> > >> > Thanks,\n" "> > >> > Frederic.\n" "> > >> >\n" "> > >> > Frederic Weisbecker (3):\n" - "> > >> > =A0 kill-the-BKL/reiserfs: provide a tool to lock only once th=\n" - "e write lock\n" - "> > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_truncate=\n" - "_file\n" - "> > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock once in\n" - "> > >> > =A0 =A0 reiserfs_dirty_inode\n" + "> > >> > \302\240 kill-the-BKL/reiserfs: provide a tool to lock only once the write lock\n" + "> > >> > \302\240 kill-the-BKL/reiserfs: lock only once in reiserfs_truncate_file\n" + "> > >> > \302\240 kill-the-BKL/reiserfs: only acquire the write lock once in\n" + "> > >> > \302\240 \302\240 reiserfs_dirty_inode\n" "> > >> >\n" - "> > >> > =A0fs/reiserfs/inode.c =A0 =A0 =A0 =A0 | =A0 10 +++++++---\n" - "> > >> > =A0fs/reiserfs/lock.c =A0 =A0 =A0 =A0 =A0| =A0 26 ++++++++++++=\n" - "++++++++++++++\n" - "> > >> > =A0fs/reiserfs/super.c =A0 =A0 =A0 =A0 | =A0 15 +++++++++-----=\n" - "-\n" - "> > >> > =A0include/linux/reiserfs_fs.h | =A0 =A02 ++\n" - "> > >> > =A04 files changed, 44 insertions(+), 9 deletions(-)\n" + "> > >> > \302\240fs/reiserfs/inode.c \302\240 \302\240 \302\240 \302\240 | \302\240 10 +++++++---\n" + "> > >> > \302\240fs/reiserfs/lock.c \302\240 \302\240 \302\240 \302\240 \302\240| \302\240 26 ++++++++++++++++++++++++++\n" + "> > >> > \302\240fs/reiserfs/super.c \302\240 \302\240 \302\240 \302\240 | \302\240 15 +++++++++------\n" + "> > >> > \302\240include/linux/reiserfs_fs.h | \302\240 \302\2402 ++\n" + "> > >> > \302\2404 files changed, 44 insertions(+), 9 deletions(-)\n" "> > >> >\n" "> > >>\n" "> > >> Hi\n" @@ -70,23 +62,21 @@ "> > >\n" "> > > I'm wondering ... your version hash suggests you used vanilla\n" "> > > upstream as a base for your test. There's a string of other fixes\n" - "> > > from Frederic in tip:core/kill-the-BKL branch, have you picked th=\n" - "em\n" + "> > > from Frederic in tip:core/kill-the-BKL branch, have you picked them\n" "> > > all up when you did your testing?\n" "> > >\n" "> > > The most coherent way to test this would be to pick up the latest\n" "> > > core/kill-the-BKL git tree from:\n" "> > >\n" - "> > > =A0 git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-t=\n" - "ip.git core/kill-the-BKL\n" + "> > > \302\240 git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core/kill-the-BKL\n" "> > >\n" - "> >=20\n" - "> > I did not know about this branch, now I am testing it and there is=20\n" + "> > \n" + "> > I did not know about this branch, now I am testing it and there is \n" "> > no more problem with that testcase (dbench).\n" - "> >=20\n" + "> > \n" "> > I will continue testing.\n" - ">=20\n" - "> thanks for testing it! It seems reiserfs with Frederic's changes=20\n" + "> \n" + "> thanks for testing it! It seems reiserfs with Frederic's changes \n" "> appears to be more stable now on your system.\n" "\n" "\n" @@ -95,50 +85,44 @@ "Yeah, thanks a lot for this testing!\n" "\n" "\n" - "=20\n" - "> I saw your NFS circular locking kill-the-BKL problem report on LKML=20\n" + " \n" + "> I saw your NFS circular locking kill-the-BKL problem report on LKML \n" "> - also attached below.\n" - ">=20\n" - "> Hopefully someone on the Cc: list with NFS experience can point out=20\n" + "> \n" + "> Hopefully someone on the Cc: list with NFS experience can point out \n" "> the BKL assumption that is causing this.\n" - ">=20\n" + "> \n" "> \tIngo\n" - ">=20\n" - "> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.c=\n" - "om> -----\n" - ">=20\n" + "> \n" + "> ----- Forwarded message from Alexander Beregalov <a.beregalov@gmail.com> -----\n" + "> \n" "> Date: Wed, 15 Apr 2009 22:08:01 +0400\n" "> From: Alexander Beregalov <a.beregalov@gmail.com>\n" "> To: linux-kernel <linux-kernel@vger.kernel.org>,\n" "> \tIngo Molnar <mingo@elte.hu>, linux-nfs@vger.kernel.org\n" - "> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependen=\n" - "cy\n" - ">=20\n" + "> Subject: [core/kill-the-BKL] nfs3: possible circular locking dependency\n" + "> \n" "> Hi\n" - ">=20\n" + "> \n" "> I have pulled core/kill-the-BKL on top of 2.6.30-rc2.\n" - ">=20\n" + "> \n" "> device: '0:18': device_add\n" - ">=20\n" - "> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=\n" - "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=\n" - "=3D=3D=3D=3D=3D=3D=3D=3D\n" + "> \n" + "> =======================================================\n" "> [ INFO: possible circular locking dependency detected ]\n" "> 2.6.30-rc2-00057-g30aa902-dirty #5\n" "> -------------------------------------------------------\n" "> mount.nfs/1740 is trying to acquire lock:\n" - "> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x=\n" - "3c\n" - ">=20\n" + "> (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x3c\n" + "> \n" "> but task is already holding lock:\n" - "> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x=\n" - "228/0x36c\n" - ">=20\n" + "> (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+0x228/0x36c\n" + "> \n" "> which lock already depends on the new lock.\n" - ">=20\n" - ">=20\n" + "> \n" + "> \n" "> the existing dependency chain (in reverse order) is:\n" - ">=20\n" + "> \n" "> -> #1 (&type->s_umount_key#24/1){+.+.+.}:\n" "> [<00000000004776d0>] lock_acquire+0x5c/0x74\n" "> [<0000000000469f5c>] down_write_nested+0x38/0x50\n" @@ -149,7 +133,7 @@ "> [<00000000004cf300>] do_mount+0x7c8/0x80c\n" "> [<00000000004ed2a4>] compat_sys_mount+0x224/0x274\n" "> [<0000000000406154>] linux_sparc_syscall32+0x34/0x40\n" - ">=20\n" + "> \n" "> -> #0 (kernel_mutex){+.+.+.}:\n" "> [<00000000004776d0>] lock_acquire+0x5c/0x74\n" "> [<00000000006f0ebc>] mutex_lock_nested+0x48/0x380\n" @@ -183,13 +167,13 @@ "\n" "\n" "\n" - "=20\n" + " \n" "> other info that might help us debug this:\n" - ">=20\n" + "> \n" "> 1 lock held by mount.nfs/1740:\n" "> #0: (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>]\n" "> sget+0x228/0x36c\n" - ">=20\n" + "> \n" "> stack backtrace:\n" "> Call Trace:\n" "> [00000000004755ac] print_circular_bug_tail+0xfc/0x10c\n" @@ -209,13 +193,7 @@ "> [00000000005720dc] nfs3_proc_get_root+0x18/0x5c\n" "> [000000000056401c] nfs_get_root+0x34/0x17c\n" "> device: '0:19': device_add\n" - ">=20\n" - "> ----- End forwarded message -----\n" - "\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe reiserfs-deve=\n" - "l\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + "> \n" + > ----- End forwarded message ----- -efb958f0afce7ba3d8a99303e49be2fa48c418189ad02c81bbd03f7aff4fc0a9 +ae91cc18810c2195343504eaf5bc6ec7305ff2cfbc1d7198f6aea5d9989e63d1
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.