* RE: [PATCHv4 NEXT 1/1] net: ethtool support to configure number of channels
From: Amit Salecha @ 2011-04-13 9:45 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, Ameen Rahman, Sucheta Chakraborty,
Anirban Chakraborty
In-Reply-To: <1302177522-17815-1-git-send-email-amit.salecha@qlogic.com>
> Ethtool support to configure RX, TX and other channels. combined field
> in struct ethtool_channels to reflect set of channel (RX, TX or other).
> Other channel can be link interrupts, SR-IOV coordination etc.
>
> ETHTOOL_GCHANNELS will report max and current number of RX channels,
> max and current number of TX channels, max and current number of other
> channel
> or max and current number of combined channel.
>
> Number of channel can be modify upto max number of channel through
> ETHTOOL_SCHANNELS command.
>
> Ben Hutchings:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up
> RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Neither I see this patch in http://patchwork.ozlabs.org/project/netdev/list/ nor any comment.
Just curious, is this patch discarded along with my other garbage patches ?
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* [PATCH] net: can: mscan: fix build breakage in mpc5xxx_can
From: Anatolij Gustschin @ 2011-04-13 9:49 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Grant Likely
Commit 74888760d40b3ac9054f9c5fa07b566c0676ba2d
"dt/net: Eliminate users of of_platform_{,un}register_driver"
broke building mscan driver. Fix it.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/can/mscan/mpc5xxx_can.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index c0a1bc5..bd1d811 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -260,7 +260,7 @@ static int __devinit mpc5xxx_can_probe(struct platform_device *ofdev)
if (!ofdev->dev.of_match)
return -EINVAL;
- data = (struct mpc5xxx_can_data *)of_dev->dev.of_match->data;
+ data = (struct mpc5xxx_can_data *)ofdev->dev.of_match->data;
base = of_iomap(np, 0);
if (!base) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: can: mscan: fix build breakage in mpc5xxx_can
From: Wolfgang Grandegger @ 2011-04-13 10:17 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: netdev, David S. Miller, Grant Likely
In-Reply-To: <1302688168-26862-1-git-send-email-agust@denx.de>
On 04/13/2011 11:49 AM, Anatolij Gustschin wrote:
> Commit 74888760d40b3ac9054f9c5fa07b566c0676ba2d
> "dt/net: Eliminate users of of_platform_{,un}register_driver"
> broke building mscan driver. Fix it.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
^ permalink raw reply
* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Alexey Dobriyan @ 2011-04-13 10:29 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, netdev, Pavel Kankovsky, Solar Designer, Kees Cook,
Dan Rosenberg, Eugene Teo, Nelson Elhage, David S. Miller,
Alexey Kuznetsov, Pekka Savola, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <20110409101514.GA4262@albatros>
On Sat, Apr 9, 2011 at 1:15 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
> This patch adds IPPROTO_ICMP socket kind.
> + seq_printf(f, "%5d: %08X:%04X %08X:%04X"
> + " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d%n",
> + bucket, src, srcp, dest, destp, sp->sk_state,
> + sk_wmem_alloc_get(sp),
> + sk_rmem_alloc_get(sp),
> + 0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
These zeroes can be embedded into format string for slightly faster printing.
> +static const struct file_operations ping_seq_fops = {
> + .owner = THIS_MODULE,
Unnecessary line.
->owner is unused for proc files, this is not documented anywhere, but
it's unused.
> + .open = ping_seq_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = seq_release_net,
> +};
> +
> +static const char ping_proc_name[] = "icmp";
Ewww :-)
Does not compiler create only one string?
> +static int ping_proc_register(struct net *net)
> +{
> + struct proc_dir_entry *p;
> + int rc = 0;
> +
> + p = proc_create_data(ping_proc_name, S_IRUGO, net->proc_net,
> + &ping_seq_fops, NULL);
There is proc_net_fops_create().
> + if (!p)
> + rc = -ENOMEM;
> + return rc;
> +}
> @@ -680,6 +747,15 @@ static struct ctl_table ipv4_net_table[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec
> },
> +#ifdef CONFIG_IP_PING
> + {
> + .procname = "ping_group_range",
> + .data = &init_net.ipv4.sysctl_ping_group_range,
> + .maxlen = sizeof(init_net.ipv4.sysctl_ping_group_range),
> + .mode = 0644,
> + .proc_handler = ipv4_ping_group_range,
> + },
> +#endif
> { }
> };
>
> @@ -714,8 +790,22 @@ static __net_init int ipv4_sysctl_init_net(struct net *net)
> &net->ipv4.sysctl_icmp_ratemask;
> table[6].data =
> &net->ipv4.sysctl_rt_cache_rebuild_count;
> +#ifdef CONFIG_IP_PING
> + table[7].data =
> + &net->ipv4.sysctl_ping_group_range;
> +#endif
Now I understand it's not related, but next sysctl will have
"table[8].data = ..." line which is off-by-one if CONFIG_IP_PING=n.
^ permalink raw reply
* [net-next-2.6] if_vlan.h: fix compile errors
From: Jeff Kirsher @ 2011-04-13 10:32 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, jpirko
The following commit generates compile errors becuase vlan_untag was defined
multiple times.
commit bcc6d47903612c3861201cc3a866fb604f26b8b2
Author: Jiri Pirko <jpirko@redhat.com>
Date: Thu Apr 7 19:48:33 2011 +0000
net: vlan: make non-hw-accel rx path similar to hw-accel
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
include/linux/if_vlan.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 998b299..546d9d3 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -174,7 +174,7 @@ static inline bool vlan_do_receive(struct sk_buff **skb)
return false;
}
-inline struct sk_buff *vlan_untag(struct sk_buff *skb)
+static inline struct sk_buff *vlan_untag(struct sk_buff *skb)
{
return skb;
}
--
1.7.4.2
^ permalink raw reply related
* Re: [PATCH] net: can: mscan: fix build breakage in mpc5xxx_can
From: Marc Kleine-Budde @ 2011-04-13 10:47 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: netdev, David S. Miller, Grant Likely
In-Reply-To: <1302688168-26862-1-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On 04/13/2011 11:49 AM, Anatolij Gustschin wrote:
> Commit 74888760d40b3ac9054f9c5fa07b566c0676ba2d
> "dt/net: Eliminate users of of_platform_{,un}register_driver"
> broke building mscan driver. Fix it.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [net-next-2.6] if_vlan.h: fix compile errors
From: Jiri Pirko @ 2011-04-13 10:57 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1302690737-14524-1-git-send-email-jeffrey.t.kirsher@intel.com>
Thanks Jeff, this fix was already submitted by DaveM
Wed, Apr 13, 2011 at 12:32:17PM CEST, jeffrey.t.kirsher@intel.com wrote:
>The following commit generates compile errors becuase vlan_untag was defined
>multiple times.
>
> commit bcc6d47903612c3861201cc3a866fb604f26b8b2
> Author: Jiri Pirko <jpirko@redhat.com>
> Date: Thu Apr 7 19:48:33 2011 +0000
>
> net: vlan: make non-hw-accel rx path similar to hw-accel
>
>Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>---
> include/linux/if_vlan.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
>index 998b299..546d9d3 100644
>--- a/include/linux/if_vlan.h
>+++ b/include/linux/if_vlan.h
>@@ -174,7 +174,7 @@ static inline bool vlan_do_receive(struct sk_buff **skb)
> return false;
> }
>
>-inline struct sk_buff *vlan_untag(struct sk_buff *skb)
>+static inline struct sk_buff *vlan_untag(struct sk_buff *skb)
> {
> return skb;
> }
>--
>1.7.4.2
>
^ permalink raw reply
* Re: [net-next-2.6] if_vlan.h: fix compile errors
From: Jeff Kirsher @ 2011-04-13 11:03 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev
In-Reply-To: <20110413105758.GA2910@psychotron.orion>
On Wed, Apr 13, 2011 at 03:57, Jiri Pirko <jpirko@redhat.com> wrote:
> Thanks Jeff, this fix was already submitted by DaveM
Ah, ok. I did not see anything in netdev patchworks and I did a
recent pull of Dave's net-next tree so I knew I had the latest.
Good to know it was caught, thanks Jiri.
>
> Wed, Apr 13, 2011 at 12:32:17PM CEST, jeffrey.t.kirsher@intel.com wrote:
>>The following commit generates compile errors becuase vlan_untag was defined
>>multiple times.
>>
>> commit bcc6d47903612c3861201cc3a866fb604f26b8b2
>> Author: Jiri Pirko <jpirko@redhat.com>
>> Date: Thu Apr 7 19:48:33 2011 +0000
>>
>> net: vlan: make non-hw-accel rx path similar to hw-accel
>>
>>Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>---
>> include/linux/if_vlan.h | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>>diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
>>index 998b299..546d9d3 100644
>>--- a/include/linux/if_vlan.h
>>+++ b/include/linux/if_vlan.h
>>@@ -174,7 +174,7 @@ static inline bool vlan_do_receive(struct sk_buff **skb)
>> return false;
>> }
>>
>>-inline struct sk_buff *vlan_untag(struct sk_buff *skb)
>>+static inline struct sk_buff *vlan_untag(struct sk_buff *skb)
>> {
>> return skb;
>> }
^ permalink raw reply
* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Vasiliy Kulikov @ 2011-04-13 11:22 UTC (permalink / raw)
To: David Miller
Cc: solar, linux-kernel, netdev, peak, kees.cook, dan.j.rosenberg,
eugene, nelhage, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20110412.142534.183049889.davem@davemloft.net>
On Tue, Apr 12, 2011 at 14:25 -0700, David Miller wrote:
> I have no fundamental objections to this change and I'll be happy to
> apply it after we iron out a few details.
Great!
> First, please get rid of the debug option, we have pr_debug() which can
> be dynamically turned on and off at run time these days.
OK.
> Second, if this is a bonafide core facility we'd like everyone to use,
> let's make it so. I want it so that every ping binary can expect this
> facility to be there if the kernel is new enough.
>
> So let's get rid of the config option.
OK.
> Finally, longer term, I'd really like to see ipv6 support for this
> feature as well.
Definitely.
For ICMPv6 we should recognize what message types are OK to send by
non-root users and what types are privileged. We just didn't do this
yet.
Thank you for the review,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Vasiliy Kulikov @ 2011-04-13 11:32 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-kernel, netdev, Pavel Kankovsky, Solar Designer, Kees Cook,
Dan Rosenberg, Eugene Teo, Nelson Elhage, David S. Miller,
Alexey Kuznetsov, Pekka Savola, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <BANLkTi=ogJg_uJqsJFpnwnnr6LS+SFT3Vg@mail.gmail.com>
On Wed, Apr 13, 2011 at 13:29 +0300, Alexey Dobriyan wrote:
> On Sat, Apr 9, 2011 at 1:15 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
> > This patch adds IPPROTO_ICMP socket kind.
>
> > + seq_printf(f, "%5d: %08X:%04X %08X:%04X"
> > + " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d%n",
> > + bucket, src, srcp, dest, destp, sp->sk_state,
> > + sk_wmem_alloc_get(sp),
> > + sk_rmem_alloc_get(sp),
> > + 0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
>
> These zeroes can be embedded into format string for slightly faster printing.
Is it really needed? I mean, it is not a fast path, so such a small
overhead is not very bad. But embedding them into the string makes it a
bit more difficult to read.
> > +static const struct file_operations ping_seq_fops = {
> > + .owner = THIS_MODULE,
>
> Unnecessary line.
> ->owner is unused for proc files, this is not documented anywhere, but
> it's unused.
OK.
> > +static const char ping_proc_name[] = "icmp";
>
> Ewww :-)
> Does not compiler create only one string?
I used it for better readability as it is used 2 times.
> > + p = proc_create_data(ping_proc_name, S_IRUGO, net->proc_net,
> > + &ping_seq_fops, NULL);
>
> There is proc_net_fops_create().
OK.
> > +#ifdef CONFIG_IP_PING
> > + table[7].data =
> > + &net->ipv4.sysctl_ping_group_range;
> > +#endif
>
> Now I understand it's not related, but next sysctl will have
> "table[8].data = ..." line which is off-by-one if CONFIG_IP_PING=n.
Agreed that hardcoded indexes look a bit ugly, especially with
configurable elements. But as Dave suggested to completely remove
CONFIG_IP_PING, it doesn't make sense now.
Thank you,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [Patch] iwlwifi: remove obsoleted module alias and parameters
From: Cong Wang @ 2011-04-13 11:53 UTC (permalink / raw)
To: John W. Linville
Cc: Stanislaw Gruszka, Johannes Berg, linux-wireless, netdev,
Intel Linux Wireless, Wey-Yi Guy, Meenakshi Venkataraman,
Larry Finger
In-Reply-To: <20110412204941.GD24309@tuxdriver.com>
于 2011年04月13日 04:49, John W. Linville 写道:
> On Wed, Apr 06, 2011 at 02:57:29PM +0200, Stanislaw Gruszka wrote:
>> On Wed, Apr 06, 2011 at 06:42:48PM +0800, Cong Wang wrote:
>>> 于 2011年04月06日 18:09, Johannes Berg 写道:
>>>> On Wed, 2011-04-06 at 17:49 +0800, Amerigo Wang wrote:
>>>>> As scheduled in Documentation/feature-removal-schedule.txt,
>>>>> remove "*50", "disable_hw_scan" module parameters and MODULE_ALIAS("iwl4965").
>>>>
>>>> Mostly fine, but for iwlegacy Stanislaw we want to keep hw scan (and it
>>>> was actually made default now)
>>
>> Indeed, disable_hw_scan should be removed in iwlwifi but leaved in iwlegacy.
>>
>>> Ok, I will wait for Stanislaw's response and then send an updated patch.
>>
>> Have it now :-)
>
> Ping?
>
Huh?
The same patch from Wey-yi was merged as commit#7eaa6a5e964f1ab02d849bda36950c0d30be8ce2,
no?
^ permalink raw reply
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Daniel Baluta @ 2011-04-13 11:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <1302663608.2811.62.camel@edumazet-laptop>
Hi Eric, Cyril,
>> Since SO_REUSEPORT is not a 'stable fix', I suggest we revert the patch,
>> and eventually work on SO_REUSEPORT on net-next-2.6
>>
>> What do you think ?
>>
>
> Sorry, I should have mentioned commit id : c191a836a908d1dd6
> (tcp: disallow bind() to reuse addr/port)
Cyril's use case looks suspect. I don't think that this is a good
reason for reverting this commit.
I would love to help on adding SO_REUSEPORT option in kernel.
thanks,
Daniel.
^ permalink raw reply
* Re: [PATCH 0/4] [RFC rev2] Implement multiqueue (RX & TX) virtio-net
From: Avi Kivity @ 2011-04-13 12:00 UTC (permalink / raw)
To: Krishna Kumar
Cc: rusty, davem, mst, eric.dumazet, arnd, netdev, horms, anthony,
kvm
In-Reply-To: <20110405150826.20501.39679.sendpatchset@krkumar2.in.ibm.com>
On 04/05/2011 06:08 PM, Krishna Kumar wrote:
> This patchset implements both RX and TX MQ. Patch against virtio-net,
> vhost and qemu are included.
>
> Changes from rev1:
> -------------------
> 1. vqs are allocated as: rx/tx, rx/tx, rx/tx, etc. Lot of code in
> guest/host/qemu changes, but code becomes simpler.
> 2. vhost cache align of vhost_dev correctly.
> 3. virtio-net: cleanup properly on errors (eg detach buf for vq>0 as
> pointed out by Micheal).
> 4. Minor changes:
> - Fixed some typos.
> - Changed vhost_get_thread_index to use MAX_VHOST_THREADS.
> - Removed VIRTIO_MAX_TXQS.
> - Changed capability to VIRTIO_NET_F_MULTIQUEUE.
> - Modified "numtxqs" in virtnet_info to "num_queue_pairs".
> virtnet_info still has numtxqs as it is more convenient.
> - Moved code for VIRTIO_NET_F_CTRL_VLAN into probe function.
> - Improve check for return value of virtio_config_val().
> - Removed cache align directives in guest as it was redundant.
> 5. "If we have a wrapper to init all vqs, pls add a wrapper to clean up
> all vqs as well": I haven't done this as some errors are very
> specific to the failure location (and what was initialized till
> then). So only those errors are cleaned up using goto's like the
> rest of the code. I can change in next version if you feel this is
> still required.
> 6. "I think we should have free_unused_bufs that handles a single queue,
> and call it in a loop": I haven't done this as I think the caller wants
> all rx/tx queues to be cleaned up by calling this function.
>
> TODO's:
> --------
> 1. Reduce vectors for find_vqs().
> 2. Make vhost changes minimal. For now, I have restricted the number of
> vhost threads to 4. This can be either made unrestricted; or if the
> userspace vhost works, it can be removed altogether.
>
> Please review and provide feedback. I am travelling a bit in the next
> few days but will respond at the earliest.
Do you have an update to the virtio-pci spec for this?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* RE: [PATCHv4 NEXT 1/1] net: ethtool support to configure number of channels
From: Ben Hutchings @ 2011-04-13 12:03 UTC (permalink / raw)
To: Amit Salecha
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ameen Rahman,
Sucheta Chakraborty, Anirban Chakraborty
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FD1384031@MNEXMB2.qlogic.org>
On Wed, 2011-04-13 at 04:45 -0500, Amit Salecha wrote:
> > Ethtool support to configure RX, TX and other channels. combined field
> > in struct ethtool_channels to reflect set of channel (RX, TX or other).
> > Other channel can be link interrupts, SR-IOV coordination etc.
> >
> > ETHTOOL_GCHANNELS will report max and current number of RX channels,
> > max and current number of TX channels, max and current number of other
> > channel
> > or max and current number of combined channel.
> >
> > Number of channel can be modify upto max number of channel through
> > ETHTOOL_SCHANNELS command.
> >
> > Ben Hutchings:
> > o define 'combined' and 'other' types. Most multiqueue drivers pair up
> > RX and TX
> > queues so that most channels combine RX and TX work.
> > o Please could you use a kernel-doc comment to describe the structure.
> >
> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> Neither I see this patch in http://patchwork.ozlabs.org/project/netdev/list/ nor any comment.
> Just curious, is this patch discarded along with my other garbage patches ?
It's marked as 'deferred'; not sure what that means:
http://patchwork.ozlabs.org/patch/90166/
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [stable] [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Greg KH @ 2011-04-13 14:03 UTC (permalink / raw)
To: Amit Salecha
Cc: David Miller, netdev@vger.kernel.org, Anirban Chakraborty,
stable@kernel.org, Ameen Rahman
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FD1383FDF@MNEXMB2.qlogic.org>
On Wed, Apr 13, 2011 at 12:56:56AM -0500, Amit Salecha wrote:
> > On Tue, Apr 12, 2011 at 09:01:13PM -0500, Amit Salecha wrote:
> > >
> > > This message and any attached documents contain information from
> > QLogic Corporation or its wholly-owned subsidiaries that may be
> > confidential. If you are not the intended recipient, you may not read,
> > copy, distribute, or use this information. If you have received this
> > transmission in error, please notify the sender immediately by reply e-
> > mail and then delete this message.
> >
> > I have received this transmission in error.
> >
> > Please remove this from your footer, otherwise we can not accept any
> > emails sent from you as actually being allowed to contribute to the
> > kernel properly :(
> >
> I have send version two of this patch, that doesn't have this footer.
> Please discard this one.
>
> This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
Your footer is still present, please fix this.
^ permalink raw reply
* [PATCH] mpc5xxx_can: Fix typo causing build failure (of_dev -> ofdev)
From: Jeff Mahoney @ 2011-04-13 14:57 UTC (permalink / raw)
To: Grant Likely, David S. Miller; +Cc: Network Development
The variable is named ofdev, not of_dev.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
drivers/net/can/mscan/mpc5xxx_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -260,7 +260,7 @@ static int __devinit mpc5xxx_can_probe(s
if (!ofdev->dev.of_match)
return -EINVAL;
- data = (struct mpc5xxx_can_data *)of_dev->dev.of_match->data;
+ data = (struct mpc5xxx_can_data *)ofdev->dev.of_match->data;
base = of_iomap(np, 0);
if (!base) {
--
Jeff Mahoney
SUSE Labs
^ permalink raw reply
* [PATCH 1/1] ipv6: ignore looped-back NA while dad is running
From: Daniel Walter @ 2011-04-13 15:02 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, davem
[ipv6] Ignore looped-back NAs while in Duplicate Address Detection
If we send an unsolicited NA shortly after bringing up an
IPv6 address, the duplicate address detection algorithm
fails and the ip stays in tentative mode forever.
This is due a missing check if the NA is looped-back to us.
Signed-off-by: Daniel Walter <dwalter@barracuda.com>
---
apply against linux-2.6 HEAD
net/ipv6/ndisc.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
---
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 92f952d..f057ff3 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -945,9 +945,10 @@ static void ndisc_recv_na(struct sk_buff *skb)
}
ifp = ipv6_get_ifaddr(dev_net(dev), &msg->target, dev, 1);
if (ifp) {
- if (ifp->flags & IFA_F_TENTATIVE) {
- addrconf_dad_failure(ifp);
- return;
+ if (skb->pkt_type != PACKET_LOOPBACK
+ && (ifp->flags & IFA_F_TENTATIVE)) {
+ addrconf_dad_failure(ifp);
+ return;
}
/* What should we make now? The advertisement
is invalid, but ndisc specs say nothing
Barracuda Networks AG
Vorsitzender des Aufsichtsrates/ Chairman of the supervisory board: Dean Drako
Vorstand/ Executive Board: Dr. Wieland Alge, Mag. Guenter Klausner
Sitz der Gesellschaft/ Registered office: 6020 Innsbruck, Austria
Handelsgericht Innsbruck Firmenbuch/ Registration Number: 184392s
UID-Nr/ VAT Number: ATU47509003
Diese Nachricht und allfaellige angehaengte Dokumente sind vertraulich und nur fuer den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Adressat sein, ist jede Offenlegung, Weiterleitung oder sonstige Verwendung dieser Information nicht gestattet. In diesem Fall bitten wir, den Absender zu verstaendigen und die Information zu vernichten. Fuer Uebermittlungsfehler oder sonstige Irrtuemer bei Uebermittlung besteht keine Haftung.
This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission.
Barracuda Networks solutions are now available as virtual appliances.
Visit www.barracudanetworks.com/vx for more information.
^ permalink raw reply related
* [PATCH] macb: Add rx overrun counter
From: Alexander Stein @ 2011-04-13 15:03 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: netdev, Alexander Stein
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
drivers/net/macb.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 79ccb54..76ce819 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -576,6 +576,11 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
* add that if/when we get our hands on a full-blown MII PHY.
*/
+ if (status & MACB_BIT(ISR_ROVR)) {
+ /* We missed at least one packet */
+ bp->hw_stats.rx_overruns++;
+ }
+
if (status & MACB_BIT(HRESP)) {
/*
* TODO: Reset the hardware, and maybe move the printk
@@ -1024,7 +1029,8 @@ static struct net_device_stats *macb_get_stats(struct net_device *dev)
hwstat->rx_jabbers +
hwstat->rx_undersize_pkts +
hwstat->rx_length_mismatch);
- nstat->rx_over_errors = hwstat->rx_resource_errors;
+ nstat->rx_over_errors = hwstat->rx_resource_errors +
+ hwstat->rx_overruns;
nstat->rx_crc_errors = hwstat->rx_fcs_errors;
nstat->rx_frame_errors = hwstat->rx_align_errors;
nstat->rx_fifo_errors = hwstat->rx_overruns;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Scot Doyle @ 2011-04-13 15:10 UTC (permalink / raw)
To: Eric Dumazet, Stephen Hemminger; +Cc: David Miller, Hiroaki SHIMODA, netdev
In-Reply-To: <4DA522B2.90200@scotdoyle.com>
On 04/12/2011 11:12 PM, Scot Doyle wrote:
> On 04/12/2011 06:55 PM, Scot Doyle wrote:
>> On 04/12/2011 12:18 PM, Eric Dumazet wrote:
>>> Commit 462fb2af9788a82 (bridge : Sanitize skb before it enters the IP
>>> stack), missed one IPCB init before calling ip_options_compile()
>>>
>>> Thanks to Scot Doyle for his tests and bug reports.
>>>
>>> Reported-by: Scot Doyle<lkml@scotdoyle.com>
>>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>>> Cc: Hiroaki SHIMODA<shimoda.hiroaki@gmail.com>
>>> Acked-by: Bandan Das<bandan.das@stratus.com>
>>> Acked-by: Stephen Hemminger<shemminger@vyatta.com>
>>> Cc: Jan Lübbe<jluebbe@debian.org>
>>> ---
>>> net/bridge/br_netfilter.c | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>>> index 008ff6c..b353f7c 100644
>>> --- a/net/bridge/br_netfilter.c
>>> +++ b/net/bridge/br_netfilter.c
>>> @@ -249,11 +249,9 @@ static int br_parse_ip_options(struct sk_buff *skb)
>>> goto drop;
>>> }
>>>
>>> - /* Zero out the CB buffer if no options present */
>>> - if (iph->ihl == 5) {
>>> - memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
>>> + memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
>>> + if (iph->ihl == 5)
>>> return 0;
>>> - }
>>>
>>> opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
>>> if (ip_options_compile(dev_net(dev), opt, skb))
>>>
>>>
>>
>>
>> Here's the output after pulling 2.6.39-rc3, applying the patches listed
>> below, doing a "make clean" and hitting the bridge's assigned ip address
>> with the IP Stack Checker tcpsic command. Maybe I should also be
>> applying the patch from yesterday too? I'll try that next.
>>
>> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>> index 008ff6c..b9bdff9 100644
>> --- a/net/bridge/br_netfilter.c
>> +++ b/net/bridge/br_netfilter.c
>> @@ -249,11 +249,9 @@ static int br_parse_ip_options(struct sk_buff *skb)
>> goto drop;
>> }
>>
>> - /* Zero out the CB buffer if no options present */
>> - if (iph->ihl == 5) {
>> - memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
>> - return 0;
>> - }
>> + memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
>> + if (iph->ihl == 5)
>> + return 0;
>>
>> opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
>> if (ip_options_compile(dev_net(dev), opt, skb))
>>
>> diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
>> index dd1b20e..9df4e63 100644
>> --- a/net/ipv4/inetpeer.c
>> +++ b/net/ipv4/inetpeer.c
>> @@ -354,7 +354,8 @@ static void inetpeer_free_rcu(struct rcu_head *head)
>> }
>>
>> /* May be called with local BH enabled. */
>> -static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
>> *base)
>> +static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
>> *base,
>> + struct inet_peer __rcu **stack[PEER_MAXDEPTH])
>> {
>> int do_free;
>>
>> @@ -368,7 +369,6 @@ static void unlink_from_pool(struct inet_peer *p,
>> struct inet_peer_base *base)
>> * We use refcnt=-1 to alert lockless readers this entry is deleted.
>> */
>> if (atomic_cmpxchg(&p->refcnt, 1, -1) == 1) {
>> - struct inet_peer __rcu **stack[PEER_MAXDEPTH];
>> struct inet_peer __rcu ***stackptr, ***delp;
>> if (lookup(&p->daddr, stack, base) != p)
>> BUG();
>> @@ -422,7 +422,7 @@ static struct inet_peer_base *peer_to_base(struct
>> inet_peer *p)
>> }
>>
>> /* May be called with local BH enabled. */
>> -static int cleanup_once(unsigned long ttl)
>> +static int cleanup_once(unsigned long ttl, struct inet_peer __rcu
>> **stack[PEER_MAXDEPTH])
>> {
>> struct inet_peer *p = NULL;
>>
>> @@ -454,7 +454,7 @@ static int cleanup_once(unsigned long ttl)
>> * happen because of entry limits in route cache. */
>> return -1;
>>
>> - unlink_from_pool(p, peer_to_base(p));
>> + unlink_from_pool(p, peer_to_base(p), stack);
>> return 0;
>> }
>>
>> @@ -524,7 +524,7 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr
>> *daddr, int create)
>>
>> if (base->total >= inet_peer_threshold)
>> /* Remove one less-recently-used entry. */
>> - cleanup_once(0);
>> + cleanup_once(0, stack);
>>
>> return p;
>> }
>> @@ -540,6 +540,7 @@ static void peer_check_expire(unsigned long dummy)
>> {
>> unsigned long now = jiffies;
>> int ttl, total;
>> + struct inet_peer __rcu **stack[PEER_MAXDEPTH];
>>
>> total = compute_total();
>> if (total >= inet_peer_threshold)
>> @@ -548,7 +549,7 @@ static void peer_check_expire(unsigned long dummy)
>> ttl = inet_peer_maxttl
>> - (inet_peer_maxttl - inet_peer_minttl) / HZ *
>> total / inet_peer_threshold * HZ;
>> - while (!cleanup_once(ttl)) {
>> + while (!cleanup_once(ttl, stack)) {
>> if (jiffies != now)
>> break;
>> }
>>
>> diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
>> index 28a736f..dea9947 100644
>> --- a/net/ipv4/ip_options.c
>> +++ b/net/ipv4/ip_options.c
>> @@ -200,6 +200,11 @@ int ip_options_echo(struct ip_options * dopt,
>> struct sk_buff * skb)
>> *dptr++ = IPOPT_END;
>> dopt->optlen++;
>> }
>> + if (unlikely(dopt->optlen > 40)) {
>> + pr_err("ip_options_echo() fatal error optlen=%u > 40\n", dopt->optlen);
>> + print_hex_dump(KERN_ERR, "ip options: ", DUMP_PREFIX_OFFSET,
>> + 16, 1, dopt->__data, dopt->optlen, false);
>> + }
>> return 0;
>> }
>>
>>
>> ------------
>>
>>
>> [ 761.720393] BUG: unable to handle kernel NULL pointer dereference at
>> 00000000000000d0
>> [ 761.728206] IP: [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
>> [ 761.734452] PGD 0
>> [ 761.736459] Oops: 0000 [#1] SMP
>> [ 761.739683] last sysfs file: /sys/devices/virtual/misc/kvm/uevent
>> [ 761.745744] CPU 0
>> [ 761.747570] Modules linked in: kvm_intel kvm bridge stp loop snd_pcm
>> snd_timer snd tpm_tis tpm tpm_bios soundcore psmouse snd_page_alloc
>> processor ghes thermal_sys
>> i7core_edac evdev pcspkr serio_raw edac_core dcdbas power_meter button
>> hed ext2 mbcache dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas
>> uhci_hcd ehci_hcd mpt2sas
>> scsi_transport_sas raid_class igb scsi_mod usbcore bnx2 dca [last
>> unloaded: scsi_wait_scan]
>> [ 761.785171]
>> [ 761.786651] Pid: 0, comm: swapper Not tainted 2.6.39-rc3+ #14 Dell
>> Inc. PowerEdge R510/0DPRKF
>> [ 761.795157] RIP: 0010:[<ffffffff8129fbe9>] [<ffffffff8129fbe9>]
>> ip_options_compile+0x1c1/0x435
>> [ 761.803823] RSP: 0018:ffff88042f203af0 EFLAGS: 00010286
>> [ 761.809106] RAX: 0000000000000017 RBX: ffff8804027b3600 RCX:
>> ffff88040466a864
>> [ 761.816205] RDX: 000000000000001a RSI: 0000000000000000 RDI:
>> ffffffff817e6100
>> [ 761.823304] RBP: ffff88040466a862 R08: ffffffffa01d6e89 R09:
>> ffff88042f203c58
>> [ 761.830402] R10: 0000000000000000 R11: 0000000000000000 R12:
>> ffff8804027b3628
>> [ 761.837501] R13: 000000000000001d R14: ffff88040466a84e R15:
>> 0000000000000024
>> [ 761.844601] FS: 0000000000000000(0000) GS:ffff88042f200000(0000)
>> knlGS:0000000000000000
>> [ 761.852650] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 761.858365] CR2: 00000000000000d0 CR3: 0000000001603000 CR4:
>> 00000000000006f0
>> [ 761.865463] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>> 0000000000000000
>> [ 761.872562] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>> 0000000000000400
>> [ 761.879661] Process swapper (pid: 0, threadinfo ffffffff81600000, task
>> ffffffff8160b020)
>> [ 761.887710] Stack:
>> [ 761.889708] 0000000000000000 ffffffff81276928 0000000000000000
>> ffffffff817e6100
>> [ 761.897102] 000000000000004e ffff88040500e600 ffff88040500e600
>> ffff8804027b3600
>> [ 761.904496] ffff880404fc0000 ffff8804027b3628 0000000000000000
>> ffff880404fc0000
>> [ 761.911889] Call Trace:
>> [ 761.914319] <IRQ>
>> [ 761.916413] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
>> [ 761.922306] [<ffffffffa01dae3b>] ? br_parse_ip_options+0x134/0x1a8
>> [bridge]
>> [ 761.929319] [<ffffffffa01dbbe0>] ? br_nf_pre_routing+0x348/0x3cb
>> [bridge]
>> [ 761.936160] [<ffffffff81298527>] ? nf_iterate+0x41/0x7e
>> [ 761.941444] [<ffffffff8104afaa>] ? irq_exit+0x58/0x8f
>> [ 761.946556] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
>> [ 761.953052] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
>> [ 761.959546] [<ffffffff812985d7>] ? nf_hook_slow+0x73/0x114
>> [ 761.965089] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
>> [ 761.971583] [<ffffffff8126d097>] ? __netdev_alloc_skb+0x15/0x2f
>> [ 761.977561] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
>> [ 761.984055] [<ffffffffa01d6e6f>] ? NF_HOOK.clone.4+0x3c/0x56 [bridge]
>> [ 761.990551] [<ffffffff812a7dde>] ? tcp_gro_receive+0xa1/0x204
>> [ 761.996355] [<ffffffffa01d71e5>] ? br_handle_frame+0x195/0x1ac [bridge]
>> [ 762.003022] [<ffffffffa01d7050>] ? br_handle_frame_finish+0x1c7/0x1c7
>> [bridge]
>> [ 762.010294] [<ffffffff812764ef>] ? __netif_receive_skb+0x2a7/0x450
>> [ 762.016530] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
>> [ 762.022420] [<ffffffff81276e2a>] ? napi_gro_receive+0x1f/0x2f
>> [ 762.028222] [<ffffffff812769ff>] ? napi_skb_finish+0x1c/0x31
>> [ 762.033941] [<ffffffffa024afcd>] ? igb_poll+0x6d9/0x9ee [igb]
>> [ 762.039744] [<ffffffff8109034f>] ? handle_irq_event+0x40/0x55
>> [ 762.045547] [<ffffffff8106fc3c>] ? arch_local_irq_save+0x14/0x1d
>> [ 762.051609] [<ffffffff81276f55>] ? net_rx_action+0xa4/0x1b1
>> [ 762.057239] [<ffffffff8104ad26>] ? __do_softirq+0xb8/0x176
>> [ 762.062783] [<ffffffff81333cdc>] ? call_softirq+0x1c/0x30
>> [ 762.068241] [<ffffffff8100aa57>] ? do_softirq+0x3f/0x84
>> [ 762.073524] [<ffffffff8104af91>] ? irq_exit+0x3f/0x8f
>> [ 762.078635] [<ffffffff8100a793>] ? do_IRQ+0x85/0x9e
>> [ 762.083575] [<ffffffff8132cc53>] ? common_interrupt+0x13/0x13
>> [ 762.089375] <EOI>
>> [ 762.091469] [<ffffffff81061348>] ? enqueue_hrtimer+0x3f/0x53
>> [ 762.097188] [<ffffffffa0430417>] ? arch_local_irq_enable+0x7/0x8
>> [processor]
>> [ 762.104288] [<ffffffffa0430dab>] ? acpi_idle_enter_c1+0x86/0xa2
>> [processor]
>> [ 762.111303] [<ffffffff8125d05d>] ? cpuidle_idle_call+0xf4/0x17e
>> [ 762.117277] [<ffffffff81008298>] ? cpu_idle+0xa2/0xc4
>> [ 762.122388] [<ffffffff8169db60>] ? start_kernel+0x3b9/0x3c4
>> [ 762.128018] [<ffffffff8169d3c6>] ? x86_64_start_kernel+0x102/0x10f
>> [ 762.134253] Code: 4d 02 3c 03 0f 86 59 02 00 00 0f b6 d0 44 39 ea 7f
>> 32 83 c2 03 44 39 ea 0f 8f 45 02 00 00 48 85 db 74 18 48 8b 74 24 10 0f
>> b6 c0 <8b> 96 d0 00 00 00 89 54 05 ff 41 80 4c 24 08 04 80 01 04 41 80
>> [ 762.153593] RIP [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
>> [ 762.159923] RSP <ffff88042f203af0>
>> [ 762.163391] CR2: 00000000000000d0
>> [ 762.167017] ---[ end trace e15d7b082f680b62 ]---
>> --
>> 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
>>
>
>
> Good news! I cannot create any kernel panics with the following patches
> to 2.6.39-rc3 commit a6360dd37e1a144ed11e6548371bade559a1e4df while
> targeting either the host's bridged IP address or the guest virtual
> machine bridged IP addresses with the IP Stack Checker tools.
>
> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
> index 008ff6c..cdb4423 100644
> --- a/net/bridge/br_netfilter.c
> +++ b/net/bridge/br_netfilter.c
> @@ -221,6 +221,7 @@ static int br_parse_ip_options(struct sk_buff *skb)
> struct ip_options *opt;
> struct iphdr *iph;
> struct net_device *dev = skb->dev;
> + struct rtable *rt;
> u32 len;
>
> iph = ip_hdr(skb);
> @@ -249,10 +250,18 @@ static int br_parse_ip_options(struct sk_buff *skb)
> goto drop;
> }
>
> - /* Zero out the CB buffer if no options present */
> - if (iph->ihl == 5) {
> - memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
> - return 0;
> + memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
> + if (iph->ihl == 5)
> + return 0;
> +
> + /* Associate bogus bridge route table */
> + if (!skb_dst(skb)) {
> + rt = bridge_parent_rtable(dev);
> + if (!rt) {
> + kfree_skb(skb);
> + return 0;
> + }
> + skb_dst_set_noref(skb,&rt->dst);
> }
>
> opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
> diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
> index dd1b20e..9df4e63 100644
> --- a/net/ipv4/inetpeer.c
> +++ b/net/ipv4/inetpeer.c
> @@ -354,7 +354,8 @@ static void inetpeer_free_rcu(struct rcu_head *head)
> }
>
> /* May be called with local BH enabled. */
> -static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
> *base)
> +static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
> *base,
> + struct inet_peer __rcu **stack[PEER_MAXDEPTH])
> {
> int do_free;
>
> @@ -368,7 +369,6 @@ static void unlink_from_pool(struct inet_peer *p,
> struct inet_peer_base *base)
> * We use refcnt=-1 to alert lockless readers this entry is deleted.
> */
> if (atomic_cmpxchg(&p->refcnt, 1, -1) == 1) {
> - struct inet_peer __rcu **stack[PEER_MAXDEPTH];
> struct inet_peer __rcu ***stackptr, ***delp;
> if (lookup(&p->daddr, stack, base) != p)
> BUG();
> @@ -422,7 +422,7 @@ static struct inet_peer_base *peer_to_base(struct
> inet_peer *p)
> }
>
> /* May be called with local BH enabled. */
> -static int cleanup_once(unsigned long ttl)
> +static int cleanup_once(unsigned long ttl, struct inet_peer __rcu
> **stack[PEER_MAXDEPTH])
> {
> struct inet_peer *p = NULL;
>
> @@ -454,7 +454,7 @@ static int cleanup_once(unsigned long ttl)
> * happen because of entry limits in route cache. */
> return -1;
>
> - unlink_from_pool(p, peer_to_base(p));
> + unlink_from_pool(p, peer_to_base(p), stack);
> return 0;
> }
>
> @@ -524,7 +524,7 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr
> *daddr, int create)
>
> if (base->total >= inet_peer_threshold)
> /* Remove one less-recently-used entry. */
> - cleanup_once(0);
> + cleanup_once(0, stack);
>
> return p;
> }
> @@ -540,6 +540,7 @@ static void peer_check_expire(unsigned long dummy)
> {
> unsigned long now = jiffies;
> int ttl, total;
> + struct inet_peer __rcu **stack[PEER_MAXDEPTH];
>
> total = compute_total();
> if (total >= inet_peer_threshold)
> @@ -548,7 +549,7 @@ static void peer_check_expire(unsigned long dummy)
> ttl = inet_peer_maxttl
> - (inet_peer_maxttl - inet_peer_minttl) / HZ *
> total / inet_peer_threshold * HZ;
> - while (!cleanup_once(ttl)) {
> + while (!cleanup_once(ttl, stack)) {
> if (jiffies != now)
> break;
> }
>
The net effect is that three patches are required to eliminate the panics.
These two patches have been accepted by David:
http://article.gmane.org/gmane.linux.network/192015
http://article.gmane.org/gmane.linux.network/192055
This patch, incrementally authored by Stephen and Eric and compiled by
me, is also required:
http://article.gmane.org/gmane.linux.network/192007
What should happen for this third patch to be included upstream?
^ permalink raw reply
* Re: [PATCH] mpc5xxx_can: Fix typo causing build failure (of_dev -> ofdev)
From: Anatolij Gustschin @ 2011-04-13 15:13 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: Grant Likely, David S. Miller, Network Development
In-Reply-To: <4DA5B9BF.2010809@suse.com>
Hi,
On Wed, 13 Apr 2011 10:57:03 -0400
Jeff Mahoney <jeffm@suse.com> wrote:
> The variable is named ofdev, not of_dev.
>
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> ---
> drivers/net/can/mscan/mpc5xxx_can.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
There is already a patch pending, [1].
[1] http://patchwork.ozlabs.org/patch/90979/
^ permalink raw reply
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Stephen Hemminger @ 2011-04-13 15:24 UTC (permalink / raw)
To: Scot Doyle; +Cc: Eric Dumazet, David Miller, Hiroaki SHIMODA, netdev
In-Reply-To: <4DA5BCF7.9020606@scotdoyle.com>
> The net effect is that three patches are required to eliminate the panics.
>
> These two patches have been accepted by David:
> http://article.gmane.org/gmane.linux.network/192015
> http://article.gmane.org/gmane.linux.network/192055
>
> This patch, incrementally authored by Stephen and Eric and compiled by
> me, is also required:
> http://article.gmane.org/gmane.linux.network/192007
>
> What should happen for this third patch to be included upstream?
Although making IP more robust is a good.
I still think bridging shouldn't give bad packets to IP.
^ permalink raw reply
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Eric Dumazet @ 2011-04-13 15:28 UTC (permalink / raw)
To: Scot Doyle; +Cc: Stephen Hemminger, David Miller, Hiroaki SHIMODA, netdev
In-Reply-To: <4DA5BCF7.9020606@scotdoyle.com>
Le mercredi 13 avril 2011 à 10:10 -0500, Scot Doyle a écrit :
> The net effect is that three patches are required to eliminate the panics.
>
> These two patches have been accepted by David:
> http://article.gmane.org/gmane.linux.network/192015
> http://article.gmane.org/gmane.linux.network/192055
>
> This patch, incrementally authored by Stephen and Eric and compiled by
> me, is also required:
> http://article.gmane.org/gmane.linux.network/192007
>
> What should happen for this third patch to be included upstream?
Dont worry, Stephen or me will send it asap.
Thanks
^ permalink raw reply
* Linux L4-Load Balancing with ECMP
From: Christoph Paasch @ 2011-04-13 15:24 UTC (permalink / raw)
To: netdev; +Cc: Gregory Detal
Hi all,
we were trying to do L4-load-balancing with the Linux Kernel (by configuring
multiple nexthops for the default-route) , and were surprised to see that the
Linux Kernel load-balances the traffic based only on the IP-addresses and does
not consider the 5-tuple, when forwarding the traffic.
As L4 load-balancing with ECMP is quite common, I was wondering, if it has
ever been considered to include this in the Kernel?
Or, what are the reasons that it is not inside?
Thanks,
Christoph Paasch
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Scot Doyle @ 2011-04-13 15:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, netdev
In-Reply-To: <20110413082457.52784d6d@nehalam>
On 04/13/2011 10:24 AM, Stephen Hemminger wrote:
>> The net effect is that three patches are required to eliminate the panics.
>>
>> These two patches have been accepted by David:
>> http://article.gmane.org/gmane.linux.network/192015
>> http://article.gmane.org/gmane.linux.network/192055
>>
>> This patch, incrementally authored by Stephen and Eric and compiled by
>> me, is also required:
>> http://article.gmane.org/gmane.linux.network/192007
>>
>> What should happen for this third patch to be included upstream?
> Although making IP more robust is a good.
> I still think bridging shouldn't give bad packets to IP.
I'm definitely willing to test alternative patches. The output without
that third patch is:
[ 761.720393] BUG: unable to handle kernel NULL pointer dereference at
00000000000000d0
[ 761.728206] IP: [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
[ 761.734452] PGD 0
[ 761.736459] Oops: 0000 [#1] SMP
[ 761.739683] last sysfs file: /sys/devices/virtual/misc/kvm/uevent
[ 761.745744] CPU 0
[ 761.747570] Modules linked in: kvm_intel kvm bridge stp loop snd_pcm
snd_timer snd tpm_tis tpm tpm_bios soundcore psmouse snd_page_alloc
processor ghes thermal_sys
i7core_edac evdev pcspkr serio_raw edac_core dcdbas power_meter button
hed ext2 mbcache dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas
uhci_hcd ehci_hcd mpt2sas
scsi_transport_sas raid_class igb scsi_mod usbcore bnx2 dca [last
unloaded: scsi_wait_scan]
[ 761.785171]
[ 761.786651] Pid: 0, comm: swapper Not tainted 2.6.39-rc3+ #14 Dell
Inc. PowerEdge R510/0DPRKF
[ 761.795157] RIP: 0010:[<ffffffff8129fbe9>] [<ffffffff8129fbe9>]
ip_options_compile+0x1c1/0x435
[ 761.803823] RSP: 0018:ffff88042f203af0 EFLAGS: 00010286
[ 761.809106] RAX: 0000000000000017 RBX: ffff8804027b3600 RCX:
ffff88040466a864
[ 761.816205] RDX: 000000000000001a RSI: 0000000000000000 RDI:
ffffffff817e6100
[ 761.823304] RBP: ffff88040466a862 R08: ffffffffa01d6e89 R09:
ffff88042f203c58
[ 761.830402] R10: 0000000000000000 R11: 0000000000000000 R12:
ffff8804027b3628
[ 761.837501] R13: 000000000000001d R14: ffff88040466a84e R15:
0000000000000024
[ 761.844601] FS: 0000000000000000(0000) GS:ffff88042f200000(0000)
knlGS:0000000000000000
[ 761.852650] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 761.858365] CR2: 00000000000000d0 CR3: 0000000001603000 CR4:
00000000000006f0
[ 761.865463] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 761.872562] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 761.879661] Process swapper (pid: 0, threadinfo ffffffff81600000,
task ffffffff8160b020)
[ 761.887710] Stack:
[ 761.889708] 0000000000000000 ffffffff81276928 0000000000000000
ffffffff817e6100
[ 761.897102] 000000000000004e ffff88040500e600 ffff88040500e600
ffff8804027b3600
[ 761.904496] ffff880404fc0000 ffff8804027b3628 0000000000000000
ffff880404fc0000
[ 761.911889] Call Trace:
[ 761.914319] <IRQ>
[ 761.916413] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
[ 761.922306] [<ffffffffa01dae3b>] ? br_parse_ip_options+0x134/0x1a8
[bridge]
[ 761.929319] [<ffffffffa01dbbe0>] ? br_nf_pre_routing+0x348/0x3cb
[bridge]
[ 761.936160] [<ffffffff81298527>] ? nf_iterate+0x41/0x7e
[ 761.941444] [<ffffffff8104afaa>] ? irq_exit+0x58/0x8f
[ 761.946556] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.953052] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.959546] [<ffffffff812985d7>] ? nf_hook_slow+0x73/0x114
[ 761.965089] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.971583] [<ffffffff8126d097>] ? __netdev_alloc_skb+0x15/0x2f
[ 761.977561] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.984055] [<ffffffffa01d6e6f>] ? NF_HOOK.clone.4+0x3c/0x56 [bridge]
[ 761.990551] [<ffffffff812a7dde>] ? tcp_gro_receive+0xa1/0x204
[ 761.996355] [<ffffffffa01d71e5>] ? br_handle_frame+0x195/0x1ac [bridge]
[ 762.003022] [<ffffffffa01d7050>] ?
br_handle_frame_finish+0x1c7/0x1c7 [bridge]
[ 762.010294] [<ffffffff812764ef>] ? __netif_receive_skb+0x2a7/0x450
[ 762.016530] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
[ 762.022420] [<ffffffff81276e2a>] ? napi_gro_receive+0x1f/0x2f
[ 762.028222] [<ffffffff812769ff>] ? napi_skb_finish+0x1c/0x31
[ 762.033941] [<ffffffffa024afcd>] ? igb_poll+0x6d9/0x9ee [igb]
[ 762.039744] [<ffffffff8109034f>] ? handle_irq_event+0x40/0x55
[ 762.045547] [<ffffffff8106fc3c>] ? arch_local_irq_save+0x14/0x1d
[ 762.051609] [<ffffffff81276f55>] ? net_rx_action+0xa4/0x1b1
[ 762.057239] [<ffffffff8104ad26>] ? __do_softirq+0xb8/0x176
[ 762.062783] [<ffffffff81333cdc>] ? call_softirq+0x1c/0x30
[ 762.068241] [<ffffffff8100aa57>] ? do_softirq+0x3f/0x84
[ 762.073524] [<ffffffff8104af91>] ? irq_exit+0x3f/0x8f
[ 762.078635] [<ffffffff8100a793>] ? do_IRQ+0x85/0x9e
[ 762.083575] [<ffffffff8132cc53>] ? common_interrupt+0x13/0x13
[ 762.089375] <EOI>
[ 762.091469] [<ffffffff81061348>] ? enqueue_hrtimer+0x3f/0x53
[ 762.097188] [<ffffffffa0430417>] ? arch_local_irq_enable+0x7/0x8
[processor]
[ 762.104288] [<ffffffffa0430dab>] ? acpi_idle_enter_c1+0x86/0xa2
[processor]
[ 762.111303] [<ffffffff8125d05d>] ? cpuidle_idle_call+0xf4/0x17e
[ 762.117277] [<ffffffff81008298>] ? cpu_idle+0xa2/0xc4
[ 762.122388] [<ffffffff8169db60>] ? start_kernel+0x3b9/0x3c4
[ 762.128018] [<ffffffff8169d3c6>] ? x86_64_start_kernel+0x102/0x10f
[ 762.134253] Code: 4d 02 3c 03 0f 86 59 02 00 00 0f b6 d0 44 39 ea 7f
32 83 c2 03 44 39 ea 0f 8f 45 02 00 00 48 85 db 74 18 48 8b 74 24 10 0f
b6 c0 <8b> 96 d0 00 00 00 89 54 05 ff 41 80 4c 24 08 04 80 01 04 41 80
[ 762.153593] RIP [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
[ 762.159923] RSP <ffff88042f203af0>
[ 762.163391] CR2: 00000000000000d0
[ 762.167017] ---[ end trace e15d7b082f680b62 ]---
^ permalink raw reply
* Re: [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Amit Salecha @ 2011-04-13 15:59 UTC (permalink / raw)
To: Greg KH
Cc: netdev@vger.kernel.org, Anirban Chakraborty, David Miller,
Ameen Rahman, stable@kernel.org
In-Reply-To: <20110413140307.GA7426@kroah.com>
> On Wed, Apr 13, 2011 at 12:56:56AM -0500, Amit Salecha wrote:
> > > On Tue, Apr 12, 2011 at 09:01:13PM -0500, Amit Salecha wrote:
> > > >
> > > > This message and any attached documents contain information from
> > > QLogic Corporation or its wholly-owned subsidiaries that may be
> > > confidential. If you are not the intended recipient, you may not
> read,
> > > copy, distribute, or use this information. If you have received
> this
> > > transmission in error, please notify the sender immediately by
> reply e-
> > > mail and then delete this message.
> > >
> > > I have received this transmission in error.
> > >
> > > Please remove this from your footer, otherwise we can not accept
> any
> > > emails sent from you as actually being allowed to contribute to the
> > > kernel properly :(
> > >
> > I have send version two of this patch, that doesn't have this footer.
> > Please discard this one.
> >
> > This message and any attached documents contain information from
> QLogic Corporation or its wholly-owned subsidiaries that may be
> confidential. If you are not the intended recipient, you may not read,
> copy, distribute, or use this information. If you have received this
> transmission in error, please notify the sender immediately by reply e-
> mail and then delete this message.
>
> Your footer is still present, please fix this.
Footer will present in my reply to this email. But footer should not be there in patches sent by me.
Can you verify patch version 2 again ? Here http://patchwork.ozlabs.org/patch/90938/ I don't see any footer.
If you see footer with patch version 2, please send me that.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ 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