diff for duplicates of <20090416085153.GC9813@elte.hu> diff --git a/a/1.txt b/N1/1.txt index 990335d..19c3a38 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,47 +2,38 @@ * Frederic Weisbecker <fweisbec@gmail.com> wrote: > 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 = -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 tr= -ying +> > > >> > 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 Igo= -r 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 = -the write lock -> > > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_trunca= -te_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 @@ -53,81 +44,68 @@ 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 fix= -es -> > > > from Frederic in tip:core/kill-the-BKL branch, have you picked = -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 late= -st +> > > > 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= --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 i= -s=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 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= -=2Ecom> ----- -> >=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 depend= -ency -> >=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/= -0x3c -> >=20 +> > (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x3c +> > > > but task is already holding lock: -> > (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+= -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 @@ -138,7 +116,7 @@ ency > > [<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 @@ -160,12 +138,12 @@ ency > > [<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. The problem seem to be that this NFS call context: @@ -192,25 +170,24 @@ The problem seem to be that this NFS call context: [<00000000004ed2a4>] compat_sys_mount+0x224/0x274 [<0000000000406154>] linux_sparc_syscall32+0x34/0x40 -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. -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. -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(). Ingo --------------> -=46rom 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 200= -1 -=46rom: Ingo Molnar <mingo@elte.hu> +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 @@ -230,10 +207,10 @@ 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; @@ -244,4 +221,3 @@ index 6eab9bf..e12e571 100644 + lock_kernel(); return 0; } -=20 diff --git a/a/content_digest b/N1/content_digest index 1685631..2e0ce1b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -23,47 +23,38 @@ "* Frederic Weisbecker <fweisbec@gmail.com> wrote:\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 Weisbecker =\n" - "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 tr=\n" - "ying\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 =\n" - "to 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 Igo=\n" - "r 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 =\n" - "the write lock\n" - "> > > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_trunca=\n" - "te_file\n" - "> > > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock once =\n" - "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" @@ -74,81 +65,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 fix=\n" - "es\n" - "> > > > from Frederic in tip:core/kill-the-BKL branch, have you picked =\n" - "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 late=\n" - "st\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=\n" - "-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 i=\n" - "s=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 LKML=\n" - "=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 out=\n" - "=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=\n" - "=2Ecom> -----\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 depend=\n" - "ency\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/=\n" - "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>] sget+=\n" - "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" @@ -159,7 +137,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" @@ -181,12 +159,12 @@ "> > [<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" "\n" "The problem seem to be that this NFS call context:\n" @@ -213,25 +191,24 @@ " [<00000000004ed2a4>] compat_sys_mount+0x224/0x274\n" " [<0000000000406154>] linux_sparc_syscall32+0x34/0x40\n" "\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" + "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" - "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" - "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" "\tIngo\n" "\n" "-------------->\n" - "=46rom 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 200=\n" - "1\n" - "=46rom: Ingo Molnar <mingo@elte.hu>\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" "\n" @@ -251,10 +228,10 @@ "--- 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" @@ -264,7 +241,6 @@ "+\tif (bkl)\n" "+\t\tlock_kernel();\n" " \treturn 0;\n" - " }\n" - =20 + } -31ad261e29052b580a5ef9e01349184a2d734e08d257019055848f914539a2dc +aa462995e3d8d15b994067ca12d4fa708819427e5b5137bac450a128d4bbece6
diff --git a/a/1.txt b/N2/1.txt index 990335d..0916ab4 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -2,47 +2,38 @@ * Frederic Weisbecker <fweisbec@gmail.com> wrote: > 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 = -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 tr= -ying +> > > >> > 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 Igo= -r 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 = -the write lock -> > > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_trunca= -te_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 @@ -53,81 +44,68 @@ 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 fix= -es -> > > > from Frederic in tip:core/kill-the-BKL branch, have you picked = -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 late= -st +> > > > 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= --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 i= -s=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 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= -=2Ecom> ----- -> >=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 depend= -ency -> >=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/= -0x3c -> >=20 +> > (kernel_mutex){+.+.+.}, at: [<00000000006f32dc>] lock_kernel+0x28/0x3c +> > > > but task is already holding lock: -> > (&type->s_umount_key#24/1){+.+.+.}, at: [<00000000004b88a0>] sget+= -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 @@ -138,7 +116,7 @@ ency > > [<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 @@ -160,12 +138,12 @@ ency > > [<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. The problem seem to be that this NFS call context: @@ -192,25 +170,24 @@ The problem seem to be that this NFS call context: [<00000000004ed2a4>] compat_sys_mount+0x224/0x274 [<0000000000406154>] linux_sparc_syscall32+0x34/0x40 -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. -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. -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(). Ingo --------------> -=46rom 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 200= -1 -=46rom: Ingo Molnar <mingo@elte.hu> +>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 @@ -230,10 +207,10 @@ 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; @@ -244,4 +221,3 @@ index 6eab9bf..e12e571 100644 + lock_kernel(); return 0; } -=20 diff --git a/a/content_digest b/N2/content_digest index 1685631..2b40146 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -23,47 +23,38 @@ "* Frederic Weisbecker <fweisbec@gmail.com> wrote:\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 Weisbecker =\n" - "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 tr=\n" - "ying\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 =\n" - "to 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 Igo=\n" - "r 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 =\n" - "the write lock\n" - "> > > >> > =A0 kill-the-BKL/reiserfs: lock only once in reiserfs_trunca=\n" - "te_file\n" - "> > > >> > =A0 kill-the-BKL/reiserfs: only acquire the write lock once =\n" - "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" @@ -74,81 +65,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 fix=\n" - "es\n" - "> > > > from Frederic in tip:core/kill-the-BKL branch, have you picked =\n" - "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 late=\n" - "st\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=\n" - "-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 i=\n" - "s=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 LKML=\n" - "=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 out=\n" - "=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=\n" - "=2Ecom> -----\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 depend=\n" - "ency\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/=\n" - "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>] sget+=\n" - "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" @@ -159,7 +137,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" @@ -181,12 +159,12 @@ "> > [<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" "\n" "The problem seem to be that this NFS call context:\n" @@ -213,25 +191,24 @@ " [<00000000004ed2a4>] compat_sys_mount+0x224/0x274\n" " [<0000000000406154>] linux_sparc_syscall32+0x34/0x40\n" "\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" + "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" - "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" - "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" "\tIngo\n" "\n" "-------------->\n" - "=46rom 352e0d25def53e6b36234e4dc2083ca7f5d712a9 Mon Sep 17 00:00:00 200=\n" - "1\n" - "=46rom: Ingo Molnar <mingo@elte.hu>\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" "\n" @@ -251,10 +228,10 @@ "--- 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" @@ -264,7 +241,6 @@ "+\tif (bkl)\n" "+\t\tlock_kernel();\n" " \treturn 0;\n" - " }\n" - =20 + } -31ad261e29052b580a5ef9e01349184a2d734e08d257019055848f914539a2dc +41a17b72ece7b4cc33b6146ce71475cc33e7e837206cb19e8c21ec293e6882f4
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.