Andrew Morton wrote, On 12/15/2007 11:48 AM:
On Sat, 15 Dec 2007 14:10:21 +0800 Herbert Xu [EMAIL PROTECTED] wrote:
On Fri, Dec 14, 2007 at 09:44:18PM -0800, Andrew Morton wrote:
That sounds like a bug in mutex_trylock() to me.
I was relying on
On Sun, Dec 16, 2007 at 07:06:41PM +0100, Jarek Poplawski wrote:
It seemed to exist a few days ago:
http://kerneltrap.org/mailarchive/linux-netdev/2007/12/4/473123
Btw., I don't know which of the patches: Eric's or yours will be chosen,
but, IMHO, there is no reason to remove
On Mon, Dec 17, 2007 at 09:26:32AM +0800, Herbert Xu wrote:
On Sun, Dec 16, 2007 at 07:06:41PM +0100, Jarek Poplawski wrote:
It seemed to exist a few days ago:
http://kerneltrap.org/mailarchive/linux-netdev/2007/12/4/473123
Btw., I don't know which of the patches: Eric's or yours will
On Mon, Dec 17, 2007 at 08:26:01AM +0100, Jarek Poplawski wrote:
Btw. #2: David Miller gave this example of ASSERT_RTNL use:
ASSERT_RTNL();
page = alloc_page(GFP_KERNEL);
But isn't there a debugging duplication: it seems alloc_page() is used
in so many places and this check
On Mon, Dec 17, 2007 at 08:26:01AM +0100, Jarek Poplawski wrote:
On Mon, Dec 17, 2007 at 09:26:32AM +0800, Herbert Xu wrote:
...
I retract what I've said in this thread and continue to oppose
this change without a might_sleep.
...
So, I think using might_sleep() explicitly would be much more
On Mon, Dec 17, 2007 at 03:31:33PM +0800, Herbert Xu wrote:
On Mon, Dec 17, 2007 at 08:26:01AM +0100, Jarek Poplawski wrote:
Btw. #2: David Miller gave this example of ASSERT_RTNL use:
ASSERT_RTNL();
page = alloc_page(GFP_KERNEL);
But isn't there a debugging duplication:
On Sat, 15 Dec 2007 14:10:21 +0800 Herbert Xu [EMAIL PROTECTED] wrote:
On Fri, Dec 14, 2007 at 09:44:18PM -0800, Andrew Morton wrote:
That sounds like a bug in mutex_trylock() to me.
I was relying on
http://kerneltrap.org/mailarchive/linux-netdev/2007/9/28/325129
which seems
On Sat, Dec 15, 2007 at 02:48:10AM -0800, Andrew Morton wrote:
When Eric said
Way way deep in mutex debugging on the slowpath there is a unreadable
and incomprehensible WARN_ON in muxtex_trylock that will trigger if
you have 10 tons of debugging turned on, and you are in,
interrupt
From: Andrew Morton [EMAIL PROTECTED]
Date: Fri, 14 Dec 2007 21:44:18 -0800
That sounds like a bug in mutex_trylock() to me.
I disagree, I have yet to see a legitimate case where doing a trylock
on a mutex lock didn't turn out to be a bug when performed in an
atomic context.
This is
From: Herbert Xu [EMAIL PROTECTED]
Date: Sat, 15 Dec 2007 21:10:16 +0800
On Sat, Dec 15, 2007 at 02:48:10AM -0800, Andrew Morton wrote:
Now as a separate issue we (ie: you) need to work out what _other_ things
you want ASSERT_RTNL to check apart from rtnl must be held.
Since we have now
On Sat, Dec 15, 2007 at 09:44:29PM -0800, David Miller wrote:
Such situations (ASSERT_RTNL() in atomic context) have always
been bugs though, and that continues to be true and I think
the check should be added somehow.
OK once I've fixed the set_multicast path I'll do an audit of
the existing
On Fri, 14 Dec 2007 16:10:44 +0800 Herbert Xu [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
diff -puN
drivers/net/cxgb3/cxgb3_main.c~net-use-mutex_is_locked-for-assert_rtnl
drivers/net/cxgb3/cxgb3_main.c
--- a/drivers/net/cxgb3/cxgb3_main.c~net-use-mutex_is_locked-for-assert_rtnl
[EMAIL PROTECTED] wrote:
diff -puN
drivers/net/cxgb3/cxgb3_main.c~net-use-mutex_is_locked-for-assert_rtnl
drivers/net/cxgb3/cxgb3_main.c
--- a/drivers/net/cxgb3/cxgb3_main.c~net-use-mutex_is_locked-for-assert_rtnl
+++ a/drivers/net/cxgb3/cxgb3_main.c
@@ -2191,7 +2191,7 @@ static void
On Fri, Dec 14, 2007 at 12:22:09AM -0800, Andrew Morton wrote:
I don't see how it could warn about that. Nor should it - one might want
to check that rtnl_lock is held inside preempt_disable() or spin_lock or
whatever.
It might make sense to warn if ASSERT_RTNL is called in in_interrupt()
I agree with this. IIRC I removed some ASSERT_RTNL()s in the wireless
code (or maybe it was only during testing patches) where we had a
function that required only the rtnl to be held but in certain contexts
was called from within an RCU section.
Please point me to the actual code so I
On Fri, Dec 14, 2007 at 01:37:40PM +0100, Johannes Berg wrote:
I agree with this. IIRC I removed some ASSERT_RTNL()s in the wireless
code (or maybe it was only during testing patches) where we had a
function that required only the rtnl to be held but in certain contexts
was called from
I don't see how it could warn about that. Nor should it - one might want
to check that rtnl_lock is held inside preempt_disable() or spin_lock or
whatever.
I agree with this. IIRC I removed some ASSERT_RTNL()s in the wireless
code (or maybe it was only during testing patches) where we had a
From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 14 Dec 2007 16:30:37 +0800
On Fri, Dec 14, 2007 at 12:22:09AM -0800, Andrew Morton wrote:
I don't see how it could warn about that. Nor should it - one might want
to check that rtnl_lock is held inside preempt_disable() or spin_lock or
From: [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 16:02:36 -0800
From: Andrew Morton [EMAIL PROTECTED]
ASSERT_RTNL() uses mutex_trylock(), but it's better to use mutex_is_locked().
Make that change, and remove rtnl_trylock() altogether.
(not tested yet!)
Cc: David S. Miller [EMAIL
On Fri, 14 Dec 2007 11:15:14 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 14 Dec 2007 16:30:37 +0800
On Fri, Dec 14, 2007 at 12:22:09AM -0800, Andrew Morton wrote:
I don't see how it could warn about that. Nor should it - one might
On Fri, Dec 14, 2007 at 03:11:36PM -0800, Andrew Morton wrote:
I don't believe that ASSERT_RTNL() presently warns when called from atomic
contexts. If it does then I missed it.
It does when mutex debugging is enabled.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu
On Sat, 15 Dec 2007 12:18:27 +0800 Herbert Xu [EMAIL PROTECTED] wrote:
On Fri, Dec 14, 2007 at 03:11:36PM -0800, Andrew Morton wrote:
I don't believe that ASSERT_RTNL() presently warns when called from atomic
contexts. If it does then I missed it.
It does when mutex debugging is
On Fri, Dec 14, 2007 at 09:44:18PM -0800, Andrew Morton wrote:
That sounds like a bug in mutex_trylock() to me.
I was relying on
http://kerneltrap.org/mailarchive/linux-netdev/2007/9/28/325129
which seems to be a bogus claim now that I actually look at the
source code. So in that
From: Andrew Morton [EMAIL PROTECTED]
ASSERT_RTNL() uses mutex_trylock(), but it's better to use mutex_is_locked().
Make that change, and remove rtnl_trylock() altogether.
(not tested yet!)
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
24 matches
Mail list logo
