From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Marc Dietrich <Marc.Dietrich@ap.physik.uni-giessen.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Neil Brown <neilb@suse.de>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net,
Johannes Berg <johannes@sipsolutions.net>,
Oleg Nesterov <oleg@tv-sign.ru>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: 2.6.23-rc1-mm2
Date: Mon, 06 Aug 2007 12:24:05 -0400 [thread overview]
Message-ID: <1186417445.6616.23.camel@localhost> (raw)
In-Reply-To: <200708061305.37208.marc.dietrich@ap.physik.uni-giessen.de>
[-- Attachment #1: Type: text/plain, Size: 4592 bytes --]
On Mon, 2007-08-06 at 13:05 +0200, Marc Dietrich wrote:
> Hi,
>
> Am Monday 06 August 2007 08:24 schrieb Johannes Berg:
> > On Fri, 2007-08-03 at 21:21 +0400, Oleg Nesterov wrote:
> > > To avoid a possible confusion: it is still OK if work->func() flushes
> > > its own workqueue, so strictly speaking this trace is false positive,
> > > but it would be very nice if we can get rid of this practice.
> >
> > I just had a thought: we could get rid of this warning by using a
> > read-lock here. That way, flushing from within a work function (which
> > would be seen as read-after-read recursive lock) won't trigger this
> > warning. Patch below. This would, however, also get rid of any warnings
> > for run_workqueue recursion. Which again we may or may not want, the
> > code inidicates that it should be allowed up to a depth of three.
> >
> > However, the question whether we should allow flush_workqueue from
> > within a struct work is mainly an API policy issue; it doesn't hurt to
> > flush a workqueue from within a work, but it is probably nearer the
> > intent to use targeted cancel_work_sync() or such. OTOH, one could
> > imagine situations where multiple different work structs are on that
> > workqueue belonging to the same subsystem and then the general
> > flush_scheduled_work() call is the only way to guarantee nothing is on
> > scheduled at a given point... I don't feel qualified to make the
> > decision for or against allowing this use of the API at this point.
> >
> > Marc, do you have an easy way to trigger this warning? Could you verify
> > that it goes away with the patch below applied?
>
> just booting into X is enough.
>
> I applied the patch, but now I get:
>
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.23-rc1-mm2 #4
> ---------------------------------
> inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> (rpc_credcache_lock){-+..}, at: [<c01dc487>] _atomic_dec_and_lock+0x17/0x60
> {softirq-on-W} state was registered at:
> [<c013e870>] __lock_acquire+0x650/0x1030
> [<c013f2b1>] lock_acquire+0x61/0x80
> [<c02db9ac>] _spin_lock+0x2c/0x40
> [<c01dc487>] _atomic_dec_and_lock+0x17/0x60
> [<dced55fd>] put_rpccred+0x5d/0x100 [sunrpc]
> [<dced56c1>] rpcauth_unbindcred+0x21/0x60 [sunrpc]
> [<dced3fd4>] a0 [sunrpc]
> [<dcecefe0>] rpc_call_sync+0x30/0x40 [sunrpc]
> [<dcedc73b>] rpcb_register+0xdb/0x180 [sunrpc]
> [<dced65b3>] svc_register+0x93/0x160 [sunrpc]
> [<dced6ebe>] __svc_create+0x1ee/0x220 [sunrpc]
> [<dced7053>] svc_create+0x13/0x20 [sunrpc]
> [<dcf6d722>] nfs_callback_up+0x82/0x120 [nfs]
> [<dcf48f36>] nfs_get_client+0x176/0x390 [nfs]
> [<dcf49181>] nfs4_set_client+0x31/0x190 [nfs]
> [<dcf49983>] nfs4_create_server+0x63/0x3b0 [nfs]
> [<dcf52426>] nfs4_get_sb+0x346/0x5b0 [nfs]
> [<c017b444>] vfs_kern_mount+0x94/0x110
> [<c0190a62>] do_mount+0x1f2/0x7d0
> [<c01910a6>] sys_mount+0x66/0xa0
> [<c0104046>] syscall_call+0x7/0xb
> [<ffffffff>] 0xffffffff
> irq event stamp: 5277830
> hardirqs last enabled at (5277830): [<c017530a>] kmem_cache_free+0x8a/0xc0
> hardirqs last disabled at (5277829): [<c01752d2>] kmem_cache_free+0x52/0xc0
> softirqs last enabled at (5277798): [<c0124173>] __do_softirq+0xa3/0xc0
> softirqs last disabled at (5277817): [<c01241d7>] do_softirq+0x47/0x50
>
> other info that might help us debug this:
> no locks held by swapper/0.
>
> stack backtrace:
> [<c0104fda>] show_trace_log_lvl+0x1a/0x30
> [<c0105c02>] show_trace+0x12/0x20
> [<c0105d15>] dump_stack+0x15/0x20
> [<c013ccc3>] print_usage_bug+0x153/0x160
> [<c013d8b9>] mark_lock+0x449/0x620
> [<c013e824>] __lock_acquire+0x604/0x1030
> [<c013f2b1>] lock_acquire+0x61/0x80
> [<c02db9ac>] _spin_lock+0x2c/0x40
> [<c01dc487>] _atomic_dec_and_lock+0x17/0x60
> [<dced55fd>] put_rpccred+0x5d/0x100 [sunrpc]
> [<dcf6bf83>] nfs_free_delegation_callback+0x13/0x20 [nfs]
> [<c012f9ea>] __rcu_process_callbacks+0x6a/0x1c0
> [<c012fb52>] rcu_process_callbacks+0x12/0x30
> [<c0124218>] tasklet_action+0x38/0x80
> [<c0124125>] __do_softirq+0x55/0xc0
> [<c01241d7>] do_softirq+0x47/0x50
> [<c0124605>] irq_exit+0x35/0x40
> [<c0112463>] smp_apic_timer_interrupt+0x43/0x80
> [<c0104a77>] apic_timer_interrupt+0x33/0x38
> [<c02690df>] cpuidle_idle_call+0x6f/0x90
> [<c01023c3>] cpu_idle+0x43/0x70
> [<c02d8c27>] rest_init+0x47/0x50
> [<c03bcb6a>] start_kernel+0x22a/0x2b0
> [<00000000>] 0x0
> =======================
That is a different matter. I assume this patch should suffice to fix
the above problem.
Trond
[-- Attachment #2: linux-2.6.23-005-dont_call_rpc_putcred_from_rcu.dif --]
[-- Type: message/rfc822, Size: 2128 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: No Subject
Date: Mon, 6 Aug 2007 12:18:34 -0400
Message-ID: <1186417445.6616.24.camel@localhost>
Doing so would require us to introduce bh-safe locks into put_rpccred().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/delegation.c | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 20ac403..c55a761 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -20,10 +20,8 @@
#include "delegation.h"
#include "internal.h"
-static void nfs_free_delegation(struct nfs_delegation *delegation)
+static void nfs_do_free_delegation(struct nfs_delegation *delegation)
{
- if (delegation->cred)
- put_rpccred(delegation->cred);
kfree(delegation);
}
@@ -31,7 +29,18 @@ static void nfs_free_delegation_callback(struct rcu_head *head)
{
struct nfs_delegation *delegation = container_of(head, struct nfs_delegation, rcu);
- nfs_free_delegation(delegation);
+ nfs_do_free_delegation(delegation);
+}
+
+static void nfs_free_delegation(struct nfs_delegation *delegation)
+{
+ struct rpc_cred *cred;
+
+ cred = rcu_dereference(delegation->cred);
+ rcu_assign_pointer(delegation->cred, NULL);
+ call_rcu(&delegation->rcu, nfs_free_delegation_callback);
+ if (cred)
+ put_rpccred(cred);
}
static int nfs_delegation_claim_locks(struct nfs_open_context *ctx, struct nfs4_state *state)
@@ -166,7 +175,7 @@ static int nfs_do_return_delegation(struct inode *inode, struct nfs_delegation *
int res = 0;
res = nfs4_proc_delegreturn(inode, delegation->cred, &delegation->stateid);
- call_rcu(&delegation->rcu, nfs_free_delegation_callback);
+ nfs_free_delegation(delegation);
return res;
}
@@ -448,7 +457,7 @@ restart:
spin_unlock(&clp->cl_lock);
rcu_read_unlock();
if (delegation != NULL)
- call_rcu(&delegation->rcu, nfs_free_delegation_callback);
+ nfs_free_delegation(delegation);
goto restart;
}
rcu_read_unlock();
[-- Attachment #3: Type: text/plain, Size: 315 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
[-- Attachment #4: Type: text/plain, Size: 140 bytes --]
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Marc Dietrich <Marc.Dietrich@ap.physik.uni-giessen.de>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Oleg Nesterov <oleg@tv-sign.ru>,
Andrew Morton <akpm@linux-foundation.org>,
Neil Brown <neilb@suse.de>,
nfs@lists.sourceforge.net, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [NFS] 2.6.23-rc1-mm2
Date: Mon, 06 Aug 2007 12:24:05 -0400 [thread overview]
Message-ID: <1186417445.6616.23.camel@localhost> (raw)
In-Reply-To: <200708061305.37208.marc.dietrich@ap.physik.uni-giessen.de>
[-- Attachment #1: Type: text/plain, Size: 4592 bytes --]
On Mon, 2007-08-06 at 13:05 +0200, Marc Dietrich wrote:
> Hi,
>
> Am Monday 06 August 2007 08:24 schrieb Johannes Berg:
> > On Fri, 2007-08-03 at 21:21 +0400, Oleg Nesterov wrote:
> > > To avoid a possible confusion: it is still OK if work->func() flushes
> > > its own workqueue, so strictly speaking this trace is false positive,
> > > but it would be very nice if we can get rid of this practice.
> >
> > I just had a thought: we could get rid of this warning by using a
> > read-lock here. That way, flushing from within a work function (which
> > would be seen as read-after-read recursive lock) won't trigger this
> > warning. Patch below. This would, however, also get rid of any warnings
> > for run_workqueue recursion. Which again we may or may not want, the
> > code inidicates that it should be allowed up to a depth of three.
> >
> > However, the question whether we should allow flush_workqueue from
> > within a struct work is mainly an API policy issue; it doesn't hurt to
> > flush a workqueue from within a work, but it is probably nearer the
> > intent to use targeted cancel_work_sync() or such. OTOH, one could
> > imagine situations where multiple different work structs are on that
> > workqueue belonging to the same subsystem and then the general
> > flush_scheduled_work() call is the only way to guarantee nothing is on
> > scheduled at a given point... I don't feel qualified to make the
> > decision for or against allowing this use of the API at this point.
> >
> > Marc, do you have an easy way to trigger this warning? Could you verify
> > that it goes away with the patch below applied?
>
> just booting into X is enough.
>
> I applied the patch, but now I get:
>
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.23-rc1-mm2 #4
> ---------------------------------
> inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> (rpc_credcache_lock){-+..}, at: [<c01dc487>] _atomic_dec_and_lock+0x17/0x60
> {softirq-on-W} state was registered at:
> [<c013e870>] __lock_acquire+0x650/0x1030
> [<c013f2b1>] lock_acquire+0x61/0x80
> [<c02db9ac>] _spin_lock+0x2c/0x40
> [<c01dc487>] _atomic_dec_and_lock+0x17/0x60
> [<dced55fd>] put_rpccred+0x5d/0x100 [sunrpc]
> [<dced56c1>] rpcauth_unbindcred+0x21/0x60 [sunrpc]
> [<dced3fd4>] a0 [sunrpc]
> [<dcecefe0>] rpc_call_sync+0x30/0x40 [sunrpc]
> [<dcedc73b>] rpcb_register+0xdb/0x180 [sunrpc]
> [<dced65b3>] svc_register+0x93/0x160 [sunrpc]
> [<dced6ebe>] __svc_create+0x1ee/0x220 [sunrpc]
> [<dced7053>] svc_create+0x13/0x20 [sunrpc]
> [<dcf6d722>] nfs_callback_up+0x82/0x120 [nfs]
> [<dcf48f36>] nfs_get_client+0x176/0x390 [nfs]
> [<dcf49181>] nfs4_set_client+0x31/0x190 [nfs]
> [<dcf49983>] nfs4_create_server+0x63/0x3b0 [nfs]
> [<dcf52426>] nfs4_get_sb+0x346/0x5b0 [nfs]
> [<c017b444>] vfs_kern_mount+0x94/0x110
> [<c0190a62>] do_mount+0x1f2/0x7d0
> [<c01910a6>] sys_mount+0x66/0xa0
> [<c0104046>] syscall_call+0x7/0xb
> [<ffffffff>] 0xffffffff
> irq event stamp: 5277830
> hardirqs last enabled at (5277830): [<c017530a>] kmem_cache_free+0x8a/0xc0
> hardirqs last disabled at (5277829): [<c01752d2>] kmem_cache_free+0x52/0xc0
> softirqs last enabled at (5277798): [<c0124173>] __do_softirq+0xa3/0xc0
> softirqs last disabled at (5277817): [<c01241d7>] do_softirq+0x47/0x50
>
> other info that might help us debug this:
> no locks held by swapper/0.
>
> stack backtrace:
> [<c0104fda>] show_trace_log_lvl+0x1a/0x30
> [<c0105c02>] show_trace+0x12/0x20
> [<c0105d15>] dump_stack+0x15/0x20
> [<c013ccc3>] print_usage_bug+0x153/0x160
> [<c013d8b9>] mark_lock+0x449/0x620
> [<c013e824>] __lock_acquire+0x604/0x1030
> [<c013f2b1>] lock_acquire+0x61/0x80
> [<c02db9ac>] _spin_lock+0x2c/0x40
> [<c01dc487>] _atomic_dec_and_lock+0x17/0x60
> [<dced55fd>] put_rpccred+0x5d/0x100 [sunrpc]
> [<dcf6bf83>] nfs_free_delegation_callback+0x13/0x20 [nfs]
> [<c012f9ea>] __rcu_process_callbacks+0x6a/0x1c0
> [<c012fb52>] rcu_process_callbacks+0x12/0x30
> [<c0124218>] tasklet_action+0x38/0x80
> [<c0124125>] __do_softirq+0x55/0xc0
> [<c01241d7>] do_softirq+0x47/0x50
> [<c0124605>] irq_exit+0x35/0x40
> [<c0112463>] smp_apic_timer_interrupt+0x43/0x80
> [<c0104a77>] apic_timer_interrupt+0x33/0x38
> [<c02690df>] cpuidle_idle_call+0x6f/0x90
> [<c01023c3>] cpu_idle+0x43/0x70
> [<c02d8c27>] rest_init+0x47/0x50
> [<c03bcb6a>] start_kernel+0x22a/0x2b0
> [<00000000>] 0x0
> =======================
That is a different matter. I assume this patch should suffice to fix
the above problem.
Trond
[-- Attachment #2: linux-2.6.23-005-dont_call_rpc_putcred_from_rcu.dif --]
[-- Type: message/rfc822, Size: 2128 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: No Subject
Date: Mon, 6 Aug 2007 12:18:34 -0400
Message-ID: <1186417445.6616.24.camel@localhost>
Doing so would require us to introduce bh-safe locks into put_rpccred().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/delegation.c | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 20ac403..c55a761 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -20,10 +20,8 @@
#include "delegation.h"
#include "internal.h"
-static void nfs_free_delegation(struct nfs_delegation *delegation)
+static void nfs_do_free_delegation(struct nfs_delegation *delegation)
{
- if (delegation->cred)
- put_rpccred(delegation->cred);
kfree(delegation);
}
@@ -31,7 +29,18 @@ static void nfs_free_delegation_callback(struct rcu_head *head)
{
struct nfs_delegation *delegation = container_of(head, struct nfs_delegation, rcu);
- nfs_free_delegation(delegation);
+ nfs_do_free_delegation(delegation);
+}
+
+static void nfs_free_delegation(struct nfs_delegation *delegation)
+{
+ struct rpc_cred *cred;
+
+ cred = rcu_dereference(delegation->cred);
+ rcu_assign_pointer(delegation->cred, NULL);
+ call_rcu(&delegation->rcu, nfs_free_delegation_callback);
+ if (cred)
+ put_rpccred(cred);
}
static int nfs_delegation_claim_locks(struct nfs_open_context *ctx, struct nfs4_state *state)
@@ -166,7 +175,7 @@ static int nfs_do_return_delegation(struct inode *inode, struct nfs_delegation *
int res = 0;
res = nfs4_proc_delegreturn(inode, delegation->cred, &delegation->stateid);
- call_rcu(&delegation->rcu, nfs_free_delegation_callback);
+ nfs_free_delegation(delegation);
return res;
}
@@ -448,7 +457,7 @@ restart:
spin_unlock(&clp->cl_lock);
rcu_read_unlock();
if (delegation != NULL)
- call_rcu(&delegation->rcu, nfs_free_delegation_callback);
+ nfs_free_delegation(delegation);
goto restart;
}
rcu_read_unlock();
next prev parent reply other threads:[~2007-08-06 16:24 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-01 6:09 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 6:25 ` 2.6.23-rc1-mm2 Paul Mundt
2007-08-01 7:58 ` 2.6.23-rc1-mm2 Mike Frysinger
2007-08-01 8:10 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 13:45 ` 2.6.23-rc1-mm2 Christoph Hellwig
2007-08-01 13:57 ` 2.6.23-rc1-mm2 Jason Wessel
2007-08-01 8:15 ` 2.6.23-rc1-mm2 Paul Mundt
2007-08-01 9:04 ` 2.6.23-rc1-mm2 Mike Frysinger
2007-08-01 12:22 ` 2.6.23-rc1-mm2 Jason Wessel
2007-08-01 7:36 ` 2.6.23-rc1-mm2 (vm-dont-run-touch_buffer-during-buffercache-lookups.patch) Eric St-Laurent
2007-08-01 7:46 ` Andrew Morton
2007-08-01 8:04 ` Eric St-Laurent
2007-08-01 8:30 ` Andrew Morton
2007-08-01 8:02 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-01 8:02 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-01 8:13 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 8:13 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 8:16 ` 2.6.23-rc1-mm2 Ingo Molnar
2007-08-01 8:16 ` 2.6.23-rc1-mm2 Ingo Molnar
2007-08-01 10:23 ` 2.6.23-rc1-mm2 Jiri Kosina
2007-08-02 9:47 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-02 14:20 ` [linux-usb-devel] 2.6.23-rc1-mm2 Alan Stern
2007-08-02 14:26 ` Jiri Kosina
2007-08-02 14:32 ` Mariusz Kozlowski
2007-08-01 10:32 ` 2.6.23-rc1-mm2 Paul Mackerras
2007-08-01 10:32 ` 2.6.23-rc1-mm2 Paul Mackerras
2007-08-02 10:14 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-02 10:14 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-03 9:39 ` 2.6.23-rc1-mm2 Kumar Gala
2007-08-03 9:39 ` 2.6.23-rc1-mm2 Kumar Gala
2007-08-06 19:12 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 19:12 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 19:10 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 19:10 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-01 16:36 ` 2.6.23-rc1-mm2 Greg KH
2007-08-01 16:36 ` 2.6.23-rc1-mm2 Greg KH
2007-08-06 19:08 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 19:08 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 19:34 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-06 19:34 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-06 21:25 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 21:25 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 22:34 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-06 22:34 ` 2.6.23-rc1-mm2 Mariusz Kozlowski
2007-08-06 23:12 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-06 23:12 ` 2.6.23-rc1-mm2 Segher Boessenkool
2007-08-01 9:34 ` [PATCH] prevent SSB compilation on s390 part 2 Heiko Carstens
2007-08-01 12:24 ` John W. Linville
2007-08-01 14:43 ` Heiko Carstens
2007-08-01 14:54 ` Michael Buesch
2007-08-01 10:33 ` unionfs compile error ( Re: 2.6.23-rc1-mm2 ) Gabriel C
2007-08-01 17:22 ` Andrew Morton
2007-08-01 17:27 ` Josef Sipek
2007-08-02 16:29 ` Erez Zadok
2007-08-01 17:35 ` Gabriel C
2007-08-01 10:56 ` 2.6.23-rc1-mm2 Gabriel C
2007-08-01 17:26 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 17:39 ` 2.6.23-rc1-mm2 Gabriel C
2007-08-01 11:16 ` [PATCH] fix slown down printk on boot compile error Heiko Carstens
2007-08-01 16:32 ` Randy Dunlap
2007-08-01 13:01 ` drivers/scsi/advansys.c compile error ( Re: 2.6.23-rc1-mm2 ) Gabriel C
2007-08-01 13:39 ` [PATCH] drivers/scsi/advansys.c: fix advansys_board_found compile error Eugene Teo
2007-08-01 13:54 ` Gabriel C
2007-08-01 13:55 ` Matthew Wilcox
2007-08-01 14:27 ` Gabriel C
2007-08-01 14:32 ` Matthew Wilcox
2007-08-01 14:46 ` Gabriel C
2007-08-01 14:23 ` [PATCH -mm] Fix defined but not used warning in drivers/kvm/vmx.c Gabriel C
2007-08-01 18:35 ` Avi Kivity
2007-08-01 15:19 ` [PATCH -mm] Fix a section mismatch warning Gabriel C
2007-08-01 20:13 ` 2.6.23-rc1-mm2 (checks-for-80wire-cable-use-in-pata_via) Laurent Riffard
2007-08-01 20:30 ` 2.6.23-rc1-mm2 Valdis.Kletnieks
2007-08-01 20:40 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 20:52 ` 2.6.23-rc1-mm2 Torsten Kaiser
2007-08-01 21:17 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 21:17 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-01 23:40 ` 2.6.23-rc1-mm2 Mel Gorman
2007-08-02 4:38 ` 2.6.23-rc1-mm2 Torsten Kaiser
2007-08-02 14:01 ` 2.6.23-rc1-mm2 Andy Whitcroft
2007-08-02 17:44 ` 2.6.23-rc1-mm2 Torsten Kaiser
2007-08-01 23:40 ` INOTIFY=n , AUDIT*=y compile error Gabriel C
2007-08-01 23:59 ` [PATCH -mm] linux-audit list is subscribers-only Gabriel C
2007-08-02 1:30 ` Randy Dunlap
2007-08-02 13:11 ` [PATCH -mm] Fix section mismatch warnings in sound/pci/hda/ Gabriel C
2007-08-02 13:24 ` Takashi Iwai
2007-08-02 16:32 ` Sam Ravnborg
2007-08-02 17:17 ` Takashi Iwai
2007-08-02 17:31 ` 2.6.23-rc1-mm2: Fix crash in sysfs_hash_and_remove Rafael J. Wysocki
2007-08-02 17:34 ` Tejun Heo
2007-08-02 18:19 ` Eric W. Biederman
2007-08-03 11:00 ` 2.6.23-rc1-mm2 Marc Dietrich
2007-08-03 16:38 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-03 16:38 ` 2.6.23-rc1-mm2 Andrew Morton
2007-08-03 17:03 ` 2.6.23-rc1-mm2 Trond Myklebust
2007-08-03 17:03 ` [NFS] 2.6.23-rc1-mm2 Trond Myklebust
2007-08-03 17:21 ` 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-03 17:21 ` [NFS] 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-06 6:24 ` 2.6.23-rc1-mm2 Johannes Berg
2007-08-06 6:24 ` [NFS] 2.6.23-rc1-mm2 Johannes Berg
2007-08-06 10:53 ` 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-06 10:53 ` [NFS] 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-06 10:58 ` 2.6.23-rc1-mm2 Johannes Berg
2007-08-06 10:58 ` [NFS] 2.6.23-rc1-mm2 Johannes Berg
2007-08-06 11:05 ` 2.6.23-rc1-mm2 Marc Dietrich
2007-08-06 11:05 ` [NFS] 2.6.23-rc1-mm2 Marc Dietrich
2007-08-06 11:13 ` 2.6.23-rc1-mm2 Johannes Berg
2007-08-06 11:13 ` [NFS] 2.6.23-rc1-mm2 Johannes Berg
2007-08-06 16:24 ` Trond Myklebust [this message]
2007-08-06 16:24 ` Trond Myklebust
2007-08-07 12:09 ` Marc Dietrich
2007-08-07 21:08 ` 2.6.23-rc1-mm2 Trond Myklebust
2007-08-07 21:08 ` [NFS] 2.6.23-rc1-mm2 Trond Myklebust
2007-08-07 21:37 ` 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-07 21:37 ` [NFS] 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-07 22:05 ` 2.6.23-rc1-mm2 Trond Myklebust
2007-08-07 22:05 ` [NFS] 2.6.23-rc1-mm2 Trond Myklebust
2007-08-07 22:20 ` 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-07 22:20 ` [NFS] 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-07 23:08 ` 2.6.23-rc1-mm2 Trond Myklebust
2007-08-07 23:08 ` [NFS] 2.6.23-rc1-mm2 Trond Myklebust
2007-08-07 23:14 ` 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-07 23:14 ` [NFS] 2.6.23-rc1-mm2 Oleg Nesterov
2007-08-08 21:31 ` 2.6.23-rc1-mm2: MMC_ARMMMCI compile error Adrian Bunk
2007-08-09 12:03 ` Pierre Ossman
2007-08-14 21:21 ` [-mm patch] make pm3fb_init() static again Adrian Bunk
2007-08-14 21:21 ` [-mm patch] fs/reiser4/plugin/: make 3 functions static Adrian Bunk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1186417445.6616.23.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--cc=Marc.Dietrich@ap.physik.uni-giessen.de \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
--cc=oleg@tv-sign.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.