* [2.6.25-rc1] Locks in udp_recvmsg()?
From: Tetsuo Handa @ 2008-02-11 2:20 UTC (permalink / raw)
To: netdev
Hello.
I found that udp_recvmsg() in net/ipv4/udp.c for 2.6.25-rc1 calls
lock_sock() only when it releases the datagram (i.e. out_free: and csum_copy_err:).
Is it correct to call __skb_recv_datagram() without calling lock_sock()
when it acquires the datagram (i.e. try_again:)?
Regards.
^ permalink raw reply
* Re: Netfilter fixes to 2.6.24-git
From: David Miller @ 2008-02-11 5:27 UTC (permalink / raw)
To: jengelh; +Cc: netdev, linux-kernel, netfilter-devel, kaber, torvalds
In-Reply-To: <Pine.LNX.4.64.0802102146590.7915@fbirervta.pbzchgretzou.qr>
From: Jan Engelhardt <jengelh@computergmbh.de>
Date: Sun, 10 Feb 2008 22:02:35 +0100 (CET)
> I have been unable to reach the netfilter and net maintainers the past
> week regarding inclusion of patches, but most importantly a group of
> fixes at [0]-[3]. I am kind of at a loss here but to turn up the volume
> and write to more people on how to proceed.
You just need to be patient and wait for Patrick to get to your
patches, it's as simple as that :-)
Patrick is normally very responsive, so whatever it is it has to be a
temporary issue.
Because of LCA08 etc. I myself wasn't even able to get any networking
bug fix submissions into 2.6.24.1
Big deal, we'll just get it into the next 2.6.24.x release.
Thanks for your patience.
^ permalink raw reply
* Re: Netfilter fixes to 2.6.24-git
From: Patrick McHardy @ 2008-02-11 7:00 UTC (permalink / raw)
To: David Miller; +Cc: jengelh, netdev, linux-kernel, netfilter-devel, torvalds
In-Reply-To: <20080210.212754.55064006.davem@davemloft.net>
David Miller wrote:
> From: Jan Engelhardt <jengelh@computergmbh.de>
> Date: Sun, 10 Feb 2008 22:02:35 +0100 (CET)
>
>> I have been unable to reach the netfilter and net maintainers the past
>> week regarding inclusion of patches, but most importantly a group of
>> fixes at [0]-[3]. I am kind of at a loss here but to turn up the volume
>> and write to more people on how to proceed.
>
> You just need to be patient and wait for Patrick to get to your
> patches, it's as simple as that :-)
>
> Patrick is normally very responsive, so whatever it is it has to be a
> temporary issue.
Indeed, I'm currently ill and not really up for much working,
but this will hopefully get better soon.
^ permalink raw reply
* Re: [patch 1/2] qeth: new qeth device driver
From: Frank Blaschka @ 2008-02-11 7:55 UTC (permalink / raw)
To: paulmck; +Cc: netdev
In-Reply-To: <20080208155416.GB12085@linux.vnet.ibm.com>
Paul E. McKenney schrieb:
> On Fri, Feb 08, 2008 at 03:10:00PM +0100, Frank.Blaschka@de.ibm.com wrote:
>> From: Frank Blaschka <frank.blaschka@de.ibm.com>
>>
>> List of major changes and improvements:
>> no manipulation of the global ARP constructor
>> clean code split into core, layer 2 and layer 3 functionality
>> better exploitation of the ethtool interface
>> better representation of the various hardware capabilities
>> fix packet socket support (tcpdump), no fake_ll required
>> osasnmpd notification via udev events
>> coding style and beautification
>
> One question below...
>
>> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
>> ---
>
> [ . . . ]
>
>> +static void qeth_l3_vlan_rx_add_vid(struct net_device *dev, unsigned short vid)
>> +{
>> + struct net_device *vlandev;
>> + struct qeth_card *card = (struct qeth_card *) dev->priv;
>> + struct in_device *in_dev;
>> +
>> + if (card->info.type == QETH_CARD_TYPE_IQD)
>> + return;
>> +
>> + vlandev = vlan_group_get_device(card->vlangrp, vid);
>> + vlandev->neigh_setup = qeth_l3_neigh_setup;
>> +
>> + in_dev = __in_dev_get_rcu(vlandev);
>
> Is this really in an RCU read-side critical section? Or is this just
> using common code?
>
> Thanx, Paul
> --
> 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
>
Hi Paul,
thanks for pointing at this. Using __in_dev_get_rcu without the rcu lock
is probably a bug at this place (right?). Using in_dev_get/in_dev_put
would be more appropriate. Same for qeth_l3_free_vlan_addresses4(), here
we take the rcu read lock, but in_dev_get/in_dev_put would be the better
choice. What do you think?
Best regards,
Frank
^ permalink raw reply
* Re: Netfilter fixes to 2.6.24-git
From: Jarek Poplawski @ 2008-02-11 8:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <47AFF28A.9090808@trash.net>
On 11-02-2008 08:00, Patrick McHardy wrote:
...
> Indeed, I'm currently ill and not really up for much working,
> but this will hopefully get better soon.
Wish you well, Patrick!
I hope it's about some WARN_ON not BUG_ON?
Anyway, drop these last patches and get back to stable!
Regards,
Jarek P.
^ permalink raw reply
* Re: [patch 1/7] typhoon section fix
From: Jan Beulich @ 2008-02-11 8:22 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: davem, jeff, Andrew Morton, David Dillow, netdev
In-Reply-To: <20080208190340.GA31072@uranus.ravnborg.org>
>So do we have other options that to drop the constification and thus
>dropping the __devinitconst and the other __*const annotations - I think not :-(
As I had said already in another reply - I think the most reasonable thing
to do is to fold section name attribute *and* const into __*initconst
(while defining __*initconst to __*initdata on those targets not allowing
relocations in read-only sections, which should be done by a promptless
config option to avoid enumerating all the targets each time such a
conditional is needed somewhere). While that doesn't allow the 'const'
compile time checking on those problem targets, it is consistent for all
targets and provides the intended DEBUG_RODATA benefit where
possible. Additionally, the const compile time checking will then be more
tight on the presumable more frequently tested x86 targets, so the
chances of bad constructs slipping in should be reduced.
Jan
^ permalink raw reply
* [PATCH] [IPV4]: Remove warning in node_set_parent.
From: Denis V. Lunev @ 2008-02-11 8:47 UTC (permalink / raw)
To: davem; +Cc: netdev, devel, shemminger, Denis V. Lunev
net/ipv4/fib_trie.c: In function 'node_set_parent':
net/ipv4/fib_trie.c:184: warning: assignment makes integer from pointer
without a cast
Signed-off-by: Denis V. Lunev <den@openvz.org>
---
net/ipv4/fib_trie.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index f5fba3f..1753cd4 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -177,10 +177,11 @@ static inline struct tnode *node_parent_rcu(struct node *node)
return rcu_dereference(ret);
}
-static inline void node_set_parent(struct node *node, struct tnode *ptr)
+static inline void node_set_parent(struct node *node, struct tnode *__ptr)
{
- rcu_assign_pointer(node->parent,
- (unsigned long)ptr | NODE_TYPE(node));
+ struct node *ptr;
+ ptr = (struct node *)((unsigned long)__ptr | NODE_TYPE(node));
+ rcu_assign_pointer(node->parent, ptr);
}
static inline struct node *tnode_get_child(struct tnode *tn, unsigned int i)
--
1.5.3.rc5
^ permalink raw reply related
* [BUG][AX25] mkiss and ax25_route lockdep warning
From: Jann Traschewski @ 2008-02-11 8:56 UTC (permalink / raw)
To: netdev
Hello,
After using "Lock debugging: prove locking correctness" with the Kernel I
got this warning:
=================================
[ 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:
[<c013a340>] __lock_acquire+0x464/0xb7b
[<c01398d8>] mark_held_locks+0x39/0x53
[<c0124d35>] local_bh_enable_ip+0xcd/0xd5
[<c0139aaf>] trace_hardirqs_on+0x11a/0x13d
[<c013ae58>] lock_acquire+0x5f/0x77
[<f8a0d381>] ax25_rt_ioctl+0x66/0x325 [ax25]
[<c0299ce7>] _write_lock+0x29/0x34
[<f8a0d381>] ax25_rt_ioctl+0x66/0x325 [ax25]
[<f8a0d381>] ax25_rt_ioctl+0x66/0x325 [ax25]
[<f8a0f699>] ax25_ioctl+0x1b6/0x5b8 [ax25]
[<c0161280>] fd_install+0x1e/0x46
[<c0299c7a>] _spin_lock+0x29/0x34
[<c022e75d>] sock_ioctl+0x1bb/0x1e0
[<c022e5a2>] sock_ioctl+0x0/0x1e0
[<c016c76f>] do_ioctl+0x1f/0x62
[<c016c9d2>] vfs_ioctl+0x220/0x232
[<c0139aaf>] trace_hardirqs_on+0x11a/0x13d
[<c016ca17>] sys_ioctl+0x33/0x4c
[<c0103ea2>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
irq event stamp: 120000
hardirqs last enabled at (120000): [<c0124d35>]
local_bh_enable_ip+0xcd/0xd5
hardirqs last disabled at (119999): [<c0124cc3>]
local_bh_enable_ip+0x5b/0xd5
softirqs last enabled at (119892): [<f89fd53d>]
mkiss_receive_buf+0x2a5/0x394 [mkiss]
softirqs last disabled at (119893): [<c01249f0>] do_softirq+0x37/0x4d
other info that might help us debug this:
5 locks held by linuxnet/3046:
#0: (&tty->atomic_write_lock){--..}, at: [<c01ded5e>]
tty_write_lock+0x11/0x37
#1: (rcu_read_lock){..--}, at: [<c023a8d2>] net_rx_action+0x4e/0x1c4
#2: (rcu_read_lock){..--}, at: [<c0238579>] netif_receive_skb+0xe6/0x3d6
#3: (rcu_read_lock){..--}, at: [<c025549d>]
ip_local_deliver_finish+0x2d/0x1f7
#4: (slock-AF_INET){-+..}, at: [<c0274e43>] icmp_send+0x10e/0x37a
stack backtrace:
Pid: 3046, comm: linuxnet Not tainted 2.6.24-dg8ngn-p02 #1
[<c0138e13>] print_usage_bug+0x138/0x142
[<c013961f>] mark_lock+0x1ca/0x44a
[<c013a2d9>] __lock_acquire+0x3fd/0xb7b
[<c01398d8>] mark_held_locks+0x39/0x53
[<c0124d35>] local_bh_enable_ip+0xcd/0xd5
[<c013ae58>] lock_acquire+0x5f/0x77
[<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
[<c0299dc7>] _read_lock+0x29/0x34
[<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
[<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
[<f89fda29>] ax_header+0x0/0x1a [mkiss]
[<f8a0c3f6>] ax25_rebuild_header+0x30/0x202 [ax25]
[<f89fda29>] ax_header+0x0/0x1a [mkiss]
[<c023f90c>] neigh_compat_output+0x7b/0x97
[<c0258bd6>] ip_finish_output+0x1da/0x204
[<c0259a26>] ip_output+0x74/0x89
[<c0257831>] ip_push_pending_frames+0x2d8/0x33a
[<c025742c>] dst_output+0x0/0x7
[<c0275039>] icmp_send+0x304/0x37a
[<c013a353>] __lock_acquire+0x477/0xb7b
[<c0270c05>] __udp4_lib_lookup+0xec/0xf6
[<c0271a48>] __udp4_lib_rcv+0x586/0x771
[<c02555ae>] ip_local_deliver_finish+0x13e/0x1f7
[<c025549d>] ip_local_deliver_finish+0x2d/0x1f7
[<c0255451>] ip_rcv_finish+0x2c1/0x2e0
[<c025591c>] ip_rcv+0x1f0/0x22b
[<c0255190>] ip_rcv_finish+0x0/0x2e0
[<c0238808>] netif_receive_skb+0x375/0x3d6
[<c0238579>] netif_receive_skb+0xe6/0x3d6
[<c023adc4>] process_backlog+0x6c/0xcd
[<c023a940>] net_rx_action+0xbc/0x1c4
[<c023a8d2>] net_rx_action+0x4e/0x1c4
[<c0124944>] __do_softirq+0x69/0xde
[<f89fd53d>] mkiss_receive_buf+0x2a5/0x394 [mkiss]
[<c01249f0>] do_softirq+0x37/0x4d
[<c0124d15>] local_bh_enable_ip+0xad/0xd5
[<f89fd53d>] mkiss_receive_buf+0x2a5/0x394 [mkiss]
[<c029a042>] _spin_unlock_irqrestore+0x34/0x39
[<c01e3233>] pty_write+0x2f/0x39
[<c01e1233>] write_chan+0x22d/0x2a1
[<c01191e7>] default_wake_function+0x0/0x8
[<c01def37>] tty_write+0x14d/0x1c2
[<c01e1006>] write_chan+0x0/0x2a1
[<c01dedea>] tty_write+0x0/0x1c2
[<c0162f28>] vfs_write+0x8a/0x10c
[<c01634a4>] sys_write+0x41/0x67
[<c0103ea2>] syscall_call+0x7/0xb
=======================
--
Jann Traschewski, Drosselstr.1, D-90513 Zirndorf, Germany
Tel.: +49-911-696971, Mobile: +49-170-1045937, EMail: jann@gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/db0fhn, ICQ UIN: 4130182
^ permalink raw reply
* Re: [PATCH][RFC] race in generic address resolution
From: Frank Blaschka @ 2008-02-11 9:01 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20080205.205154.153345843.davem@davemloft.net>
David Miller schrieb:
> From: Blaschka <frank.blaschka@de.ibm.com>
> Date: Mon, 4 Feb 2008 15:27:17 +0100
>
>> I'm running a SMP maschine (2 CPUs) configured as a router. During heavy
>> traffic kernel dies with following message:
>>
>> <2>kernel BUG at /home/autobuild/BUILD/linux-2.6.23-20080125/net/core/skbuff.c:648!
> ...
>> Following patch fixes the problem but I do not know if it is a good sollution.
>>
>> From: Frank Blaschka <frank.blaschka@de.ibm.com>
>>
>> neigh_update sends skb from neigh->arp_queue while
>> neigh_timer_handler has increased skbs refcount and calls
>> solicit with the skb. Do not send neighbour skbs
>> marked for solicit (skb_shared).
>>
>> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
>
> Thanks for finding this bug.
>
> I'm fine with your approach as a temporary fix, but there is a slight
> problem with your patch. If the skb is shared we have to free it if
> we don't pass it on to ->output(), otherwise this creates a leak.
>
> In the longer term, this is an unfortunate limitation. The
> ->solicit() code just wants to look at a few header fields to
> determine how to construct the solicitation request.
>
> What's funny is that we added these skb_get() calls for
> the solications exactly to deal with this race condition.
>
> I considered various ways to fix this. The simplest is probably just
> to skb_copy() in the ->solicit() case. Solicitation is a rare event
> so it's not big deal to copy the packet until the neighbour is
> resolved.
>
> The other option is holding the write lock on neigh->lock during the
> ->solicit() call. I looked at all of the ndisc_ops implementations
> and this seems workable. The only case that needs special care is the
> IPV4 ARP implementation of arp_solicit(). It wants to take
> neigh->lock as a reader to protect the header entry in neigh->ha
> during the emission of the soliciation. We can simply remove the read
> lock calls to take care of that since holding the lock as a writer at
> the caller providers a superset of the protection afforded by the
> existing read locking.
>
> The rest of the ->solicit() implementations don't care whether
> the neigh is locked or not.
>
> Can you see if this version of the patch fixes your problem?
>
> Thanks!
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index a16cf1e..7bb6a9a 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -834,18 +834,12 @@ static void neigh_timer_handler(unsigned long arg)
> }
> if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) {
> struct sk_buff *skb = skb_peek(&neigh->arp_queue);
> - /* keep skb alive even if arp_queue overflows */
> - if (skb)
> - skb_get(skb);
> - write_unlock(&neigh->lock);
> +
> neigh->ops->solicit(neigh, skb);
> atomic_inc(&neigh->probes);
> - if (skb)
> - kfree_skb(skb);
> - } else {
> -out:
> - write_unlock(&neigh->lock);
> }
> +out:
> + write_unlock(&neigh->lock);
>
> if (notify)
> neigh_update_notify(neigh);
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index 8e17f65..c663fa5 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -368,7 +368,6 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
> if (!(neigh->nud_state&NUD_VALID))
> printk(KERN_DEBUG "trying to ucast probe in NUD_INVALID\n");
> dst_ha = neigh->ha;
> - read_lock_bh(&neigh->lock);
> } else if ((probes -= neigh->parms->app_probes) < 0) {
> #ifdef CONFIG_ARPD
> neigh_app_ns(neigh);
> @@ -378,8 +377,6 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
>
> arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
> dst_ha, dev->dev_addr, NULL);
> - if (dst_ha)
> - read_unlock_bh(&neigh->lock);
> }
>
> static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
> --
> 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
>
Hi Dave,
we run your patch during the weekend on single CPU and SMP machines. We do not
see any problems. Thanks for providing the fix.
Best regards,
Frank
^ permalink raw reply
* [PATCH] [RESENDING] netconsole: register cmdline netconsole configs to configfs
From: Joonwoo Park @ 2008-02-11 9:08 UTC (permalink / raw)
To: akpm; +Cc: Joonwoo Park, linux-kernel, netdev, satyam, mpm
In-Reply-To: <12027209163465-git-send-email-joonwpark81@gmail.com>
This patch intorduces cmdline netconsole configs to register to configfs
with dynamic netconsole. Satyam Sharma who designed shiny dynamic
reconfiguration for netconsole, mentioned about this issue already.
(http://lkml.org/lkml/2007/7/29/360)
But I think, without separately managing of two kind of netconsole target
objects, it's possible by using config_group instead of
config_item in the netconsole_target and default_groups feature of configfs.
Patch was tested with configuration creation/destruction by kernel and
module.
And it makes possible to enable/disable, modify and review netconsole
target configs from cmdline.
Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
---
drivers/net/netconsole.c | 91 ++++++++++++++++++++++++++++++++++++----------
1 files changed, 72 insertions(+), 19 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 31e047d..63aabbb 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -93,7 +93,7 @@ static DEFINE_SPINLOCK(target_list_lock);
struct netconsole_target {
struct list_head list;
#ifdef CONFIG_NETCONSOLE_DYNAMIC
- struct config_item item;
+ struct config_group group;
#endif
int enabled;
struct netpoll np;
@@ -103,16 +103,49 @@ struct netconsole_target {
static struct configfs_subsystem netconsole_subsys;
-static int __init dynamic_netconsole_init(void)
+static void netconsole_target_put(struct netconsole_target *nt);
+static struct config_item_type netconsole_target_type;
+
+static int __init dynamic_netconsole_init(int defaults)
{
+ int err;
+ unsigned long flags;
config_group_init(&netconsole_subsys.su_group);
+
+ if (defaults > 0) {
+ struct list_head *pos;
+ struct config_group **groups;
+ int i = 0;
+
+ groups = kcalloc(defaults, sizeof(struct config_group *),
+ GFP_KERNEL);
+ if (!groups)
+ return -ENOMEM;
+
+ spin_lock_irqsave(&target_list_lock, flags);
+ list_for_each(pos, &target_list) {
+ struct netconsole_target *nt;
+ nt = list_entry(pos, struct netconsole_target, list);
+ groups[i] = &nt->group;
+ i++;
+ }
+ spin_unlock_irqrestore(&target_list_lock, flags);
+ netconsole_subsys.su_group.default_groups = groups;
+ }
+
mutex_init(&netconsole_subsys.su_mutex);
- return configfs_register_subsystem(&netconsole_subsys);
+
+ err = configfs_register_subsystem(&netconsole_subsys);
+ if (err)
+ kfree(netconsole_subsys.su_group.default_groups);
+
+ return err;
}
static void __exit dynamic_netconsole_exit(void)
{
configfs_unregister_subsystem(&netconsole_subsys);
+ kfree(netconsole_subsys.su_group.default_groups);
}
/*
@@ -122,14 +155,23 @@ static void __exit dynamic_netconsole_exit(void)
*/
static void netconsole_target_get(struct netconsole_target *nt)
{
- if (config_item_name(&nt->item))
- config_item_get(&nt->item);
+ if (config_item_name(&nt->group.cg_item))
+ config_item_get(&nt->group.cg_item);
}
static void netconsole_target_put(struct netconsole_target *nt)
{
- if (config_item_name(&nt->item))
- config_item_put(&nt->item);
+ if (config_item_name(&nt->group.cg_item))
+ config_item_put(&nt->group.cg_item);
+}
+
+static void dynamic_netconsole_init_type_name(struct netconsole_target *nt,
+ int index)
+{
+ char name[16];
+ snprintf(name, sizeof(name), "netcon%d", index);
+ config_item_init_type_name(&nt->group.cg_item, name,
+ &netconsole_target_type);
}
#else /* !CONFIG_NETCONSOLE_DYNAMIC */
@@ -155,6 +197,11 @@ static void netconsole_target_put(struct netconsole_target *nt)
{
}
+static void dynamic_netconsole_init_type_name(struct netconsole_target *nt,
+ int index)
+{
+}
+
#endif /* CONFIG_NETCONSOLE_DYNAMIC */
/* Allocate new target (from boot/module param) and setup netpoll for it */
@@ -236,8 +283,8 @@ struct netconsole_target_attr {
static struct netconsole_target *to_target(struct config_item *item)
{
return item ?
- container_of(item, struct netconsole_target, item) :
- NULL;
+ container_of(to_config_group(item), struct netconsole_target,
+ group) : NULL;
}
/*
@@ -370,7 +417,7 @@ static ssize_t store_dev_name(struct netconsole_target *nt,
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
"disable to update parameters\n",
- config_item_name(&nt->item));
+ config_item_name(&nt->group.cg_item));
return -EINVAL;
}
@@ -394,7 +441,7 @@ static ssize_t store_local_port(struct netconsole_target *nt,
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
"disable to update parameters\n",
- config_item_name(&nt->item));
+ config_item_name(&nt->group.cg_item));
return -EINVAL;
}
@@ -417,7 +464,7 @@ static ssize_t store_remote_port(struct netconsole_target *nt,
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
"disable to update parameters\n",
- config_item_name(&nt->item));
+ config_item_name(&nt->group.cg_item));
return -EINVAL;
}
@@ -437,7 +484,7 @@ static ssize_t store_local_ip(struct netconsole_target *nt,
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
"disable to update parameters\n",
- config_item_name(&nt->item));
+ config_item_name(&nt->group.cg_item));
return -EINVAL;
}
@@ -453,7 +500,7 @@ static ssize_t store_remote_ip(struct netconsole_target *nt,
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
"disable to update parameters\n",
- config_item_name(&nt->item));
+ config_item_name(&nt->group.cg_item));
return -EINVAL;
}
@@ -473,7 +520,7 @@ static ssize_t store_remote_mac(struct netconsole_target *nt,
if (nt->enabled) {
printk(KERN_ERR "netconsole: target (%s) is enabled, "
"disable to update parameters\n",
- config_item_name(&nt->item));
+ config_item_name(&nt->group.cg_item));
return -EINVAL;
}
@@ -608,14 +655,15 @@ static struct config_item *make_netconsole_target(struct config_group *group,
memset(nt->np.remote_mac, 0xff, ETH_ALEN);
/* Initialize the config_item member */
- config_item_init_type_name(&nt->item, name, &netconsole_target_type);
+ config_item_init_type_name(&nt->group.cg_item, name,
+ &netconsole_target_type);
/* Adding, but it is disabled */
spin_lock_irqsave(&target_list_lock, flags);
list_add(&nt->list, &target_list);
spin_unlock_irqrestore(&target_list_lock, flags);
- return &nt->item;
+ return &nt->group.cg_item;
}
static void drop_netconsole_target(struct config_group *group,
@@ -635,7 +683,7 @@ static void drop_netconsole_target(struct config_group *group,
if (nt->enabled)
netpoll_cleanup(&nt->np);
- config_item_put(&nt->item);
+ config_item_put(&nt->group.cg_item);
}
static struct configfs_group_operations netconsole_subsys_group_ops = {
@@ -741,6 +789,7 @@ static int __init init_netconsole(void)
unsigned long flags;
char *target_config;
char *input = config;
+ int i = 0;
if (strnlen(input, MAX_PARAM_LENGTH)) {
while ((target_config = strsep(&input, ";"))) {
@@ -749,9 +798,13 @@ static int __init init_netconsole(void)
err = PTR_ERR(nt);
goto fail;
}
+
+ dynamic_netconsole_init_type_name(nt, i);
+
spin_lock_irqsave(&target_list_lock, flags);
list_add(&nt->list, &target_list);
spin_unlock_irqrestore(&target_list_lock, flags);
+ i++;
}
}
@@ -759,7 +812,7 @@ static int __init init_netconsole(void)
if (err)
goto fail;
- err = dynamic_netconsole_init();
+ err = dynamic_netconsole_init(i);
if (err)
goto undonotifier;
--
1.5.3.rc5
^ permalink raw reply related
* [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: James Chapman @ 2008-02-11 9:22 UTC (permalink / raw)
To: netdev
Fix locking issues in the pppol2tp driver which can cause a kernel
crash on SMP boxes when hundreds of L2TP sessions are created/deleted
simultaneously (ISP environment). The driver was violating read_lock()
and write_lock() scheduling rules so we now consistently use the _irq
variants of the lock functions.
Signed-off-by: James Chapman <jchapman@katalix.com>
--
This patch has been verified by the ISP that discovered the problem.
If the patch is accepted, it should be pushed to the stable 2.6.23 and
2.6.24 trees.
Index: linux-2.6.24/drivers/net/pppol2tp.c
===================================================================
--- linux-2.6.24.orig/drivers/net/pppol2tp.c
+++ linux-2.6.24/drivers/net/pppol2tp.c
@@ -301,15 +301,16 @@ pppol2tp_session_find(struct pppol2tp_tu
pppol2tp_session_id_hash(tunnel, session_id);
struct pppol2tp_session *session;
struct hlist_node *walk;
+ unsigned long flags;
- read_lock(&tunnel->hlist_lock);
+ read_lock_irqsave(&tunnel->hlist_lock, flags);
hlist_for_each_entry(session, walk, session_list, hlist) {
if (session->tunnel_addr.s_session == session_id) {
- read_unlock(&tunnel->hlist_lock);
+ read_unlock_irqrestore(&tunnel->hlist_lock, flags);
return session;
}
}
- read_unlock(&tunnel->hlist_lock);
+ read_unlock_irqrestore(&tunnel->hlist_lock, flags);
return NULL;
}
@@ -319,15 +320,16 @@ pppol2tp_session_find(struct pppol2tp_tu
static struct pppol2tp_tunnel *pppol2tp_tunnel_find(u16 tunnel_id)
{
struct pppol2tp_tunnel *tunnel = NULL;
+ unsigned long flags;
- read_lock(&pppol2tp_tunnel_list_lock);
+ read_lock_irqsave(&pppol2tp_tunnel_list_lock, flags);
list_for_each_entry(tunnel, &pppol2tp_tunnel_list, list) {
if (tunnel->stats.tunnel_id == tunnel_id) {
- read_unlock(&pppol2tp_tunnel_list_lock);
+ read_unlock_irqrestore(&pppol2tp_tunnel_list_lock, flags);
return tunnel;
}
}
- read_unlock(&pppol2tp_tunnel_list_lock);
+ read_unlock_irqrestore(&pppol2tp_tunnel_list_lock, flags);
return NULL;
}
@@ -1099,6 +1101,7 @@ static void pppol2tp_tunnel_closeall(str
struct hlist_node *tmp;
struct pppol2tp_session *session;
struct sock *sk;
+ unsigned long flags;
if (tunnel == NULL)
BUG();
@@ -1106,7 +1109,7 @@ static void pppol2tp_tunnel_closeall(str
PRINTK(tunnel->debug, PPPOL2TP_MSG_CONTROL, KERN_INFO,
"%s: closing all sessions...\n", tunnel->name);
- write_lock(&tunnel->hlist_lock);
+ write_lock_irqsave(&tunnel->hlist_lock, flags);
for (hash = 0; hash < PPPOL2TP_HASH_SIZE; hash++) {
again:
hlist_for_each_safe(walk, tmp, &tunnel->session_hlist[hash]) {
@@ -1126,7 +1129,7 @@ again:
* disappear as we're jumping between locks.
*/
sock_hold(sk);
- write_unlock(&tunnel->hlist_lock);
+ write_unlock_irqrestore(&tunnel->hlist_lock, flags);
lock_sock(sk);
if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND)) {
@@ -1148,11 +1151,11 @@ again:
* list so we are guaranteed to make forward
* progress.
*/
- write_lock(&tunnel->hlist_lock);
+ write_lock_irqsave(&tunnel->hlist_lock, flags);
goto again;
}
}
- write_unlock(&tunnel->hlist_lock);
+ write_unlock_irqrestore(&tunnel->hlist_lock, flags);
}
/* Really kill the tunnel.
@@ -1160,10 +1163,12 @@ again:
*/
static void pppol2tp_tunnel_free(struct pppol2tp_tunnel *tunnel)
{
+ unsigned long flags;
+
/* Remove from socket list */
- write_lock(&pppol2tp_tunnel_list_lock);
+ write_lock_irqsave(&pppol2tp_tunnel_list_lock, flags);
list_del_init(&tunnel->list);
- write_unlock(&pppol2tp_tunnel_list_lock);
+ write_unlock_irqrestore(&pppol2tp_tunnel_list_lock, flags);
atomic_dec(&pppol2tp_tunnel_count);
kfree(tunnel);
@@ -1212,6 +1217,7 @@ end:
static void pppol2tp_session_destruct(struct sock *sk)
{
struct pppol2tp_session *session = NULL;
+ unsigned long flags;
if (sk->sk_user_data != NULL) {
struct pppol2tp_tunnel *tunnel;
@@ -1239,9 +1245,9 @@ static void pppol2tp_session_destruct(st
/* Delete the session socket from the
* hash
*/
- write_lock(&tunnel->hlist_lock);
+ write_lock_irqsave(&tunnel->hlist_lock, flags);
hlist_del_init(&session->hlist);
- write_unlock(&tunnel->hlist_lock);
+ write_unlock_irqrestore(&tunnel->hlist_lock, flags);
atomic_dec(&pppol2tp_session_count);
}
@@ -1312,6 +1318,7 @@ static struct sock *pppol2tp_prepare_tun
struct sock *sk;
struct pppol2tp_tunnel *tunnel;
struct sock *ret = NULL;
+ unsigned long flags;
/* Get the tunnel UDP socket from the fd, which was opened by
* the userspace L2TP daemon.
@@ -1386,9 +1393,9 @@ static struct sock *pppol2tp_prepare_tun
/* Add tunnel to our list */
INIT_LIST_HEAD(&tunnel->list);
- write_lock(&pppol2tp_tunnel_list_lock);
+ write_lock_irqsave(&pppol2tp_tunnel_list_lock, flags);
list_add(&tunnel->list, &pppol2tp_tunnel_list);
- write_unlock(&pppol2tp_tunnel_list_lock);
+ write_unlock_irqrestore(&pppol2tp_tunnel_list_lock, flags);
atomic_inc(&pppol2tp_tunnel_count);
/* Bump the reference count. The tunnel context is deleted
@@ -1462,6 +1469,7 @@ static int pppol2tp_connect(struct socke
struct pppol2tp_tunnel *tunnel;
struct dst_entry *dst;
int error = 0;
+ unsigned long irqflags;
lock_sock(sk);
@@ -1593,11 +1601,11 @@ static int pppol2tp_connect(struct socke
sk->sk_user_data = session;
/* Add session to the tunnel's hash list */
- write_lock(&tunnel->hlist_lock);
+ write_lock_irqsave(&tunnel->hlist_lock, irqflags);
hlist_add_head(&session->hlist,
pppol2tp_session_id_hash(tunnel,
session->tunnel_addr.s_session));
- write_unlock(&tunnel->hlist_lock);
+ write_unlock_irqrestore(&tunnel->hlist_lock, irqflags);
atomic_inc(&pppol2tp_session_count);
@@ -2198,8 +2206,9 @@ static struct pppol2tp_session *next_ses
int found = 0;
int next = 0;
int i;
+ unsigned long flags;
- read_lock(&tunnel->hlist_lock);
+ read_lock_irqsave(&tunnel->hlist_lock, flags);
for (i = 0; i < PPPOL2TP_HASH_SIZE; i++) {
hlist_for_each_entry(session, walk, &tunnel->session_hlist[i], hlist) {
if (curr == NULL) {
@@ -2217,7 +2226,7 @@ static struct pppol2tp_session *next_ses
}
}
out:
- read_unlock(&tunnel->hlist_lock);
+ read_unlock_irqrestore(&tunnel->hlist_lock, flags);
if (!found)
session = NULL;
@@ -2227,14 +2236,15 @@ out:
static struct pppol2tp_tunnel *next_tunnel(struct pppol2tp_tunnel *curr)
{
struct pppol2tp_tunnel *tunnel = NULL;
+ unsigned long flags;
- read_lock(&pppol2tp_tunnel_list_lock);
+ read_lock_irqsave(&pppol2tp_tunnel_list_lock, flags);
if (list_is_last(&curr->list, &pppol2tp_tunnel_list)) {
goto out;
}
tunnel = list_entry(curr->list.next, struct pppol2tp_tunnel, list);
out:
- read_unlock(&pppol2tp_tunnel_list_lock);
+ read_unlock_irqrestore(&pppol2tp_tunnel_list_lock, flags);
return tunnel;
}
^ permalink raw reply
* [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 9:49 UTC (permalink / raw)
To: Greg KH
Cc: Jan-Bernd Themann, Thomas Klein, netdev, linux-kernel, linux-ppc,
Christoph Raisch
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.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Hi Greg,
are you the right person to address this patch to?
Regards,
Jan-Bernd
drivers/base/memory.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7ae413f..1e1bd4c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
{
return blocking_notifier_chain_register(&memory_chain, nb);
}
+EXPORT_SYMBOL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
blocking_notifier_chain_unregister(&memory_chain, nb);
}
+EXPORT_SYMBOL(unregister_memory_notifier);
/*
* register_memory - Setup a sysfs device for a memory block
--
1.5.2
^ permalink raw reply related
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Dave Hansen @ 2008-02-11 10:12 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Greg KH, Jan-Bernd Themann, Thomas Klein, netdev, linux-kernel,
linux-ppc, Christoph Raisch
In-Reply-To: <200802111049.05478.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> are you the right person to address this patch to?
You might want to check the top of the file. ;)
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> {
> return blocking_notifier_chain_register(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(register_memory_notifier);
>
> void unregister_memory_notifier(struct notifier_block *nb)
> {
> blocking_notifier_chain_unregister(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(unregister_memory_notifier);
Is there a particular reason these can't be GPL?
-- Dave
^ permalink raw reply
* Engress path / congestion detection and avoidance
From: Jeba Anandhan @ 2008-02-11 10:38 UTC (permalink / raw)
To: netdev; +Cc: matthew.hattersley
Hi All,
i have few doubts related to congestion and engress path.
1) What happens when congestion hits and how it affects engress path?.
2) How the engress traffic slow down when the congestion hits?
3) what are the variables updated when the congestion hits?
4) is it good to invoke netif_stop_queue when congestion hits?
thanks
Jeba
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 10:47 UTC (permalink / raw)
To: Dave Hansen
Cc: Greg KH, Jan-Bernd Themann, Thomas Klein, netdev, linux-kernel,
linux-ppc, Christoph Raisch
In-Reply-To: <1202724743.8276.2.camel@nimitz.home.sr71.net>
On Monday 11 February 2008 11:12, Dave Hansen wrote:
> On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > are you the right person to address this patch to?
>
> You might want to check the top of the file. ;)
>
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > {
> > return blocking_notifier_chain_register(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(register_memory_notifier);
> >
> > void unregister_memory_notifier(struct notifier_block *nb)
> > {
> > blocking_notifier_chain_unregister(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(unregister_memory_notifier);
>
> Is there a particular reason these can't be GPL?
>
I don't object to make them GPL. Greg, what do you think?
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [patch 2.6.24-git] net/enc28j60: oops fix, low power mode
From: Claudio Lanconelli @ 2008-02-11 12:07 UTC (permalink / raw)
To: David Brownell; +Cc: netdev
In-Reply-To: <200802100954.18225.david-b@pacbell.net>
David Brownell wrote:
>> > and in the enc28j60_net_close() after enc28j60_hw_disable().
>> > Probably we don't need to set_lowpower(false) in enc28j60_net_open() since
>> > it performs a soft reset with enc28j60_hw_init() (not sure).
>>
>
> The current patch sets the device in low power mode in hw_disable(),
> and takes it out of that mode in hw_enable(). I can move them; and
> the only "soft" thing about this chip's reset is when it starts from
> a protocol command not the reset command.
>
>
I want to mean the reset software command. It's functionally
equivalent to hardware system reset, but it seems to need exit low
power mode to work flawlessly.
I have tried your latest patch. Only after the following change it
works fine (no more rx errors during ifconfig up).
I added enc28j60_lowpower(false) just before enc28j60_hw_init()
@@ -1318,8 +1347,9 @@
}
return -EADDRNOTAVAIL;
}
- /* Reset the hardware here */
+ /* Reset the hardware here (and take it out of low power mode) */
enc28j60_hw_disable(priv);
+ enc28j60_lowpower(priv, false);
if (!enc28j60_hw_init(priv)) {
if (netif_msg_ifup(priv))
dev_err(&dev->dev, "hw_reset() failed\n");
With this addition you can add Acked-by line.
Thank you.
>> After a couple of :
>>
>> ifconfig eth0 down
>> (wait just 1 second)
>> ifconfig eth0 up
>>
>> the network is frozen.
>>
>> If I do another
>> ifconfig eth0 down
>> (wait just 1 second)
>> ifconfig eth0 up
>>
>> restarts.
>> It's random, no rule.
>>
>
> I write a shell loop to do that, and added a "ping -c2" too.
> If that was done before the "sleep 1" no packets flowed.
> Afterwards, no problem -- ever.
>
> (And outside the loop, "ethool -s eth1 duplex full".)
>
>
>
I forgot to tell that during my test I have a web server running on the
board and
a client continuously requesting a page.
^ permalink raw reply
* [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
From: Jarek Poplawski @ 2008-02-11 12:42 UTC (permalink / raw)
To: David Miller
Cc: Jann Traschewski, Bernard Pidoux F6BVP, Ralf Baechle DL5RB,
netdev
In-Reply-To: <000d01c86c8b$fd9e67d0$453c822c@dg8ngn>
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] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
From: Christian Borntraeger @ 2008-02-11 13:11 UTC (permalink / raw)
To: Avi Kivity; +Cc: dor.laor, Anthony Liguori, kvm-devel, virtualization, netdev
Avi,
this fixes a problem that was introduced by the virtio_reset patches.
Can you apply that fix to kvm.git as a bugfix, as the virtio_reset
infrastructure is not on Linus upstream yet?
Anthony, Dor,
are you ok with that change?
--
With the latest virtio_reset patches I got the following oops:
Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000
Oops: 0004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 Not tainted 2.6.24zlive-guest-10577-g63f5307-dirty #168
Process swapper (pid: 0, task: 000000000f866040, ksp: 000000000f86fd78)
Krnl PSW : 0404100180000000 000000000047598a (skb_recv_done+0x52/0x98)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000000 000000000efd0e60 0000000000000001
0000000000000000 000000000f866040 0000000000000000 0000000000000000
00000000008de4c8 0000000000001237 0000000000001237 000000000f977dd8
0000000000000020 00000000001132bc 000000000f977e08 000000000f977dd8
Krnl Code: 000000000047597c: e31040300004 lg %r1,48(%r4)
0000000000475982: b9040001 lgr %r0,%r1
0000000000475986: b9810003 ogr %r0,%r3
>000000000047598a: eb1040300030 csg %r1,%r0,48(%r4)
0000000000475990: a744fff9 brc 4,475982
0000000000475994: a7110001 tmll %r1,1
0000000000475998: a7840009 brc 8,4759aa
000000000047599c: e340b0b80004 lg %r4,184(%r11)
Call Trace:
([<000001500f978000>] 0x1500f978000)
[<00000000004779a6>] vring_interrupt+0x72/0x88
[<0000000000491d9c>] kvm_extint_handler+0x34/0x44
[<000000000010d2d4>] do_extint+0xc0/0xfc
[<0000000000113b5a>] ext_no_vtime+0x1c/0x20
[<000000000010a0b6>] cpu_idle+0x21a/0x230
We must initialize vdev->priv before we use the notify hypercall as
vdev->priv is used in skb_recv_done. So lets move the assignment of
vdev->priv before we call try_fill_recv.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/net/virtio_net.c
===================================================================
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -361,6 +361,7 @@ static int virtnet_probe(struct virtio_d
netif_napi_add(dev, &vi->napi, virtnet_poll, napi_weight);
vi->dev = dev;
vi->vdev = vdev;
+ vdev->priv = vi;
/* We expect two virtqueues, receive then send. */
vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
@@ -395,7 +396,6 @@ static int virtnet_probe(struct virtio_d
}
pr_debug("virtnet: registered device %s\n", dev->name);
- vdev->priv = vi;
return 0;
unregister:
^ permalink raw reply
* Re: Protocol handler for Marvell DSA EtherType packets
From: Jesper Dangaard Brouer @ 2008-02-11 13:18 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: David S. Miller
In-Reply-To: <1201872514.17661.50.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 5251 bytes --]
Hi NetDev and Google,
The answer to my question was:
Aha, you are trying to use tcpdump to see the "encapsulated" packets,
then you also need to adjust skb->mac.raw.
I have attached the code (and inlined the receive func, for easier
commenting), as I have another question:
I use dev_get_by_index() which calls dev_hold() (via my function
m88e_get_netdevice()).
The question is:
Should I use dev_put() before or after calling netif_rx(skb).
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
On Fri, 2008-02-01 at 14:28 +0100, Jesper Dangaard Brouer wrote:
> Hi Netdev
>
> I writing a new protocol handler using dev_add_pack(). (For a Marvell
> switch chip handling DSA (Distributed Switch Architecture) Ethertype
> packets).
>
> My protocol handler works and I get the skb. But I want to remove the
> DSA Headers and send the packet back for normal processing on a
> device. (I actually just want to be able to tcpdump these packets on
> the device).
>
> I'm removing the headers by:
> skb_pull(skb, sizeof(struct dsa_header));
>
> I'm trying to retransmit it by:
> netif_rx(skb);
>
> But it seems that I just retransmit the same packet without removing
> the DSA headers.
>
> Any hints about which functions I should use the remove the DSA header?
/*
* Main DSA Receive routine.
*/
int dsa_receive(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)
{
int res = NET_RX_SUCCESS;
struct dsa_header *dsa_hdr;
struct proto_header *proto_hdr;
struct net_device *port_dev; /* the port associated net_device*/
struct ethhdr *eth_hdr;
/*
if (skb->pkt_type == PACKET_OTHERHOST) VERBOSE("PACKET_OTHERHOST");
else if (skb->pkt_type == PACKET_BROADCAST) VERBOSE("PACKET_BROADCAST");
else if (skb->pkt_type == PACKET_MULTICAST) VERBOSE("PACKET_MULTICAST");
else if (skb->pkt_type == PACKET_HOST) VERBOSE("PACKET_HOST");
else VERBOSE("PACKET_TYPE UNKNOWN");
*/
// Access to the real mac header
eth_hdr = (struct ethhdr *)skb->mac.raw; // Same as eth_hdr(skb)
// At this point the Ethernet header has been removed, but the
// DSA EtherType header contains two extra reserved bytes,
// move the pointer past these.
//
// DEBUGOUT("Removing 2 reserved bytes from DSA EtherType tag");
skb_pull(skb, 2);
// Access to the DSA packet information
dsa_hdr = (struct dsa_header *) skb->data;
if (net_ratelimit()) {
printk(KERN_INFO);
printk("Dev:%s ", skb->dev->name);
printk("Type 0x%x ", dsa_hdr->type);
printk("Tagged 0x%x ", dsa_hdr->tagged);
// printk("Dev 0x%x ", dsa_hdr->dev);
printk("Port 0x%x ", dsa_hdr->port);
printk("Info 0x%x ", dsa_hdr->info);
printk("Prio 0x%x ", dsa_hdr->pri);
printk("Res 0x%x ", dsa_hdr->res);
printk("VLAN ID 0x%x ",dsa_hdr->vid);
printk("\n");
}
// Decoding the DSA type
switch(dsa_hdr->type) {
case DSA_TO_CPU:
{
int code = ((dsa_hdr->info)&0x06)|dsa_hdr->res;
if(IGMP_TRAP == code) {
printk("IGMP Trap\n");
} else {
printk("Unsupported code %d\n",code);
}
break;
}
case DSA_FROM_CPU:
/*Fall through*/
case DSA_TO_SNIFFER:
/*Fall through*/
if (net_ratelimit())
DEBUGOUT("Sniffer packet");
break;
case DSA_FORWARD:
/*Fall through*/
default:
break;
}
// Find the device associated with the switch port.
//
// Q: m88e_get_netdevice() calls dev_get_by_index(), which it calls dev_hold()
port_dev = m88e_get_netdevice(dsa_hdr->port);
skb->dev = port_dev;
// Move past the DSA header
skb_pull(skb, sizeof(struct dsa_header));
// TEST: if it possible to change some skb data and see it in tcpdump
// eth_hdr->h_proto = 0x9111;
/* Extract the ethertype of the encapsulated packet, and
indicate the protocol to the next layer. */
proto_hdr = (struct proto_header*) skb->data;
skb->protocol = proto_hdr->h_proto;
if (net_ratelimit())
printk(KERN_ERR "Encapsulated packet Protocol 0x%x\n",skb->protocol);
// HACK, shift the mac header, this allows packet sniffers to
// decode the packet as a normal ethernet packet, but the mac
// address will not be correct.
skb->mac.raw = skb->data - (6+6);
// Q: Is it allowed to modify the skb data, I would like to
// correct the MAC headers, but is that allowed? Do I need to
// skb_copy the packet?
// Move past the EtherType of the encapsulated packet
skb_pull(skb, sizeof(struct proto_header));
// FIXME: Perhaps we need to change skb->pkt_type to
// PACKET_HOST, to make the next protocol handlers
// accept/process the data???
//skb->pkt_type = PACKET_HOST;
// Retransmit it on a virtual switch port device... this will
// e.g. send it to the IGMP protocol handler.
res = netif_rx(skb);
// Release the device pointer
if (port_dev)
dev_put(port_dev);
return res;
drop:
kfree_skb(skb);
out:
return NET_RX_DROP;
}
static struct packet_type dsa_packet_type =
{
.type = __constant_htons(ETHERTYPE_DSA),
.dev = NULL, /* NULL is wildcarded interfaces */
.func = dsa_receive,
.data = NULL,
//.data = (void*)1, /* Set here '(void *)1' when this code can SHARE SKBs */
.next = NULL
};
[-- Attachment #2: ethertype_dsa.c --]
[-- Type: text/x-csrc, Size: 6773 bytes --]
/*
* Marvell DSA (Distributed Switch Architecture) Ethertype handling.
*
* Some Marvell switch chips support to send/trap/mirror special
* packets to another switch port. These special packets can contain
* some extra information stored in (whats called) a DSA tag. The
* chip also supports adding a special EtherType in front of the DSA
* tag, allowing a CPU (which attached to one of the switch ports)
* easier identification of DSA frames.
*
* Copyright (C) Jesper Dangaard Brouer, Visipia Aps.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* SVN version info:
* $LastChangedDate: 2008-02-11 11:11:28 +0100 (Mon, 11 Feb 2008) $
* $LastChangedRevision: 5238 $
* $LastChangedBy: jdb $
*
*/
#include <linux/module.h>
#include <linux/kernel.h>
#include "ethertype_dsa.h"
#define MODULE_NAME "m88e_DSA"
#define M88E_DEBUG 1
#define M88E_VERBOSE 1
#include "m88e.h"
#ifndef NOTICE /* Handle if "m88e.h" debug macros are not included */
#define NOTICE(S) printk(KERN_NOTICE "NOTICE: " S "\n")
#define DEBUGOUT(S) printk(KERN_DEBUG S "\n")
#define DEBUGOUT1(S, A...) printk(KERN_DEBUG S "\n", A)
#endif/*NOTICE*/
#include <linux/netdevice.h> /* struct packet_type */
#include <linux/if_ether.h> /* struct ethhdr */
#include "m88e_dev.h" /* Access to port associated net_device's */
/*
Default EtherType set by Marvell is 0x9100, this should be changed
1) because its conflicts with double-tagging of VLANs
2) because it hits the same EtherType hash bucket (ptype_base) as IP and VLAN
*/
#define ETHERTYPE_DSA 0x9100
struct proto_header
{
unsigned short h_proto; /* packet type ID field */
} __attribute__((packed));
/*
* Main DSA Receive routine.
*/
int dsa_receive(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)
{
int res = NET_RX_SUCCESS;
struct dsa_header *dsa_hdr;
struct proto_header *proto_hdr;
struct net_device *port_dev; /* the port associated net_device*/
struct ethhdr *eth_hdr;
/*
if (skb->pkt_type == PACKET_OTHERHOST) VERBOSE("PACKET_OTHERHOST");
else if (skb->pkt_type == PACKET_BROADCAST) VERBOSE("PACKET_BROADCAST");
else if (skb->pkt_type == PACKET_MULTICAST) VERBOSE("PACKET_MULTICAST");
else if (skb->pkt_type == PACKET_HOST) VERBOSE("PACKET_HOST");
else VERBOSE("PACKET_TYPE UNKNOWN");
*/
// Access to the real mac header
eth_hdr = (struct ethhdr *)skb->mac.raw; // Same as eth_hdr(skb)
// At this point the Ethernet header has been removed, but the
// DSA EtherType header contains two extra reserved bytes,
// move the pointer past these.
//
// DEBUGOUT("Removing 2 reserved bytes from DSA EtherType tag");
skb_pull(skb, 2);
// Access to the DSA packet information
dsa_hdr = (struct dsa_header *) skb->data;
if (net_ratelimit()) {
printk(KERN_INFO);
printk("Dev:%s ", skb->dev->name);
printk("Type 0x%x ", dsa_hdr->type);
printk("Tagged 0x%x ", dsa_hdr->tagged);
// printk("Dev 0x%x ", dsa_hdr->dev);
printk("Port 0x%x ", dsa_hdr->port);
printk("Info 0x%x ", dsa_hdr->info);
printk("Prio 0x%x ", dsa_hdr->pri);
printk("Res 0x%x ", dsa_hdr->res);
printk("VLAN ID 0x%x ",dsa_hdr->vid);
printk("\n");
}
// Decoding the DSA type
switch(dsa_hdr->type) {
case DSA_TO_CPU:
{
int code = ((dsa_hdr->info)&0x06)|dsa_hdr->res;
if(IGMP_TRAP == code) {
printk("IGMP Trap\n");
} else {
printk("Unsupported code %d\n",code);
}
break;
}
case DSA_FROM_CPU:
/*Fall through*/
case DSA_TO_SNIFFER:
/*Fall through*/
if (net_ratelimit())
DEBUGOUT("Sniffer packet");
break;
case DSA_FORWARD:
/*Fall through*/
default:
break;
}
// Find the device associated with the switch port.
port_dev = m88e_get_netdevice(dsa_hdr->port);
skb->dev = port_dev;
// Move past the DSA header
skb_pull(skb, sizeof(struct dsa_header));
// TEST: if it possible to change some skb data and see it in tcpdump
// eth_hdr->h_proto = 0x9111;
/* Extract the ethertype of the encapsulated packet, and
indicate the protocol to the next layer. */
proto_hdr = (struct proto_header*) skb->data;
skb->protocol = proto_hdr->h_proto;
if (net_ratelimit())
printk(KERN_ERR "Encapsulated packet Protocol 0x%x\n",skb->protocol);
// HACK, shift the mac header, this allows packet sniffers to
// decode the packet as a normal ethernet packet, but the mac
// address will not be correct.
skb->mac.raw = skb->data - (6+6);
// Q: Is it allowed to modify the skb data, I would like to
// correct the MAC headers, but is that allowed? Do I need to
// skb_copy the packet?
// Move past the EtherType of the encapsulated packet
skb_pull(skb, sizeof(struct proto_header));
// FIXME: Perhaps we need to change skb->pkt_type to
// PACKET_HOST, to make the next protocol handlers
// accept/process the data???
//skb->pkt_type = PACKET_HOST;
// Retransmit it on a virtual switch port device... this will
// e.g. send it to the IGMP protocol handler.
res = netif_rx(skb);
// Release the device pointer
if (port_dev)
dev_put(port_dev);
return res;
drop:
kfree_skb(skb);
out:
return NET_RX_DROP;
}
static struct packet_type dsa_packet_type =
{
.type = __constant_htons(ETHERTYPE_DSA),
.dev = NULL, /* NULL is wildcarded interfaces */
.func = dsa_receive,
.data = NULL,
//.data = (void*)1, /* Set here '(void *)1' when this code can SHARE SKBs */
.next = NULL
};
void dsa_register_handler(void)
{
// Only process DSA packets on CPU to switch device, trying to
// avoid loops.
dsa_packet_type.dev = dev_get_by_name("ixp1");
// TODO: Increase the MTU on the receiving device, the DSA
// EtherType is 4 bytes and the DSA info is 4 bytes.
NOTICE("Register: DSA EtherType packet handler");
dev_add_pack(&dsa_packet_type);
}
void dsa_unregister_handler(void)
{
NOTICE("Unregister: DSA EtherType packet handler");
dev_remove_pack(&dsa_packet_type);
}
[-- Attachment #3: ethertype_dsa.h --]
[-- Type: text/x-chdr, Size: 2018 bytes --]
/*
* Marvell DSA (Distributed Switch Architecture) Ethertype handling.
*
* Copyright (C) Jesper Dangaard Brouer, Visipia Aps.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* SVN version info:
* $LastChangedDate: 2008-02-11 11:11:28 +0100 (Mon, 11 Feb 2008) $
* $LastChangedRevision: 5238 $
* $LastChangedBy: jdb $
*
*/
#ifndef _ethertype_dsa_H_
#define _ethertype_dsa_H_
#include <linux/types.h>
#include <asm/byteorder.h>
struct dsa_header {
__u8 type:2,
tagged:1,
dev:5;
__u8 port:5,
info:3; // Decoding dependent on type
#if defined(__BIG_ENDIAN_BITFIELD)
__u16 pri:3,
res:1,
vid:12;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
#error "Not defined for Little Endian CPUs"
#else
#error "Adjust your <asm/byteorder.h> defines"
#endif
};
// DSA Tag Types
enum {
DSA_TO_CPU = 0x0, // b00
DSA_FROM_CPU = 0x1, // b01
DSA_TO_SNIFFER = 0x2, // b10
DSA_FORWARD = 0x3, // b11
};
// DSA_TO_CPU Support codes
enum {
BDPU_TRAP = 0x0, // b000
FRAME2REG_RESPONSE = 0x1, // b001
IGMP_TRAP = 0x2, // b010
POLICY_TRAP = 0x3, // b011
ARP_MIRROR = 0x4, // b100
POLICY_MIRROR = 0x5, // b101
};
extern void dsa_register_handler (void);
extern void dsa_unregister_handler(void);
#endif
^ permalink raw reply
* AW: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
From: Reither Robert @ 2008-02-11 14:26 UTC (permalink / raw)
To: David Stevens; +Cc: netdev
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0, Stand G16
________________________________________________________________________
Hi David,
thanks for your help. Your input is always welcome ;-)
But according to Linux Programmer's Manual it should be OK to use ifindex of 0
e.g. (http://www.rt.com/man/ip.4.html)
but maybe this document is depcecated/obsolte ...
Well anyway, i did what u suggested, used eth0.3 as interface (i'm using VLAN)
Setting ifindex to eth0 won't help .. strange, but well ...,
maybe receiving is blocked by the virtual interface somehow, should be.
The problem is, now i get unreliable results.
At first attempt, it always worked as before with ifindex=0, but now further attempts SOMETIMES works !!!
Every 3rd or forth attempt i can receive the packets. (this way maybe the same with old method, i'll investigate further)
But netstat always shows the join (and the absence, if i close socket/leave mc-group)
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 224.0.0.1
eth0 1 224.0.0.1
eth0.3 1 224.1.9.0
eth0.3 1 224.0.0.1
Do u know a way to debug this further ?
It's not so easy for me to build a small app to show the faulty behav, but i'll try.
Robert
-----Ursprüngliche Nachricht-----
Von: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org]Im Auftrag von David Stevens
Gesendet: Donnerstag, 07. Februar 2008 17:09
An: Reither Robert
Cc: netdev@vger.kernel.org
Betreff: Re: Problem receiving multicast/promiscuous-mode with
kernel.2.6.24
You need to join the multicast group on the interface you want
to receive it. If you're setting both imr_address and imr_index
to 0, you haven't specified an interface.
Instead of setting imr_ifindex to 0, try setting it like this:
imr.imr_ifindex = if_nametoindex("eth0");
(or whatever interface you need).
You can verify that you've joined the group on the correct
interface with "netstat -g", also. Make sure that the interface
field is correct for the group you want.
And because I can't resist mentioning it, "inet_aton" is deprecated--
suggest inet_pton() with appropriate arguments and return value
checking instead.
There was a bug fix where the sense of promiscuous mode was
backwards for multicasting, which is probably why it was accidently
(and incorrectly) working in earlier kernels.
If that doesn't do it for you, let me know; better if you can post the
full code (or even better, the smallest subset that demonstrates the
problem).
+-DLS
--
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
* Re: oops with ipcomp
From: Beschorner Daniel @ 2008-02-11 15:03 UTC (permalink / raw)
To: netdev; +Cc: Herbert Xu
> Does every packet from A trigger the crash?
In my last test the crash was triggered after 300MB of http output (on
the fifth run of a script downloading the same 60MB of data).
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Greg KH @ 2008-02-11 15:22 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Jan-Bernd Themann, netdev, Dave Hansen, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch
In-Reply-To: <200802111147.51225.ossthema@de.ibm.com>
On Mon, Feb 11, 2008 at 11:47:50AM +0100, Jan-Bernd Themann wrote:
> On Monday 11 February 2008 11:12, Dave Hansen wrote:
> > On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > > are you the right person to address this patch to?
> >
> > You might want to check the top of the file. ;)
> >
> > > --- a/drivers/base/memory.c
> > > +++ b/drivers/base/memory.c
> > > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > > {
> > > return blocking_notifier_chain_register(&memory_chain, nb);
> > > }
> > > +EXPORT_SYMBOL(register_memory_notifier);
> > >
> > > void unregister_memory_notifier(struct notifier_block *nb)
> > > {
> > > blocking_notifier_chain_unregister(&memory_chain, nb);
> > > }
> > > +EXPORT_SYMBOL(unregister_memory_notifier);
> >
> > Is there a particular reason these can't be GPL?
> >
>
> I don't object to make them GPL. Greg, what do you think?
They should be _GPL to match the rest of the driver core.
Care to resend this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/5] Tsi108_eth: add missing linking to driver data
From: Jeff Garzik @ 2008-02-11 15:28 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: netdev, linuxppc-dev, Josh Boyer, Zang Roy-r61911
In-Reply-To: <1B5F013528140F45B5C671039279CA5702A9609F@NANUK.pc.tundra.com>
Alexandre Bounine wrote:
> Bug fix for tsi108_eth network driver.
> This patch adds missing linking to driver data.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> ---
>
> diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
> linux-2.6.24-fix/drivers/net/tsi108_eth.c
> --- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24
> 17:58:37.000000000 -0500
> +++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
> 14:30:04.000000000 -0500
> @@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
> goto register_fail;
> }
>
> + platform_set_drvdata(pdev, dev);
> printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
> dev->name, print_mac(mac, dev->dev_addr));
> #ifdef DEBUG
ACK, but your patches are unusable because they are word-wrapped
^ permalink raw reply
* Re: [PATCH] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
From: Anthony Liguori @ 2008-02-11 15:29 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Avi Kivity, dor.laor, kvm-devel, virtualization, netdev
In-Reply-To: <200802111411.15745.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> Avi,
> this fixes a problem that was introduced by the virtio_reset patches.
> Can you apply that fix to kvm.git as a bugfix, as the virtio_reset
> infrastructure is not on Linus upstream yet?
>
The reset support is in Linus's tree so we should try to push it for -rc2.
> Anthony, Dor,
> are you ok with that change?
>
Yes.
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
Regards,
Anthony Liguori
> --
>
> With the latest virtio_reset patches I got the following oops:
>
> Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000
> Oops: 0004 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 1 Not tainted 2.6.24zlive-guest-10577-g63f5307-dirty #168
> Process swapper (pid: 0, task: 000000000f866040, ksp: 000000000f86fd78)
> Krnl PSW : 0404100180000000 000000000047598a (skb_recv_done+0x52/0x98)
> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
> Krnl GPRS: 0000000000000001 0000000000000000 000000000efd0e60 0000000000000001
> 0000000000000000 000000000f866040 0000000000000000 0000000000000000
> 00000000008de4c8 0000000000001237 0000000000001237 000000000f977dd8
> 0000000000000020 00000000001132bc 000000000f977e08 000000000f977dd8
> Krnl Code: 000000000047597c: e31040300004 lg %r1,48(%r4)
> 0000000000475982: b9040001 lgr %r0,%r1
> 0000000000475986: b9810003 ogr %r0,%r3
> >000000000047598a: eb1040300030 csg %r1,%r0,48(%r4)
> 0000000000475990: a744fff9 brc 4,475982
> 0000000000475994: a7110001 tmll %r1,1
> 0000000000475998: a7840009 brc 8,4759aa
> 000000000047599c: e340b0b80004 lg %r4,184(%r11)
> Call Trace:
> ([<000001500f978000>] 0x1500f978000)
> [<00000000004779a6>] vring_interrupt+0x72/0x88
> [<0000000000491d9c>] kvm_extint_handler+0x34/0x44
> [<000000000010d2d4>] do_extint+0xc0/0xfc
> [<0000000000113b5a>] ext_no_vtime+0x1c/0x20
> [<000000000010a0b6>] cpu_idle+0x21a/0x230
>
>
> We must initialize vdev->priv before we use the notify hypercall as
> vdev->priv is used in skb_recv_done. So lets move the assignment of
> vdev->priv before we call try_fill_recv.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> drivers/net/virtio_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: kvm/drivers/net/virtio_net.c
> ===================================================================
> --- kvm.orig/drivers/net/virtio_net.c
> +++ kvm/drivers/net/virtio_net.c
> @@ -361,6 +361,7 @@ static int virtnet_probe(struct virtio_d
> netif_napi_add(dev, &vi->napi, virtnet_poll, napi_weight);
> vi->dev = dev;
> vi->vdev = vdev;
> + vdev->priv = vi;
>
> /* We expect two virtqueues, receive then send. */
> vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
> @@ -395,7 +396,6 @@ static int virtnet_probe(struct virtio_d
> }
>
> pr_debug("virtnet: registered device %s\n", dev->name);
> - vdev->priv = vi;
> return 0;
>
> unregister:
>
^ permalink raw reply
* Re: [PATCH 2.6.24] pcnet32: use NET_IP_ALIGN instead of 2
From: Jeff Garzik @ 2008-02-11 15:30 UTC (permalink / raw)
To: Don Fry; +Cc: netdev
In-Reply-To: <1202484746.10535.7.camel@new-host.home>
Don Fry wrote:
> Change hard coded 2 to NET_IP_ALIGN. Added new #define with comments.
> Tested amd_64
>
> Signed-off-by: Don Fry <pcnet32@verizon.net>
applied both
^ permalink raw reply
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