diff for duplicates of <20090416164024.GJ6004@nowhere> diff --git a/a/1.txt b/N1/1.txt index 7804107..7abd647 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,50 +1,40 @@ On Thu, Apr 16, 2009 at 10:51:53AM +0200, Ingo Molnar wrote: ->=20 +> > * Frederic Weisbecker <fweisbec@gmail.com> wrote: ->=20 +> > > 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 Weisbecke= -r wrote: +> > > > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wrote: > > > > >> > Ingo, > > > > >> > -> > > > >> > This small patchset fixes some deadlocks I've faced after = -trying +> > > > >> > 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 check= -s to ensure we -> > > > >> > _always_ release the lock before sleeping, as you suggeste= -d. -> > > > >> > Also I have to fix a lockdep warning reported by Alessio I= -gor Bogani. +> > > > >> > 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. > > > > >> > And also some optimizations.... > > > > >> > > > > > >> > Thanks, > > > > >> > Frederic. > > > > >> > > > > > >> > Frederic Weisbecker (3): -> > > > >> > =A0 kill-the-BKL/reiserfs: provide a tool to lock only onc= -e the write lock -> > > > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_trun= -cate_file -> > > > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock onc= -e 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 @@ -55,81 +45,68 @@ e in > > > > >> 2.6.30-rc1-00457-gb21597d-dirty #2 > > > > > > > > > > I'm wondering ... your version hash suggests you used vanilla -> > > > > upstream as a base for your test. There's a string of other f= -ixes -> > > > > from Frederic in tip:core/kill-the-BKL branch, have you picke= -d them +> > > > > 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 them > > > > > all up when you did your testing? > > > > > -> > > > > The most coherent way to test this would be to pick up the la= -test +> > > > > 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= -=2E6-tip.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. -> >=20 -> >=20 -> >=20 -> >=20 +> > +> > +> > +> > > > Yeah, thanks a lot for this testing! -> >=20 -> >=20 -> > =20 -> > > I saw your NFS circular locking kill-the-BKL problem report on LK= -ML=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 o= -ut=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@gma= -il.com> ----- -> > >=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 depe= -ndency -> > >=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+0x2= -8/0x3c -> > >=20 +> > > (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x3c +> > > > > > but task is already holding lock: -> > > (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sge= -t+0x228/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 @@ -140,7 +117,7 @@ t+0x228/0x36c > > > [<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 @@ -162,16 +139,16 @@ t+0x228/0x36c > > > [<00000000004cf300>] do_mount+0x7c8/0x80c > > > [<00000000004ed2a4>] compat_sys_mount+0x224/0x274 > > > [<0000000000406154>] linux_sparc_syscall32+0x34/0x40 -> >=20 -> >=20 -> >=20 -> >=20 -> > This is still the dependency between bkl and s_umount_key that has=20 -> > been reported recently. I wonder if this is not a problem in the=20 +> > +> > +> > +> > +> > This is still the dependency between bkl and s_umount_key that has +> > been reported recently. I wonder if this is not a problem in the > > fs layer. I should investigate on it. ->=20 +> > The problem seem to be that this NFS call context: ->=20 +> > -> #0 (kernel_mutex){+.+.+.}: > [<00000000004776d0>] lock_acquire+0x5c/0x74 > [<00000000006f0ebc>] mutex_lock_nested+0x48/0x380 @@ -193,18 +170,18 @@ t+0x228/0x36c > [<00000000004cf300>] do_mount+0x7c8/0x80c > [<00000000004ed2a4>] compat_sys_mount+0x224/0x274 > [<0000000000406154>] linux_sparc_syscall32+0x34/0x40 ->=20 -> Can be called with the BKL held - and then it schedule()s with the=20 -> BKL held, creating dependencies. I did the quick hack below (a year=20 -> ago! :-) but indeed that's probably wrong: we just drop and then=20 -> re-acquire the BKL at a very low level - inverting the dependency=20 +> +> Can be called with the BKL held - and then it schedule()s with the +> BKL held, creating dependencies. I did the quick hack below (a year +> ago! :-) but indeed that's probably wrong: we just drop and then +> re-acquire the BKL at a very low level - inverting the dependency > chain. Indeed, the problem remains if we do that :-) -> It's not a problem of the NFS code, it's the probem of=20 +> It's not a problem of the NFS code, it's the probem of > vfs_kern_mount taking the BKL. @@ -213,47 +190,45 @@ is the right way. Even though this patch is beeing discussed, I think it opened the right direction to dig. -> Maybe it would be better if nfs_get_sb() dropped the BKL (knowing=20 -> that it's called with the BKL held) - since it does not rely on the=20 +> Maybe it would be better if nfs_get_sb() dropped the BKL (knowing +> that it's called with the BKL held) - since it does not rely on the > BKL? Not rpc_wait_bit_killable(). -I wonder if it is not dropped because it implicitly protects something = -else. +I wonder if it is not dropped because it implicitly protects something else. May be simply concurrent accesses to the superblock? -=46rederic. +Frederic. > Ingo ->=20 +> > --------------> -> From 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 200= -1 +> From 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 2001 > From: Ingo Molnar <mingo@elte.hu> > Date: Wed, 14 May 2008 17:31:41 +0200 > Subject: [PATCH] remove the BKL: restructure NFS code ->=20 +> > the naked schedule() in rpc_wait_bit_killable() caused the BKL to > be auto-dropped in the past. ->=20 +> > avoid the immediate hang in such code. Note that this still leaves > some other locking dependencies to be sorted out in the NFS code. ->=20 +> > Signed-off-by: Ingo Molnar <mingo@elte.hu> > --- > net/sunrpc/sched.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) ->=20 +> > diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c > index 6eab9bf..e12e571 100644 > --- a/net/sunrpc/sched.c > +++ b/net/sunrpc/sched.c > @@ -224,9 +224,15 @@ EXPORT_SYMBOL_GPL(rpc_destroy_wait_queue); -> =20 +> > static int rpc_wait_bit_killable(void *word) > { -> + int bkl =3D kernel_locked(); +> + int bkl = kernel_locked(); > + > if (fatal_signal_pending(current)) > return -ERESTARTSYS; @@ -269,4 +244,4 @@ Yeah as you said, it may not drop but invert the dependency. > return 0; > } -> =20 +> diff --git a/a/content_digest b/N1/content_digest index bce8c17..8e9a4bb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -21,52 +21,42 @@ "\00:1\0" "b\0" "On Thu, Apr 16, 2009 at 10:51:53AM +0200, Ingo Molnar wrote:\n" - ">=20\n" + "> \n" "> * Frederic Weisbecker <fweisbec@gmail.com> wrote:\n" - ">=20\n" + "> \n" "> > 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 Weisbecke=\n" - "r wrote:\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 =\n" - "trying\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 check=\n" - "s to ensure we\n" - "> > > > >> > _always_ release the lock before sleeping, as you suggeste=\n" - "d.\n" - "> > > > >> > Also I have to fix a lockdep warning reported by Alessio I=\n" - "gor Bogani.\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 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 onc=\n" - "e the write lock\n" - "> > > > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_trun=\n" - "cate_file\n" - "> > > > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock onc=\n" - "e 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" @@ -77,81 +67,68 @@ "> > > > >> 2.6.30-rc1-00457-gb21597d-dirty #2\n" "> > > > >\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 f=\n" - "ixes\n" - "> > > > > from Frederic in tip:core/kill-the-BKL branch, have you picke=\n" - "d them\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 them\n" "> > > > > all up when you did your testing?\n" "> > > > >\n" - "> > > > > The most coherent way to test this would be to pick up the la=\n" - "test\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=\n" - "=2E6-tip.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=\n" - " 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" - "> >=20\n" - "> >=20\n" - "> >=20\n" - "> >=20\n" + "> > \n" + "> > \n" + "> > \n" + "> > \n" "> > Yeah, thanks a lot for this testing!\n" - "> >=20\n" - "> >=20\n" - "> > =20\n" - "> > > I saw your NFS circular locking kill-the-BKL problem report on LK=\n" - "ML=20\n" + "> > \n" + "> > \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 o=\n" - "ut=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@gma=\n" - "il.com> -----\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 depe=\n" - "ndency\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=\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=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+0x2=\n" - "8/0x3c\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>] sge=\n" - "t+0x228/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" @@ -162,7 +139,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" @@ -184,16 +161,16 @@ "> > > [<00000000004cf300>] do_mount+0x7c8/0x80c\n" "> > > [<00000000004ed2a4>] compat_sys_mount+0x224/0x274\n" "> > > [<0000000000406154>] linux_sparc_syscall32+0x34/0x40\n" - "> >=20\n" - "> >=20\n" - "> >=20\n" - "> >=20\n" - "> > This is still the dependency between bkl and s_umount_key that has=20\n" - "> > been reported recently. I wonder if this is not a problem in the=20\n" + "> > \n" + "> > \n" + "> > \n" + "> > \n" + "> > This is still the dependency between bkl and s_umount_key that has \n" + "> > been reported recently. I wonder if this is not a problem in the \n" "> > fs layer. I should investigate on it.\n" - ">=20\n" + "> \n" "> The problem seem to be that this NFS call context:\n" - ">=20\n" + "> \n" "> -> #0 (kernel_mutex){+.+.+.}:\n" "> [<00000000004776d0>] lock_acquire+0x5c/0x74\n" "> [<00000000006f0ebc>] mutex_lock_nested+0x48/0x380\n" @@ -215,18 +192,18 @@ "> [<00000000004cf300>] do_mount+0x7c8/0x80c\n" "> [<00000000004ed2a4>] compat_sys_mount+0x224/0x274\n" "> [<0000000000406154>] linux_sparc_syscall32+0x34/0x40\n" - ">=20\n" - "> Can be called with the BKL held - and then it schedule()s with the=20\n" - "> BKL held, creating dependencies. I did the quick hack below (a year=20\n" - "> ago! :-) but indeed that's probably wrong: we just drop and then=20\n" - "> re-acquire the BKL at a very low level - inverting the dependency=20\n" + "> \n" + "> Can be called with the BKL held - and then it schedule()s with the \n" + "> BKL held, creating dependencies. I did the quick hack below (a year \n" + "> ago! :-) but indeed that's probably wrong: we just drop and then \n" + "> re-acquire the BKL at a very low level - inverting the dependency \n" "> chain.\n" "\n" "\n" "Indeed, the problem remains if we do that :-)\n" "\n" "\n" - "> It's not a problem of the NFS code, it's the probem of=20\n" + "> It's not a problem of the NFS code, it's the probem of \n" "> vfs_kern_mount taking the BKL.\n" "\n" "\n" @@ -235,47 +212,45 @@ "think it opened the right direction to dig.\n" "\n" "\n" - "> Maybe it would be better if nfs_get_sb() dropped the BKL (knowing=20\n" - "> that it's called with the BKL held) - since it does not rely on the=20\n" + "> Maybe it would be better if nfs_get_sb() dropped the BKL (knowing \n" + "> that it's called with the BKL held) - since it does not rely on the \n" "> BKL? Not rpc_wait_bit_killable().\n" "\n" "\n" - "I wonder if it is not dropped because it implicitly protects something =\n" - "else.\n" + "I wonder if it is not dropped because it implicitly protects something else.\n" "May be simply concurrent accesses to the superblock?\n" "\n" - "=46rederic.\n" + "Frederic.\n" "\n" "\n" "> \tIngo\n" - ">=20\n" + "> \n" "> -------------->\n" - "> From 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 200=\n" - "1\n" + "> From 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 2001\n" "> From: Ingo Molnar <mingo@elte.hu>\n" "> Date: Wed, 14 May 2008 17:31:41 +0200\n" "> Subject: [PATCH] remove the BKL: restructure NFS code\n" - ">=20\n" + "> \n" "> the naked schedule() in rpc_wait_bit_killable() caused the BKL to\n" "> be auto-dropped in the past.\n" - ">=20\n" + "> \n" "> avoid the immediate hang in such code. Note that this still leaves\n" "> some other locking dependencies to be sorted out in the NFS code.\n" - ">=20\n" + "> \n" "> Signed-off-by: Ingo Molnar <mingo@elte.hu>\n" "> ---\n" "> net/sunrpc/sched.c | 6 ++++++\n" "> 1 files changed, 6 insertions(+), 0 deletions(-)\n" - ">=20\n" + "> \n" "> diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c\n" "> index 6eab9bf..e12e571 100644\n" "> --- a/net/sunrpc/sched.c\n" "> +++ b/net/sunrpc/sched.c\n" "> @@ -224,9 +224,15 @@ EXPORT_SYMBOL_GPL(rpc_destroy_wait_queue);\n" - "> =20\n" + "> \n" "> static int rpc_wait_bit_killable(void *word)\n" "> {\n" - "> +\tint bkl =3D kernel_locked();\n" + "> +\tint bkl = kernel_locked();\n" "> +\n" "> \tif (fatal_signal_pending(current))\n" "> \t\treturn -ERESTARTSYS;\n" @@ -291,6 +266,6 @@ "\n" "> \treturn 0;\n" "> }\n" - > =20 + > -4a00c428903d430ed9120248c77e5dba1de5dc51fc24d72a1f16cb1d8b4c4d60 +3dc9a97d7ffe9cb4a31c6bb46458027b5c48a5712709da778ec0a43be5e57be6
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.