* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-12 18:04 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, Greg KH
In-Reply-To: <200802111724.12416.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
>
> Patch for eHEA memory hotplug support that uses these functions:
> http://www.spinics.net/lists/netdev/msg54484.html
This driver is broken pretty horribly. It won't even compile for a
plain ppc64 kernel:
http://sr71.net/~dave/linux/ehea-is-broken.config
I know it's used for very specific hardware, but this is the symptom of
it not using the proper abstracted interfaces to the VM.
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_main.c:42:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
CC drivers/net/mii.o
make[4]: *** [drivers/net/ehea/ehea_main.o] Error 1
make[4]: *** Waiting for unfinished jobs....
CC drivers/net/ixgb/ixgb_param.o
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:32:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: 'NR_MEM_SECTIONS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: (Each undeclared identifier is reported only once
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: for each function it appears in.)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:575: error: implicit declaration of function 'valid_section_nr'
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_map_vaddr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:606: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_reg_kernel_mr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:655: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
-- Dave
^ permalink raw reply
* Re: Open bugs
From: James Bottomley @ 2008-02-12 17:57 UTC (permalink / raw)
To: Natalie Protasevich
Cc: alsa-devel, bugme-daemon, linux-scsi, netdev, linux-kernel,
linux-ide, akpm
In-Reply-To: <32209efe0802120018r17c38835ud931085e44aafefb@mail.gmail.com>
Added linux-scsi for the SCSI ones
On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
> Hello,
>
> The bugs listed are over a month old, and haven't been addressed yet.
> It would be appreciated if corresponding maintainers identify whether
> the bugs have been fixed, or need to be worked on, and take
> appropriate action.
>
> In most cases, reporters are standing by and ready to provide
> information and necessary testing.
> Thanks!
>
> SCSI======================================================
>
> Problems on booting
> http://bugzilla.kernel.org/show_bug.cgi?id=9621
> Date: 12/22/2007
> Regression
> Summary: The boot stops / hangs on hardware detection of SCSI. I have
> an InitioINI-9X00U/UW
> When I have an usb key sticked in /dev/sba, and run lilo then, then it
> dont boot but give L99 99 99 99 ... error
I think this was fixed by commit
e2d435ea4084022ab88efa74214accb45b1f9e92
Apparently bugzilla email is on the fritz again because this bug report
didn't come across linux-scsi.
> Resetting RAID attached to a FC Switch causes kernel panic and crash
> http://bugzilla.kernel.org/show_bug.cgi?id=9598
> 12/18/2007
> Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
> 8GB Ram, Qlogic FC adapter.
> Summary: Resetting the RAID box causes the X4200 to crash.
This one looks like the usual problem of remove re-add with the SCSI
device model.
> 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
> http://bugzilla.kernel.org/show_bug.cgi?id=8908
> 08/19/2007
> Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
> RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
> RAID Controller.
Since this one never apparently worked it's not a regression but an
enhancement request, isn't it?
However, adding this PCI ID to the driver should be fairly
straightforward. Does anyone know what the actual PCI IDs are?
James
^ permalink raw reply
* Re: e1000e hardware CRC stripping breaks bridging
From: Kok, Auke @ 2008-02-12 17:25 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev, johan.andersson, dsd, jesse.brandeburg
In-Reply-To: <47B19EDE.5020802@gentoo.org>
Daniel Drake wrote:
> Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> stripping enabled by e1000e breaks bridging because sometimes the CRC is
> not stripped:
> https://bugs.gentoo.org/show_bug.cgi?id=209235
>
> Apparently "upstream" are aware but I couldn't find any mails or bug
> reports on this topic.
>
> What's the current status of this issue? Perhaps we should disable
> hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
Jesse figured it out. I just send you a patch to test, can you guys give that a
try and see if it fixes the situation? Johan?
thanks,
Auke
^ permalink raw reply
* Re: e1000e hardware CRC stripping breaks bridging
From: Andy Gospodarek @ 2008-02-12 17:23 UTC (permalink / raw)
To: Johan Andersson; +Cc: Daniel Drake, Auke Kok, netdev
In-Reply-To: <1202824670.26114.20.camel@gentoo-johan.transmode.se>
On Tue, Feb 12, 2008 at 02:57:50PM +0100, Johan Andersson wrote:
> Here is the bug report:
> http://bugzilla.kernel.org/show_bug.cgi?id=9940
>
> /Johan
>
> On Tue, 2008-02-12 at 13:27 +0000, Daniel Drake wrote:
> > Hi,
> >
> > Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> > stripping enabled by e1000e breaks bridging because sometimes the CRC is
> > not stripped:
> > https://bugs.gentoo.org/show_bug.cgi?id=209235
> >
> > Apparently "upstream" are aware but I couldn't find any mails or bug
> > reports on this topic.
> >
> > What's the current status of this issue? Perhaps we should disable
> > hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
> >
> > Thanks,
> > Daniel
This patch, just needs to get reverted:
commit 140a74802894e9db57e5cd77ccff77e590ece5f3
Author: Auke Kok <auke-jan.h.kok@intel.com>
Date: Thu Oct 25 13:57:58 2007 -0700
e1000e: Re-enable SECRC - crc stripping
^ permalink raw reply
* [PATCH][GENETLINK]: Relax dances with genl_lock.
From: Pavel Emelyanov @ 2008-02-12 17:16 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List
The genl_unregister_family() calls the genl_unregister_mc_groups(),
which takes and releases the genl_lock and then locks and releases
this lock itself.
Relax this behavior, all the more so the genl_unregister_mc_groups()
is called from genl_unregister_family() only.
I'm not sure, whether this is 2.6.25 material, but the patch looks
pretty simple. Should I hold it till 2.6.26?
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 150579a..d16929c 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -230,10 +230,8 @@ static void genl_unregister_mc_groups(struct genl_family *family)
{
struct genl_multicast_group *grp, *tmp;
- genl_lock();
list_for_each_entry_safe(grp, tmp, &family->mcast_groups, list)
__genl_unregister_mc_group(family, grp);
- genl_unlock();
}
/**
@@ -396,10 +394,10 @@ int genl_unregister_family(struct genl_family *family)
{
struct genl_family *rc;
- genl_unregister_mc_groups(family);
-
genl_lock();
+ genl_unregister_mc_groups(family);
+
list_for_each_entry(rc, genl_family_chain(family->id), family_list) {
if (family->id != rc->id || strcmp(rc->name, family->name))
continue;
^ permalink raw reply related
* RE: r8169 auto-negotiation problem
From: fgnijuhhu guduggurehug @ 2008-02-12 16:44 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20080203184525.GA12607@electric-eye.fr.zoreil.com>
> fgnijuhhu guduggurehug :
> [...]
>> I already posted my problem and what I did to solve it on
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.
>
> Have you tried anything more recent than a 2.6.18 based kernel ?
No, but if changes were made to the iniatialization of the chipset in the current driver (mine was 2.2LK), this might do the trick. The problem is that the error is rather erratic and unreproducible.
Anyway, how to best upgrade the kernel in debian (without problems, of course)? The problem right now is that every apt-get upgrade reverts the r8169 driver to the old one...
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* Re: [PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.
From: Paul Moore @ 2008-02-12 16:34 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List
In-Reply-To: <47B1C8E4.6010908@openvz.org>
On Tuesday 12 February 2008 11:27:16 am Pavel Emelyanov wrote:
> Currently, if the call to netlbl_domhsh_search succeeds the
> return result will still be NULL.
>
> Fix that, by returning the found entry (if any).
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Good catch, thanks.
Acked-by: Paul Moore <paul.moore@hp.com>
> ---
>
> diff --git a/net/netlabel/netlabel_domainhash.c
> b/net/netlabel/netlabel_domainhash.c index 9a8ea01..fd46231 100644
> --- a/net/netlabel/netlabel_domainhash.c
> +++ b/net/netlabel/netlabel_domainhash.c
> @@ -150,11 +150,11 @@ static struct netlbl_dom_map
> *netlbl_domhsh_search_def(const char *domain) entry =
> netlbl_domhsh_search(domain);
> if (entry == NULL) {
> entry = rcu_dereference(netlbl_domhsh_def);
> - if (entry != NULL && entry->valid)
> - return entry;
> + if (entry != NULL && !entry->valid)
> + entry = NULL;
> }
>
> - return NULL;
> + return entry;
> }
>
> /*
--
paul moore
linux security @ hp
^ permalink raw reply
* [PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.
From: Pavel Emelyanov @ 2008-02-12 16:27 UTC (permalink / raw)
To: David Miller; +Cc: Paul Moore, Linux Netdev List
Currently, if the call to netlbl_domhsh_search succeeds the
return result will still be NULL.
Fix that, by returning the found entry (if any).
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/netlabel/netlabel_domainhash.c b/net/netlabel/netlabel_domainhash.c
index 9a8ea01..fd46231 100644
--- a/net/netlabel/netlabel_domainhash.c
+++ b/net/netlabel/netlabel_domainhash.c
@@ -150,11 +150,11 @@ static struct netlbl_dom_map *netlbl_domhsh_search_def(const char *domain)
entry = netlbl_domhsh_search(domain);
if (entry == NULL) {
entry = rcu_dereference(netlbl_domhsh_def);
- if (entry != NULL && entry->valid)
- return entry;
+ if (entry != NULL && !entry->valid)
+ entry = NULL;
}
- return NULL;
+ return entry;
}
/*
^ permalink raw reply related
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Paul E. McKenney @ 2008-02-12 16:07 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, shemminger, netdev, linux-kernel
In-Reply-To: <20080212085714.GB2582@ff.dom.local>
On Tue, Feb 12, 2008 at 08:57:14AM +0000, Jarek Poplawski wrote:
> On 12-02-2008 02:16, David Miller wrote:
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Mon, 11 Feb 2008 16:59:54 -0800
> >
> > linux-kernel added to CC:, any change to generic kernel infrastructure
> > should be posted there
> >
> >> Eliminate warnings when rcu_assign_pointer is used with unsigned long.
> >> It is reasonable to use RCU with non-pointer values so allow it for general
> >> use. Add a comment to explain the if test.
> >>
> >> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >> ---
> >> include/linux/rcupdate.h | 13 +++++++------
> >> 1 files changed, 7 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >> index 37a642c..c44ac87 100644
> >> --- a/include/linux/rcupdate.h
> >> +++ b/include/linux/rcupdate.h
> >> @@ -172,14 +172,15 @@ struct rcu_head {
> >> * structure after the pointer assignment. More importantly, this
> >> * call documents which pointers will be dereferenced by RCU read-side
> >> * code.
> >> + *
> >> + * If value is the NULL (constant 0), then no barrier is needed.
> >> */
> >>
> >> -#define rcu_assign_pointer(p, v) \
> >> - ({ \
> >> - if (!__builtin_constant_p(v) || \
> >> - ((v) != NULL)) \
> >> - smp_wmb(); \
> >> - (p) = (v); \
> >> +#define rcu_assign_pointer(p, v) \
> >> + ({ \
> >> + if (!(__builtin_constant_p(v) && v)) \
>
> ...But, "If value is the NULL (constant 0)" we have:
>
> if (!(1 && NULL != 0)) ==> if (!(0)) and the barrier is used?!
"All programmers are blind, especially me."
You are right, Jarek. I ran this through gcc, and the following
comes close:
#define rcu_assign_pointer(p, v) \
({ \
if (!__builtin_constant_p(v) || (v)) \
smp_wmb(); \
(p) = (v); \
})
But I am concerned about the following case:
rcu_assign_pointer(global_index, 0);
. . .
x = global_array[rcu_dereference(global_index)];
Since arrays have a zero-th element, we would really want a memory
barrier in this case.
So how about leaving the index-unfriendly version of rcu_assign_pointer()
and adding an rcu_assign_index() as follows?
Thanx, Paul
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
rcupdate.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
--- linux-2.6.24/include/linux/rcupdate.h 2008-01-24 14:58:37.000000000 -0800
+++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-12 08:04:59.000000000 -0800
@@ -278,6 +278,24 @@ extern struct lockdep_map rcu_lock_map;
})
/**
+ * rcu_assign_index - assign (publicize) a index of a newly
+ * initialized array elementg that will be dereferenced by RCU
+ * read-side critical sections. Returns the value assigned.
+ *
+ * Inserts memory barriers on architectures that require them
+ * (pretty much all of them other than x86), and also prevents
+ * the compiler from reordering the code that initializes the
+ * structure after the index assignment. More importantly, this
+ * call documents which indexes will be dereferenced by RCU read-side
+ * code.
+ */
+
+#define rcu_assign_index(p, v) ({ \
+ smp_wmb(); \
+ (p) = (v); \
+ })
+
+/**
* synchronize_sched - block until all CPUs have exited any non-preemptive
* kernel code sequences.
*
^ permalink raw reply
* Re: [git patches] net driver updates
From: Jeff Garzik @ 2008-02-12 16:01 UTC (permalink / raw)
To: Ben Dooks; +Cc: David Miller, netdev, Laurent Pinchart
In-Reply-To: <20080212123828.GB26519@fluff.org.uk>
Ben Dooks wrote:
> These two where meant to be from Laurent Pinchart, they do have
> the correct signed-off lines in for him and start with "Patch from:". Is
> there any chance of fixing the authour attribution now?
The first line of the changeset mentions it. Other than that, nope.
Jeff
^ permalink raw reply
* Re: [Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure
From: Jeff Garzik @ 2008-02-12 15:58 UTC (permalink / raw)
To: Matti Linnanvuori; +Cc: netdev, David Miller
In-Reply-To: <190693.34289.qm@web52005.mail.re2.yahoo.com>
Matti Linnanvuori wrote:
> From: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
>
> There is a race in Linux kernel file net/core/dev.c, function dev_close.
> The function calls function dev_deactivate, which calls function
> dev_watchdog_down that deletes the watchdog timer. However, after that, a
> driver can call netif_carrier_ok, which calls function
> __netdev_watchdog_up that can add the watchdog timer again. Function
> unregister_netdevice calls function dev_shutdown that traps the bug
> !timer_pending(&dev->watchdog_timer). Moving dev_deactivate after
> netif_running() has been cleared prevents function netif_carrier_on
> from calling __netdev_watchdog_up and adding the watchdog timer again.
>
> Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
>
> ---
>
> --- linux-2.6.25/net/core/dev.c 2008-02-12 12:37:51.206833000 +0200
> +++ b/net/core/dev.c 2008-02-12 12:38:48.727611400 +0200
> @@ -1071,8 +1071,6 @@ int dev_close(struct net_device *dev)
> */
> call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
>
> - dev_deactivate(dev);
> -
> clear_bit(__LINK_STATE_START, &dev->state);
>
> /* Synchronize to scheduled poll. We cannot touch poll list,
> @@ -1083,6 +1081,7 @@ int dev_close(struct net_device *dev)
> */
> smp_mb__after_clear_bit(); /* Commit netif_running(). */
>
> + dev_deactivate(dev);
> /*
> * Call the device specific close. This cannot fail.
> * Only if device is UP
This is more for davem (he does net/* stuff)
Jeff
^ permalink raw reply
* Re: e1000e hardware CRC stripping breaks bridging
From: Johan Andersson @ 2008-02-12 13:57 UTC (permalink / raw)
To: Daniel Drake; +Cc: Auke Kok, netdev
In-Reply-To: <47B19EDE.5020802@gentoo.org>
Here is the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=9940
/Johan
On Tue, 2008-02-12 at 13:27 +0000, Daniel Drake wrote:
> Hi,
>
> Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> stripping enabled by e1000e breaks bridging because sometimes the CRC is
> not stripped:
> https://bugs.gentoo.org/show_bug.cgi?id=209235
>
> Apparently "upstream" are aware but I couldn't find any mails or bug
> reports on this topic.
>
> What's the current status of this issue? Perhaps we should disable
> hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
>
> Thanks,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* e1000e hardware CRC stripping breaks bridging
From: Daniel Drake @ 2008-02-12 13:27 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev
Hi,
Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
stripping enabled by e1000e breaks bridging because sometimes the CRC is
not stripped:
https://bugs.gentoo.org/show_bug.cgi?id=209235
Apparently "upstream" are aware but I couldn't find any mails or bug
reports on this topic.
What's the current status of this issue? Perhaps we should disable
hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-12 13:24 UTC (permalink / raw)
To: James Chapman; +Cc: David Miller, netdev
In-Reply-To: <47B17BCD.2070903@katalix.com>
On Tue, Feb 12, 2008 at 10:58:21AM +0000, James Chapman wrote:
...
> Here is a trace from when we had _bh locks.
Very nice...
...But since it's quite long, and if you don't know all these paths
this could take some time, maybe one question: so if lockdep got these
locks right (sometimes it can be wrong when the same structures are
nested), then it seems some problem is with this place below. This
lock is taken for writing with softirqs enabled here, and IMHO it
would be interesting to test if changing this is enough for lockdep.
It seems this is in ip4_datagram_connect() during sk_dst_reset() or
sk_dst_set(). So maybe you could try with local_bh_disable/enable()
around them (or maybe some better idea)? Anyway, I'll try to learn
this more in the meantime.
Jarek P.
> Feb 5 16:26:32 to a soft-irq-unsafe lock:
> Feb 5 16:26:32 (&sk->sk_dst_lock){----}
> Feb 5 16:26:32 ... which became soft-irq-unsafe at:
> Feb 5 16:26:32 ... [<c014e02e>] mark_held_locks+0x5e/0x80
> Feb 5 16:26:32 [<c014ed92>] __lock_acquire+0x6a2/0x10a0
> Feb 5 16:26:32 [<c010f5b0>] save_stack_trace+0x20/0x40
> Feb 5 16:26:32 [<c014c524>] add_lock_to_list+0x44/0xb0
> Feb 5 16:26:32 [<c03dea29>] __udp_lib_get_port+0x19/0x200
> Feb 5 16:26:32 [<c014f735>] __lock_acquire+0x1045/0x10a0
> Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
> Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
> Feb 5 16:26:32 [<c040418a>] _write_lock+0x2a/0x40
> Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
> Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
> Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
> Feb 5 16:26:32 [<c0132317>] local_bh_enable_ip+0xa7/0x120
> Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
> Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
> Feb 5 16:26:32 [<c03e4d55>] inet_dgram_connect+0x35/0x80
> Feb 5 16:26:32 [<c038ec52>] sys_connect+0x82/0xd0
> Feb 5 16:26:32 [<c01455df>] down_read_trylock+0x4f/0x60
> Feb 5 16:26:32 [<c011fe9c>] do_page_fault+0xfc/0x940
> Feb 5 16:26:32 [<c0404024>] _spin_unlock+0x14/0x20
> Feb 5 16:26:32 [<c03905f8>] sys_socketcall+0x98/0x280
> Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
> Feb 5 16:26:32 [<c02a86ba>] copy_to_user+0x3a/0x70
> Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
> Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
> Feb 5 16:26:32 [<ffffffff>] 0xffffffff
^ permalink raw reply
* Re: [git patches] net driver updates
From: Ben Dooks @ 2008-02-12 12:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, netdev, Laurent Pinchart
In-Reply-To: <20080211170516.GA13872@havoc.gtf.org>
On Mon, Feb 11, 2008 at 12:05:16PM -0500, Jeff Garzik wrote:
> Mostly fixes, a few cleanups (generally assisting fixes), and an
> exception for PS3 wireless because it had been posted, reviewed and
> acked for a while, just not committed.
Thanks, good to get the DM9000 changes moving.
> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem
>
> Ben Dooks (24):
> DM9000: Fix endian-ness of data accesses.
> DM9000: Add platform data to specify external phy
These two where meant to be from Laurent Pinchart, they do have
the correct signed-off lines in for him and start with "Patch from:". Is
there any chance of fixing the authour attribution now?
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: James Chapman @ 2008-02-12 10:58 UTC (permalink / raw)
To: David Miller, jarkao2; +Cc: netdev
In-Reply-To: <20080211.213048.192442721.davem@davemloft.net>
David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Mon, 11 Feb 2008 23:41:18 +0000
>
>> Jarek Poplawski wrote:
>>> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
>>> ...
>>>> Below is example output from lockdep. The oops is reproducible when
>>>> creating/deleting lots of sessions while passing data. The lock is being
>>>> acquired for read and write in softirq contexts.
>>>>
>>>> Is there a better way to fix this?
>>>>
>>>> =================================
>>>> [ INFO: inconsistent lock state ]
>>>> 2.6.24-core2 #1
>>>> ---------------------------------
>>>> inconsistent {in-softirq-R} -> {softirq-on-W} usage.
>>>> openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
>>>> (&tunnel->hlist_lock){---?}, at: [<f8eea157>]
>>>> pppol2tp_connect+0x517/0x6d0 [pppol2tp]
>>>> {in-softirq-R} state was registered at:
>>> IMHO, according to this, disabling bh should be enough. And if it's
>>> like in this report: only read_lock is taken from softirqs, then this
>>> should be necessary to change only all write_locks to write_lock_bh
>>> (of course unless somewhere bhs are disabled already). Unless I miss
>>> something?!
>> I thought so too. I tried _bh locks first and the problem still
>> occurred. Maybe I'll try it again in case I messed something up.
>
> I agree with Jarek here, I look at all the code paths that take
> ->hlist_lock and all of them are in user context or software
> interrupts.
>
> Please get a lockdep trace with the change to _bh intead of
> hw interrupt protection so we can find out what that doesn't
> work.
>
> Thanks!
Here is a trace from when we had _bh locks.
Feb 5 16:26:32 ======================================================
Feb 5 16:26:32 [ INFO: soft-safe -> soft-unsafe lock order detected ]
Feb 5 16:26:32 2.6.24-core2 #1
Feb 5 16:26:32 ------------------------------------------------------
Feb 5 16:26:32 pppd/3224 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
Feb 5 16:26:32 (&sk->sk_dst_lock){----}, at: [<f8efacac>]
pppol2tp_xmit+0x23c/0x460 [pppol2tp]
Feb 5 16:26:32
Feb 5 16:26:32 and this task is already holding:
Feb 5 16:26:32 (&pch->downl){-...}, at: [<f8eb828e>]
ppp_push+0x44e/0x620 [ppp_generic]
Feb 5 16:26:32 which would create a new lock dependency:
Feb 5 16:26:32 (&pch->downl){-...} -> (&sk->sk_dst_lock){----}
Feb 5 16:26:32
Feb 5 16:26:32 but this new dependency connects a soft-irq-safe lock:
Feb 5 16:26:32 (&pch->upl){-.-+}
Feb 5 16:26:32 ... which became soft-irq-safe at:
Feb 5 16:26:32 [<c014d87f>] check_usage_backwards+0x1f/0x50
Feb 5 16:26:32 [<c014c479>] save_trace+0x39/0xa0
Feb 5 16:26:32 [<c014edaf>] __lock_acquire+0x6bf/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8ef915a>] pppol2tp_recv_core+0x46a/0x960 [pppol2tp]
Feb 5 16:26:32 [<f8ef967e>] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
Feb 5 16:26:32 [<c0403fd4>] _read_unlock+0x14/0x20
Feb 5 16:26:32 [<c03dd6b6>] udp_queue_rcv_skb+0x106/0x2a0
Feb 5 16:26:32 [<c03ddc7a>] __udp4_lib_rcv+0x42a/0x7e0
Feb 5 16:26:32 [<f8d5c090>] ipt_hook+0x0/0x20 [iptable_filter]
Feb 5 16:26:32 [<c03bc2fa>] ip_local_deliver_finish+0xca/0x1c0
Feb 5 16:26:32 [<c03bc25e>] ip_local_deliver_finish+0x2e/0x1c0
Feb 5 16:26:32 [<c03bbfcf>] ip_rcv_finish+0xff/0x360
Feb 5 16:26:32 [<c03bc6fc>] ip_rcv+0x20c/0x2a0
Feb 5 16:26:32 [<c03bbed0>] ip_rcv_finish+0x0/0x360
Feb 5 16:26:32 [<c039ad87>] netif_receive_skb+0x317/0x4b0
Feb 5 16:26:32 [<c039ab70>] netif_receive_skb+0x100/0x4b0
Feb 5 16:26:32 [<f8d7e27a>] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
Feb 5 16:26:32 [<f8d7dff0>] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
Feb 5 16:26:32 [<c0536150>] unknown_bootoption+0x0/0x1f0
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32
Feb 5 16:26:32 to a soft-irq-unsafe lock:
Feb 5 16:26:32 (&sk->sk_dst_lock){----}
Feb 5 16:26:32 ... which became soft-irq-unsafe at:
Feb 5 16:26:32 ... [<c014e02e>] mark_held_locks+0x5e/0x80
Feb 5 16:26:32 [<c014ed92>] __lock_acquire+0x6a2/0x10a0
Feb 5 16:26:32 [<c010f5b0>] save_stack_trace+0x20/0x40
Feb 5 16:26:32 [<c014c524>] add_lock_to_list+0x44/0xb0
Feb 5 16:26:32 [<c03dea29>] __udp_lib_get_port+0x19/0x200
Feb 5 16:26:32 [<c014f735>] __lock_acquire+0x1045/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
Feb 5 16:26:32 [<c040418a>] _write_lock+0x2a/0x40
Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0132317>] local_bh_enable_ip+0xa7/0x120
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<c03e4d55>] inet_dgram_connect+0x35/0x80
Feb 5 16:26:32 [<c038ec52>] sys_connect+0x82/0xd0
Feb 5 16:26:32 [<c01455df>] down_read_trylock+0x4f/0x60
Feb 5 16:26:32 [<c011fe9c>] do_page_fault+0xfc/0x940
Feb 5 16:26:32 [<c0404024>] _spin_unlock+0x14/0x20
Feb 5 16:26:32 [<c03905f8>] sys_socketcall+0x98/0x280
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c02a86ba>] copy_to_user+0x3a/0x70
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32
Feb 5 16:26:32 other info that might help us debug this:
Feb 5 16:26:32
Feb 5 16:26:32 2 locks held by pppd/3224:
Feb 5 16:26:32 #0: (&ppp->wlock){-...}, at: [<f8eb8478>]
ppp_xmit_process+0x18/0x630 [ppp_generic]
Feb 5 16:26:32 #1: (&pch->downl){-...}, at: [<f8eb828e>]
ppp_push+0x44e/0x620 [ppp_generic]
Feb 5 16:26:32
Feb 5 16:26:32 the soft-irq-safe lock's dependencies:
Feb 5 16:26:32 -> (&pch->upl){-.-+} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<f8efacf3>] pppol2tp_xmit+0x283/0x460 [pppol2tp]
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb9ffd>] ppp_write+0xdd/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0181f86>] vfs_write+0xa6/0x140
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<f8eb9f20>] ppp_write+0x0/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0182651>] sys_write+0x41/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-W at:
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014c524>] add_lock_to_list+0x44/0xb0
Feb 5 16:26:32 [<c014ed68>] __lock_acquire+0x678/0x10a0
Feb 5 16:26:32 [<c014e02e>] mark_held_locks+0x5e/0x80
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7387>] ppp_ioctl+0x647/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c04041cf>] _write_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7387>] ppp_ioctl+0x647/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7387>] ppp_ioctl+0x647/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 in-softirq-R at:
Feb 5 16:26:32 [<c014d87f>] check_usage_backwards+0x1f/0x50
Feb 5 16:26:32 [<c014c479>] save_trace+0x39/0xa0
Feb 5 16:26:32 [<c014edaf>] __lock_acquire+0x6bf/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8ef915a>] pppol2tp_recv_core+0x46a/0x960 [pppol2tp]
Feb 5 16:26:32 [<f8ef967e>] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
Feb 5 16:26:32 [<c0403fd4>] _read_unlock+0x14/0x20
Feb 5 16:26:32 [<c03dd6b6>] udp_queue_rcv_skb+0x106/0x2a0
Feb 5 16:26:32 [<c03ddc7a>] __udp4_lib_rcv+0x42a/0x7e0
Feb 5 16:26:32 [<f8d5c090>] ipt_hook+0x0/0x20 [iptable_filter]
Feb 5 16:26:32 [<c03bc2fa>] ip_local_deliver_finish+0xca/0x1c0
Feb 5 16:26:32 [<c03bc25e>] ip_local_deliver_finish+0x2e/0x1c0
Feb 5 16:26:32 [<c03bbfcf>] ip_rcv_finish+0xff/0x360
Feb 5 16:26:32 [<c03bc6fc>] ip_rcv+0x20c/0x2a0
Feb 5 16:26:32 [<c03bbed0>] ip_rcv_finish+0x0/0x360
Feb 5 16:26:32 [<c039ad87>] netif_receive_skb+0x317/0x4b0
Feb 5 16:26:32 [<c039ab70>] netif_receive_skb+0x100/0x4b0
Feb 5 16:26:32 [<f8d7e27a>] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
Feb 5 16:26:32 [<f8d7dff0>] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
Feb 5 16:26:32 [<c0536150>] unknown_bootoption+0x0/0x1f0
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-R at:
Feb 5 16:26:32 [<c014da27>] mark_lock+0x77/0x620
Feb 5 16:26:32 [<c014ec2f>] __lock_acquire+0x53f/0x10a0
Feb 5 16:26:32 [<f8efacf3>] pppol2tp_xmit+0x283/0x460 [pppol2tp]
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb9ffd>] ppp_write+0xdd/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0181f86>] vfs_write+0xa6/0x140
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<f8eb9f20>] ppp_write+0x0/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0182651>] sys_write+0x41/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 }
Feb 5 16:26:32 ... key at: [<f8ebdf20>]
__key.30415+0x0/0xffffc2e7 [ppp_generic]
Feb 5 16:26:32 -> (&ppp->wlock){-...} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-W at:
Feb 5 16:26:32 [<c014da27>] mark_lock+0x77/0x620
Feb 5 16:26:32 [<c014ed68>] __lock_acquire+0x678/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 }
Feb 5 16:26:32 ... key at: [<f8ebdf08>]
__key.30659+0x0/0xffffc2ff [ppp_generic]
Feb 5 16:26:32 -> (&ppp->rlock){-...} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-W at:
Feb 5 16:26:32 [<c014da27>] mark_lock+0x77/0x620
Feb 5 16:26:32 [<c014ed68>] __lock_acquire+0x678/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 }
Feb 5 16:26:32 ... key at: [<f8ebdf10>]
__key.30658+0x0/0xffffc2f7 [ppp_generic]
Feb 5 16:26:32 ... acquired at:
Feb 5 16:26:32 [<c014f68f>] __lock_acquire+0xf9f/0x10a0
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32
Feb 5 16:26:32 -> (&list->lock#4){.+..} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<c0193ba2>] dput+0xa2/0x130
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c040450c>] _spin_lock_irqsave+0x4c/0x70
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<f8eb9fd5>] ppp_write+0xb5/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0181f86>] vfs_write+0xa6/0x140
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<f8eb9f20>] ppp_write+0x0/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0182651>] sys_write+0x41/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 in-softirq-W at:
Feb 5 16:26:32 [<c014c479>] save_trace+0x39/0xa0
Feb 5 16:26:32 [<c014db32>] mark_lock+0x182/0x620
Feb 5 16:26:32 [<c014ed36>] __lock_acquire+0x646/0x10a0
Feb 5 16:26:32 [<c014ef26>] __lock_acquire+0x836/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c040450c>] _spin_lock_irqsave+0x4c/0x70
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<f8eba0a8>] ppp_input+0x78/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8ef915a>] pppol2tp_recv_core+0x46a/0x960 [pppol2tp]
Feb 5 16:26:32 [<f8ef967e>] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
Feb 5 16:26:32 [<c0403fd4>] _read_unlock+0x14/0x20
Feb 5 16:26:32 [<c03dd6b6>] udp_queue_rcv_skb+0x106/0x2a0
Feb 5 16:26:32 [<c03ddc7a>] __udp4_lib_rcv+0x42a/0x7e0
Feb 5 16:26:32 [<f8d5c090>] ipt_hook+0x0/0x20 [iptable_filter]
Feb 5 16:26:32 [<c03bc2fa>] ip_local_deliver_finish+0xca/0x1c0
Feb 5 16:26:32 [<c03bc25e>] ip_local_deliver_finish+0x2e/0x1c0
Feb 5 16:26:32 [<c03bbfcf>] ip_rcv_finish+0xff/0x360
Feb 5 16:26:32 [<c03bc6fc>] ip_rcv+0x20c/0x2a0
Feb 5 16:26:32 [<c03bbed0>] ip_rcv_finish+0x0/0x360
Feb 5 16:26:32 [<c039ad87>] netif_receive_skb+0x317/0x4b0
Feb 5 16:26:32 [<c039ab70>] netif_receive_skb+0x100/0x4b0
Feb 5 16:26:32 [<f8d7e27a>] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
Feb 5 16:26:32 [<f8d7dff0>] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* [Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure
From: Matti Linnanvuori @ 2008-02-12 10:45 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: bugme-daemon
From: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
There is a race in Linux kernel file net/core/dev.c, function dev_close.
The function calls function dev_deactivate, which calls function
dev_watchdog_down that deletes the watchdog timer. However, after that, a
driver can call netif_carrier_ok, which calls function
__netdev_watchdog_up that can add the watchdog timer again. Function
unregister_netdevice calls function dev_shutdown that traps the bug
!timer_pending(&dev->watchdog_timer). Moving dev_deactivate after
netif_running() has been cleared prevents function netif_carrier_on
from calling __netdev_watchdog_up and adding the watchdog timer again.
Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
---
--- linux-2.6.25/net/core/dev.c 2008-02-12 12:37:51.206833000 +0200
+++ b/net/core/dev.c 2008-02-12 12:38:48.727611400 +0200
@@ -1071,8 +1071,6 @@ int dev_close(struct net_device *dev)
*/
call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
- dev_deactivate(dev);
-
clear_bit(__LINK_STATE_START, &dev->state);
/* Synchronize to scheduled poll. We cannot touch poll list,
@@ -1083,6 +1081,7 @@ int dev_close(struct net_device *dev)
*/
smp_mb__after_clear_bit(); /* Commit netif_running(). */
+ dev_deactivate(dev);
/*
* Call the device specific close. This cannot fail.
* Only if device is UP
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-12 10:42 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <47B0DD54.5000100@katalix.com>
On Mon, Feb 11, 2008 at 11:42:12PM +0000, James Chapman wrote:
> Jarek Poplawski wrote:
>> On Mon, Feb 11, 2008 at 11:49:24PM +0100, Jarek Poplawski wrote:
>>> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
>>> ...
>>>> Below is example output from lockdep. The oops is reproducible when
>>>> creating/deleting lots of sessions while passing data. The lock is
>>>> being acquired for read and write in softirq contexts.
>>
>> ...Hmmm... And according to this, changing read_locks should be
>> necessary too.
>
> The patch changes both read and write locks.
Right! This was only "errata" to my earlier comment where I considered
only lockdep info and forgot about yours...
Sorry,
Jarek P.
^ permalink raw reply
* [PATCH] [IRDA] irda_init() nuke useless debug printk
From: maximilian attems @ 2008-02-12 10:30 UTC (permalink / raw)
To: davem; +Cc: netdev, maximilian attems
irda_init()
dmesg line is not really informative, thus remove it.
There are better ways to know that a module is loaded.
Seen on a debian config with IRDA_DEBUG enabled.
Signed-off-by: maximilian attems <max@stro.at>
---
net/irda/irmod.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/irda/irmod.c b/net/irda/irmod.c
index 01554b9..73db875 100644
--- a/net/irda/irmod.c
+++ b/net/irda/irmod.c
@@ -90,8 +90,6 @@ static int __init irda_init(void)
{
int ret = 0;
- IRDA_DEBUG(0, "%s()\n", __FUNCTION__);
-
/* Lower layer of the stack */
irlmp_init();
irlap_init();
--
1.5.4
^ permalink raw reply related
* Re: [Bugme-new] [Bug 9940] New: e1000e driver with 82566DM-2 controller doesn't strip crc from frames
From: Andrew Morton @ 2008-02-12 10:12 UTC (permalink / raw)
To: Auke Kok; +Cc: bugme-daemon, netdev, johan.andersson
In-Reply-To: <bug-9940-10286@http.bugzilla.kernel.org/>
On Tue, 12 Feb 2008 01:50:49 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9940
>
> Summary: e1000e driver with 82566DM-2 controller doesn't strip
> crc from frames
> Product: Drivers
> Version: 2.5
> KernelVersion: 2.6.24
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: jgarzik@pobox.com
> ReportedBy: johan.andersson@transmode.se
>
>
> Latest working kernel version: n/a
> Earliest failing kernel version: 2.6.24
> Distribution: Gentoo 2007.0
> Hardware Environment: HP Compaq dc7800p
> Software Environment: n/a
> Problem Description:
> The e1000e driver doesn't strip the ethernet frame crc is used with the
> 82566DM-2 chip.
> This will result, among other things, that bridging doesn't work together with
> this chip.
> Reverting commit 140a74802894e9db57e5cd77ccff77e590ece5f3 fixes this issue but
> has performance implications.
>
> Steps to reproduce:
> Send a ping and monitor the responce with tcpdump.
>
^ permalink raw reply
* [PATCH] 2.6.25-rc1 ml4x network driver build failure
From: Kamalesh Babulal @ 2008-02-12 9:42 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, akpm
The 2.6.25-rc1 kernel build fails on the powerpc with the error
drivers/net/mlx4/alloc.c: In function ‘mlx4_buf_alloc’:
drivers/net/mlx4/alloc.c:162: error: implicit declaration of function ‘vmap’
drivers/net/mlx4/alloc.c:162: error: ‘VM_MAP’ undeclared (first use in this function)
drivers/net/mlx4/alloc.c:162: error: (Each undeclared identifier is reported only once
drivers/net/mlx4/alloc.c:162: error: for each function it appears in.)
drivers/net/mlx4/alloc.c:162: warning: assignment makes pointer from integer without a cast
drivers/net/mlx4/alloc.c: In function ‘mlx4_buf_free’:
drivers/net/mlx4/alloc.c:187: error: implicit declaration of function ‘vunmap’
make[3]: *** [drivers/net/mlx4/alloc.o] Error 1
make[2]: *** [drivers/net/mlx4] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
I have tested the patch for the build failure.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
--- linux-2.6.25-rc1/drivers/net/mlx4/alloc.c 2008-02-11 03:48:14.000000000 +0530
+++ linux-2.6.25-rc1/drivers/net/mlx4/~alloc.c 2008-02-12 14:43:46.000000000 +0530
@@ -34,6 +34,7 @@
#include <linux/slab.h>
#include <linux/bitmap.h>
#include <linux/dma-mapping.h>
+#include <linux/vmalloc.h>
#include "mlx4.h"
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
From: Jarek Poplawski @ 2008-02-12 9:44 UTC (permalink / raw)
To: Jann Traschewski
Cc: 'David Miller', 'Bernard Pidoux F6BVP',
'Ralf Baechle DL5RB', netdev
In-Reply-To: <000201c86d53$569297e0$453c822c@dg8ngn>
On Tue, Feb 12, 2008 at 09:43:26AM +0100, Jann Traschewski wrote:
> Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
> Thanks,
> Jann
Thanks Jann, too!
BTW, I hope maybe until tomorrow I'll figure out something about those
earlier two AX25 testing patches.
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Jarek Poplawski @ 2008-02-12 8:57 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, paulmck, netdev, linux-kernel
In-Reply-To: <20080211.171645.74019568.davem@davemloft.net>
On 12-02-2008 02:16, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 11 Feb 2008 16:59:54 -0800
>
> linux-kernel added to CC:, any change to generic kernel infrastructure
> should be posted there
>
>> Eliminate warnings when rcu_assign_pointer is used with unsigned long.
>> It is reasonable to use RCU with non-pointer values so allow it for general
>> use. Add a comment to explain the if test.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>> ---
>> include/linux/rcupdate.h | 13 +++++++------
>> 1 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
>> index 37a642c..c44ac87 100644
>> --- a/include/linux/rcupdate.h
>> +++ b/include/linux/rcupdate.h
>> @@ -172,14 +172,15 @@ struct rcu_head {
>> * structure after the pointer assignment. More importantly, this
>> * call documents which pointers will be dereferenced by RCU read-side
>> * code.
>> + *
>> + * If value is the NULL (constant 0), then no barrier is needed.
>> */
>>
>> -#define rcu_assign_pointer(p, v) \
>> - ({ \
>> - if (!__builtin_constant_p(v) || \
>> - ((v) != NULL)) \
>> - smp_wmb(); \
>> - (p) = (v); \
>> +#define rcu_assign_pointer(p, v) \
>> + ({ \
>> + if (!(__builtin_constant_p(v) && v)) \
...But, "If value is the NULL (constant 0)" we have:
if (!(1 && NULL != 0)) ==> if (!(0)) and the barrier is used?!
>> + smp_wmb(); \
>> + (p) = (v); \
>> })
>>
>> /**
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
From: Jann Traschewski @ 2008-02-12 8:43 UTC (permalink / raw)
To: 'Jarek Poplawski', 'David Miller'
Cc: 'Bernard Pidoux F6BVP', 'Ralf Baechle DL5RB',
netdev
In-Reply-To: <20080211124251.GB3597@ff.dom.local>
Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
Thanks,
Jann
> -----Ursprüngliche Nachricht-----
> Von: Jarek Poplawski [mailto:jarkao2@gmail.com]
> Gesendet: Montag, 11. Februar 2008 13:43
> An: David Miller
> Cc: Jann Traschewski; Bernard Pidoux F6BVP; Ralf Baechle
> DL5RB; netdev@vger.kernel.org
> Betreff: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
>
>
> Subject: [AX25] ax25_route: make ax25_route_lock BH safe
>
> > =================================
> > [ INFO: inconsistent lock state ]
> > 2.6.24-dg8ngn-p02 #1
> > ---------------------------------
> > inconsistent {softirq-on-W} -> {in-softirq-R} usage.
> > linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
> > (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7
> > [ax25] {softirq-on-W} state was registered at:
> ...
>
> This lockdep report shows that ax25_route_lock is taken for
> reading in softirq context, and for writing in process
> context with BHs enabled.
> So, to make this safe, all write_locks in ax25_route.c are
> changed to _bh versions.
>
>
> Reported-by: Jann Traschewski <jann@gmx.de>,
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>
> ---
>
> diff -Nurp 2.6.24-mm1-/net/ax25/ax25_route.c
> 2.6.24-mm1+/net/ax25/ax25_route.c
> --- 2.6.24-mm1-/net/ax25/ax25_route.c 2008-02-05
> 07:45:38.000000000 +0000
> +++ 2.6.24-mm1+/net/ax25/ax25_route.c 2008-02-11
> 11:58:47.000000000 +0000
> @@ -45,7 +45,7 @@ void ax25_rt_device_down(struct net_devi {
> ax25_route *s, *t, *ax25_rt;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> s = ax25_rt;
> @@ -68,7 +68,7 @@ void ax25_rt_device_down(struct net_devi
> }
> }
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> }
>
> static int __must_check ax25_rt_add(struct
> ax25_routes_struct *route) @@ -82,7 +82,7 @@ static int
> __must_check ax25_rt_add(stru
> if (route->digi_count > AX25_MAX_DIGIS)
> return -EINVAL;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
>
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> @@ -92,7 +92,7 @@ static int __must_check ax25_rt_add(stru
> ax25_rt->digipeat = NULL;
> if (route->digi_count != 0) {
> if ((ax25_rt->digipeat =
> kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
> - write_unlock(&ax25_route_lock);
> +
> write_unlock_bh(&ax25_route_lock);
> return -ENOMEM;
> }
> ax25_rt->digipeat->lastrepeat =
> -1; @@ -102,14 +102,14 @@ static int __must_check ax25_rt_add(stru
>
> ax25_rt->digipeat->calls[i] = route->digi_addr[i];
> }
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> return 0;
> }
> ax25_rt = ax25_rt->next;
> }
>
> if ((ax25_rt = kmalloc(sizeof(ax25_route), GFP_ATOMIC))
> == NULL) {
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> return -ENOMEM;
> }
>
> @@ -120,7 +120,7 @@ static int __must_check ax25_rt_add(stru
> ax25_rt->ip_mode = ' ';
> if (route->digi_count != 0) {
> if ((ax25_rt->digipeat =
> kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> kfree(ax25_rt);
> return -ENOMEM;
> }
> @@ -133,7 +133,7 @@ static int __must_check ax25_rt_add(stru
> }
> ax25_rt->next = ax25_route_list;
> ax25_route_list = ax25_rt;
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
>
> return 0;
> }
> @@ -152,7 +152,7 @@ static int ax25_rt_del(struct ax25_route
> if ((ax25_dev = ax25_addr_ax25dev(&route->port_addr)) == NULL)
> return -EINVAL;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
>
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> @@ -174,7 +174,7 @@ static int ax25_rt_del(struct ax25_route
> }
> }
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
>
> return 0;
> }
> @@ -188,7 +188,7 @@ static int ax25_rt_opt(struct ax25_route
> if ((ax25_dev =
> ax25_addr_ax25dev(&rt_option->port_addr)) == NULL)
> return -EINVAL;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
>
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> @@ -216,7 +216,7 @@ static int ax25_rt_opt(struct ax25_route
> }
>
> out:
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> return err;
> }
>
> @@ -492,7 +492,7 @@ void __exit ax25_rt_free(void) {
> ax25_route *s, *ax25_rt = ax25_route_list;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
> while (ax25_rt != NULL) {
> s = ax25_rt;
> ax25_rt = ax25_rt->next;
> @@ -500,5 +500,5 @@ void __exit ax25_rt_free(void)
> kfree(s->digipeat);
> kfree(s);
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> }
^ permalink raw reply
* [PATCH] trivial: fix alignment of IP-Config output
From: Uwe Kleine-König @ 2008-02-12 8:38 UTC (permalink / raw)
To: netdev; +Cc: trivial, linux-kernel
make the intended lines aligned in the output (not in the code)
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
net/ipv4/ipconfig.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index a52b585..10013cc 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1390,7 +1390,7 @@ static int __init ip_auto_config(void)
* Clue in the operator.
*/
printk("IP-Config: Complete:");
- printk("\n device=%s", ic_dev->name);
+ printk("\n device=%s", ic_dev->name);
printk(", addr=%u.%u.%u.%u", NIPQUAD(ic_myaddr));
printk(", mask=%u.%u.%u.%u", NIPQUAD(ic_netmask));
printk(", gw=%u.%u.%u.%u", NIPQUAD(ic_gateway));
--
1.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox