* Re: 2.6.34 + IPv6: Oops?
From: Andreas Klauer @ 2010-06-21 20:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Hagen Paul Pfeifer, netdev, Octavian Purdila
In-Reply-To: <20100621102508.2075d677@nehalam>
On Mon, Jun 21, 2010 at 10:25:08AM -0700, Stephen Hemminger wrote:
> It is not handling the case of ifp == NULL.
>
> Maybe the following (move the assignment into the if block).
>
> --- a/net/ipv6/ndisc.c 2010-06-21 10:22:20.825637690 -0700
> +++ b/net/ipv6/ndisc.c 2010-06-21 10:24:31.573011996 -0700
> @@ -586,6 +586,7 @@ static void ndisc_send_na(struct net_dev
> src_addr = solicited_addr;
> if (ifp->flags & IFA_F_OPTIMISTIC)
> override = 0;
> + inc_opt |= ifp->idev->cnf.force_tllao;
> in6_ifa_put(ifp);
> } else {
> if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
> @@ -599,7 +600,6 @@ static void ndisc_send_na(struct net_dev
> icmp6h.icmp6_solicited = solicited;
> icmp6h.icmp6_override = override;
>
> - inc_opt |= ifp->idev->cnf.force_tllao;
> __ndisc_send(dev, neigh, daddr, src_addr,
> &icmp6h, solicited_addr,
> inc_opt ? ND_OPT_TARGET_LL_ADDR : 0);
>
>
>
Thanks a lot! This fix seems to work fine for me (tested locally only).
I'll see what happens when I apply it to my server tomorrow.
Curious though as to why I wasn't able to reproduce it when compiling
the kernel with Gentoo's GCC. It doesn't look like it should make any
difference. Maybe I made a mistake when I tested it with Gentoo.
Regards
Andreas Klauer
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Ben Hutchings @ 2010-06-21 19:57 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: jeff, davem, netdev, gospo, Peter P Waskiewicz Jr
In-Reply-To: <20100204075101.16661.95658.stgit@localhost.localdomain>
On Wed, 2010-02-03 at 23:51 -0800, Jeff Kirsher wrote:
> From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>
> Program underlying ethernet devices with n-tuple flow classification
> filters.
>
> This also adds a new flag to ethtool_flags, allowing n-tuple
> programming to be toggled using the set_flags call.
I just noticed a problem with the implementation which makes me wonder
whether this was tested at all:
[...]
> +static struct cmdline_info cmdline_ntuple[] = {
> + { "src-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4src, NULL },
> + { "src-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4src, NULL },
> + { "dst-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4dst, NULL },
> + { "dst-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4dst, NULL },
> + { "src-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.psrc, NULL },
> + { "src-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.psrc, NULL },
> + { "dst-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.pdst, NULL },
> + { "dst-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.pdst, NULL },
> + { "vlan", CMDL_INT, &ntuple_fs.vlan_tag, NULL },
> + { "vlan-mask", CMDL_UINT, &ntuple_fs.vlan_tag_mask, NULL },
> + { "user-def", CMDL_INT, &ntuple_fs.data, NULL },
> + { "user-def-mask", CMDL_UINT, &ntuple_fs.data_mask, NULL },
> + { "action", CMDL_INT, &ntuple_fs.action, NULL },
> +};
[...]
> + if (mode == MODE_SNTUPLE) {
> + if (!strcmp(argp[i], "flow-type")) {
> + i += 1;
> + if (i >= argc) {
> + show_usage(1);
> + break;
> + }
> + ntuple_fs.flow_type =
> + rxflow_str_to_type(argp[i]);
> + i += 1;
> + parse_generic_cmdline(argc, argp, i,
> + &sntuple_changed,
> + cmdline_ntuple,
> + ARRAY_SIZE(cmdline_ntuple));
> + i = argc;
> + break;
> + } else {
> + show_usage(1);
> + }
> + break;
> + }
[...]
parse_generic_cmdline() will write an int for each argument defined with
type CMDL_INT or CMDL_UINT. But the fields in ntuple_fs are not all of
type int (or even 32-bit) - some of them are 16-bit or 64-bit, and some
of them are big-endian. I also wonder whether anyone really wants to
enter an IPv4 address as a single integer.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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
* [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: Jiri Pirko @ 2010-06-21 19:34 UTC (permalink / raw)
To: netdev; +Cc: davem
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a95a41b..e079117 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -31,8 +31,6 @@
*
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/types.h>
^ permalink raw reply related
* Re: PATCH: uninitialized memory access in tcp_parse_options
From: Mathieu Lacage @ 2010-06-21 19:10 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: netdev
In-Reply-To: <3E37AD8C-208F-42B8-AA04-E0B294D909A8@earthlink.net>
On Mon, 2010-06-21 at 11:02 -0700, Mitchell Erblich wrote:
> The standard default for TCP with IPv4 is 536, which
> translates to 576 MTU.
>
> Thus, why don't you init mss to 536?
I don't know: I am not a tcp expert and I am not sure I really
understand the way this function is expected to be used by callers but I
sent a patch to make sure that someone would feel compelled to find the
right fix. It looks like callers of this function are expected to
initialize the fields themselves so, the idea of doing the
initialization in tcp_parse_options is probably bad.
Mathieu
--
Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
Tel: +33 4 9238 5056
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:56 UTC (permalink / raw)
To: Nick Bowler
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <20100621135857.GA21159-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
On Monday, June 21, 2010, Nick Bowler wrote:
> On 00:11 Mon 21 Jun , Rafael J. Wysocki wrote:
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
>
> Didn't see this one in the list:
>
> Why is kslowd accumulating so much CPU time?
> http://thread.gmane.org/gmane.linux.kernel/996907
Thanks, I'm going to add it to the list.
Rafael
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:54 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <1277074706.21312.8.camel@maxim-laptop>
On Monday, June 21, 2010, Maxim Levitsky wrote:
> On Mon, 2010-06-21 at 00:11 +0200, Rafael J. Wysocki wrote:
> > This message contains a list of some regressions from 2.6.34,
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
> >
> > Each entry from the list will be sent additionally in an automatic reply
> > to this message with CCs to the people involved in reporting and handling
> > the issue.
> >
> >
> > Listed regressions statistics:
> >
> > Date Total Pending Unresolved
> > ----------------------------------------
> > 2010-06-21 46 37 26
> > 2010-06-09 15 13 10
> >
> >
> > Unresolved regressions
> > ----------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16255
> > Subject : 2.6.35-rc3 deadlocks on semaphore operations
> > Submitter : Christoph Lameter <cl@linux-foundation.org>
> > Date : 2010-06-18 14:49 (3 days old)
> > Message-ID : <alpine.DEB.2.00.1006180940140.11575@router.home>
> > References : http://marc.info/?l=linux-kernel&m=127687262727707&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16248
> > Subject : inconsistent lock state
> > Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > Date : 2010-06-15 11:24 (6 days old)
> > Message-ID : <20100615112434.GA3967@swordfish.minsk.epam.com>
> > References : http://marc.info/?l=linux-kernel&m=127660087625903&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16247
> > Subject : drm/i915 BUG with 2.6.35-rc
> > Submitter : Benny Halevy <bhalevy@panasas.com>
> > Date : 2010-06-14 22:38 (7 days old)
> > Message-ID : <4C16AF56.1040002@panasas.com>
> > References : http://marc.info/?l=linux-kernel&m=127655510531367&w=2
>
>
> Don't have time to test, but I confirm that running compiz without
> mode-setting (ubuntu 8.10) hangs the system. (device is i945)
> It might be related to few intel regressions on this list.
>
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> > Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2010-06-14 17:24 (7 days old)
> > Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
> I was hit by this bug. Fix is now present in iwlwifi tree.
> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=4d23e4e5eb50431426facf192354ad2506e2dd40
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16234
> > Subject : [2.6.35-rc3] reboot mutex 'bug'...
> > Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
> > Date : 2010-06-14 15:16 (7 days old)
> > Message-ID : <AANLkTimDcTnyEPmt2ZcCM1UWtn4AYKotiqyjobJApkO7@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127652861118933&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16232
> > Subject : 2.6.35-rc3 - WARNING:iwl_set_dynamic_key
> > Submitter : Mario Guenterberg <mario.guenterberg@googlemail.com>
> > Date : 2010-06-14 11:55 (7 days old)
> > Message-ID : <20100614115510.GA7904@guenti-laptop>
> > References : http://marc.info/?l=linux-kernel&m=127651695627147&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16230
> > Subject : inconsistent IN-HARDIRQ-W -> HARDIRQ-ON-W usage: fasync, 2.6.35-rc3
> > Submitter : Dominik Brodowski <linux@dominikbrodowski.net>
> > Date : 2010-06-13 9:53 (8 days old)
> > Message-ID : <20100613095305.GA13231@comet.dominikbrodowski.net>
> > References : http://marc.info/?l=linux-kernel&m=127642282208277&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
> > Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
> > Submitter : Brian Bloniarz <phunge0@hotmail.com>
> > Date : 2010-06-16 17:57 (5 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16222
> > Subject : 2.6.35-rc{12} regression: inactive console corrupted
> > Submitter : Pavel Machek <pavel@ucw.cz>
> > Date : 2010-06-12 10:33 (9 days old)
> > Message-ID : <20100612103321.GA1458@ucw.cz>
> > References : http://marc.info/?l=linux-kernel&m=127633882614501&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
> > Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-11 20:31 (10 days old)
> > Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16205
> > Subject : acpi: freeing invalid memtype bf799000-bf79a000
> > Submitter : Marcin Slusarz <marcin.slusarz@gmail.com>
> > Date : 2010-06-09 20:09 (12 days old)
> > Message-ID : <20100609200910.GA2876@joi.lan>
> > References : http://marc.info/?l=linux-kernel&m=127611427029914&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16201
> > Subject : SIOCGIWFREQ ioctl fails to get frequency info
> > Submitter : nuh <nuh@mailinator.net>
> > Date : 2010-06-14 10:45 (7 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16199
> > Subject : 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-07 18:14 (14 days old)
> > Message-ID : <AANLkTin2pPqOUx--9fIX3BH3e-cU6oCRufijcx_4ozx5@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127593447812015&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16198
> > Subject : Running make install over sshfs is painful now
> > Submitter : Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Date : 2010-06-07 6:53 (14 days old)
> > Message-ID : <20100607065324.GA25590@core.coreip.homeip.net>
> > References : http://marc.info/?l=linux-kernel&m=127589362011138&w=2
> I confirm this.
> Its direct result of adding '+' to kernel version.
> This just causes only troubles.
> I suggest to have a config option for it.
Thanks for the updates.
Rafael
^ permalink raw reply
* Re: [PATCH net-next-2.6] sfc: Implement ethtool register dump operation
From: Jeff Garzik @ 2010-06-21 18:08 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1277142725.2100.36.camel@achroite.uk.solarflarecom.com>
On 06/21/2010 01:52 PM, Ben Hutchings wrote:
> On Mon, 2010-06-21 at 13:39 -0400, Jeff Garzik wrote:
>> On 06/21/2010 09:06 AM, Ben Hutchings wrote:
>>> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
>>> ---
>>> drivers/net/sfc/ethtool.c | 16 +++
>>> drivers/net/sfc/io.h | 7 +
>>> drivers/net/sfc/nic.c | 266 +++++++++++++++++++++++++++++++++++++++++++++
>>> drivers/net/sfc/nic.h | 3 +
>>> 4 files changed, 292 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
>>> index 22026bf..81b7f39 100644
>>> --- a/drivers/net/sfc/ethtool.c
>>> +++ b/drivers/net/sfc/ethtool.c
>>> @@ -242,6 +242,20 @@ static void efx_ethtool_get_drvinfo(struct net_device *net_dev,
>>> strlcpy(info->bus_info, pci_name(efx->pci_dev), sizeof(info->bus_info));
>>> }
>>>
>>> +static int efx_ethtool_get_regs_len(struct net_device *net_dev)
>>> +{
>>> + return efx_nic_get_regs_len(netdev_priv(net_dev));
>>> +}
>>> +
>>> +static void efx_ethtool_get_regs(struct net_device *net_dev,
>>> + struct ethtool_regs *regs, void *buf)
>>> +{
>>> + struct efx_nic *efx = netdev_priv(net_dev);
>>> +
>>> + regs->version = efx->type->revision;
>>> + efx_nic_get_regs(efx, buf);
>>
>> regs->version is really the version of hardware register dump exported
>> to userspace. You might want to hardcode this in the driver, to be
>> changed when efx_nic_regs[] array changes, rather than tying
>> regs->version directly to the SFC hardware architecture revision.
>>
>> However, if that limitation is OK with you, ie. ethtool register dump
>> code will change when h/w arch rev changes, then
>
> This is exactly what we want, as the set of defined registers (and
> fields within each register) will change in each architecture revision.
> (It may not change in each chip revision, but efx_nic_type::revision is
> supposed to reflect the architecture revision.)
>
> Although this code doesn't include an explicit format version, we can
> consider the current format to be version 0 and increment it if we ever
> want to make changes to the format for existing NIC revisions.
Yep -- that's the intented purpose. If you ever want to dump additional
registers or information, it might be useful to avoid a hard coupling
with the hardware arch revision.
Either way is fine, of course.
Jeff
^ permalink raw reply
* Re: PATCH: uninitialized memory access in tcp_parse_options
From: Mitchell Erblich @ 2010-06-21 18:02 UTC (permalink / raw)
To: Mathieu Lacage; +Cc: netdev
In-Reply-To: <1277127249.9469.53.camel@localhost.localdomain>
Mathieu Lacage,
The standard default for TCP with IPv4 is 536, which
translates to 576 MTU.
Thus, why don't you init mss to 536?
Mitchell Erblich
===============
On Jun 21, 2010, at 6:34 AM, Mathieu Lacage wrote:
> valgrind reports the following error:
>
> ==15996== Conditional jump or move depends on uninitialised value(s)
> ==15996== at 0x6E63E4C: tcp_parse_options (tcp_input.c:3776)
> ==15996== by 0x6E856A3: tcp_check_req (tcp_minisocks.c:532)
> ==15996== by 0x6E7F0C6: tcp_v4_hnd_req (tcp_ipv4.c:1492)
> ==15996== by 0x6E7F55A: tcp_v4_do_rcv (tcp_ipv4.c:1571)
> ==15996== by 0x6E808C5: tcp_v4_rcv (tcp_ipv4.c:1690)
> ==15996== by 0x6E2DA7B: ip_local_deliver_finish (ip_input.c:231)
> ==15996== by 0x6E2DE0C: ip_local_deliver (netfilter.h:206)
> ==15996== by 0x6E2E940: ip_rcv_finish (dst.h:255)
> ==15996== by 0x6E2F17C: ip_rcv (netfilter.h:206)
> ==15996== by 0x6D53D0E: __netif_receive_skb (dev.c:2873)
> ==15996== by 0x6D5521F: process_backlog (dev.c:3305)
> ==15996== by 0x6D55A20: net_rx_action (dev.c:3435)
>
> The attached patch (generated against net-next-2.6) fixes that error by
> making sure that user_mss is correctly initialized at the start of
> tcp_parse_options, just like saw_tstamp is initialized at the start of
> this function. To try to be coherent, this patch also removes the
> redundant initialization of saw_tstamp from the caller, tcp_check_req.
>
> hope this helps,
> Mathieu
> --
> Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
> Tel: +33 4 9238 5056
> <tcp-options.patch>
^ permalink raw reply
* Re: [PATCH net-next-2.6] sfc: Implement ethtool register dump operation
From: Ben Hutchings @ 2010-06-21 17:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <4C1FA3C1.4020006@garzik.org>
On Mon, 2010-06-21 at 13:39 -0400, Jeff Garzik wrote:
> On 06/21/2010 09:06 AM, Ben Hutchings wrote:
> > Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> > ---
> > drivers/net/sfc/ethtool.c | 16 +++
> > drivers/net/sfc/io.h | 7 +
> > drivers/net/sfc/nic.c | 266 +++++++++++++++++++++++++++++++++++++++++++++
> > drivers/net/sfc/nic.h | 3 +
> > 4 files changed, 292 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
> > index 22026bf..81b7f39 100644
> > --- a/drivers/net/sfc/ethtool.c
> > +++ b/drivers/net/sfc/ethtool.c
> > @@ -242,6 +242,20 @@ static void efx_ethtool_get_drvinfo(struct net_device *net_dev,
> > strlcpy(info->bus_info, pci_name(efx->pci_dev), sizeof(info->bus_info));
> > }
> >
> > +static int efx_ethtool_get_regs_len(struct net_device *net_dev)
> > +{
> > + return efx_nic_get_regs_len(netdev_priv(net_dev));
> > +}
> > +
> > +static void efx_ethtool_get_regs(struct net_device *net_dev,
> > + struct ethtool_regs *regs, void *buf)
> > +{
> > + struct efx_nic *efx = netdev_priv(net_dev);
> > +
> > + regs->version = efx->type->revision;
> > + efx_nic_get_regs(efx, buf);
>
> regs->version is really the version of hardware register dump exported
> to userspace. You might want to hardcode this in the driver, to be
> changed when efx_nic_regs[] array changes, rather than tying
> regs->version directly to the SFC hardware architecture revision.
>
> However, if that limitation is OK with you, ie. ethtool register dump
> code will change when h/w arch rev changes, then
This is exactly what we want, as the set of defined registers (and
fields within each register) will change in each architecture revision.
(It may not change in each chip revision, but efx_nic_type::revision is
supposed to reflect the architecture revision.)
Although this code doesn't include an explicit format version, we can
consider the current format to be version 0 and increment it if we ever
want to make changes to the format for existing NIC revisions.
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
>
> This is a ABI-related choice, so it deserves a bit of consideration.
I *think* I know what I'm doing here. :-)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [PATCH net-next-2.6] sfc: Implement ethtool register dump operation
From: Jeff Garzik @ 2010-06-21 17:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1277125613.2100.9.camel@achroite.uk.solarflarecom.com>
On 06/21/2010 09:06 AM, Ben Hutchings wrote:
> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> ---
> drivers/net/sfc/ethtool.c | 16 +++
> drivers/net/sfc/io.h | 7 +
> drivers/net/sfc/nic.c | 266 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/net/sfc/nic.h | 3 +
> 4 files changed, 292 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
> index 22026bf..81b7f39 100644
> --- a/drivers/net/sfc/ethtool.c
> +++ b/drivers/net/sfc/ethtool.c
> @@ -242,6 +242,20 @@ static void efx_ethtool_get_drvinfo(struct net_device *net_dev,
> strlcpy(info->bus_info, pci_name(efx->pci_dev), sizeof(info->bus_info));
> }
>
> +static int efx_ethtool_get_regs_len(struct net_device *net_dev)
> +{
> + return efx_nic_get_regs_len(netdev_priv(net_dev));
> +}
> +
> +static void efx_ethtool_get_regs(struct net_device *net_dev,
> + struct ethtool_regs *regs, void *buf)
> +{
> + struct efx_nic *efx = netdev_priv(net_dev);
> +
> + regs->version = efx->type->revision;
> + efx_nic_get_regs(efx, buf);
regs->version is really the version of hardware register dump exported
to userspace. You might want to hardcode this in the driver, to be
changed when efx_nic_regs[] array changes, rather than tying
regs->version directly to the SFC hardware architecture revision.
However, if that limitation is OK with you, ie. ethtool register dump
code will change when h/w arch rev changes, then
Acked-by: Jeff Garzik <jgarzik@redhat.com>
This is a ABI-related choice, so it deserves a bit of consideration.
Regards,
Jeff
^ permalink raw reply
* RE: [PATCH] kernel 2.6.35: ixgbe: skip non IPv4 packets in ATR filter
From: Skidmore, Donald C @ 2010-06-21 17:35 UTC (permalink / raw)
To: Guillaume Gaudonville, netdev@vger.kernel.org
Cc: Kirsher, Jeffrey T, Waskiewicz Jr, Peter P,
Chilakala, Mallikarjuna
In-Reply-To: <4C1F637E.8010005@6wind.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Guillaume Gaudonville
>Sent: Monday, June 21, 2010 6:05 AM
>To: netdev@vger.kernel.org
>Cc: Kirsher, Jeffrey T; Waskiewicz Jr, Peter P; Chilakala, Mallikarjuna
>Subject: [PATCH] kernel 2.6.35: ixgbe: skip non IPv4 packets in ATR filter
>
>Hello,
>
>In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just
>add a test to check skb->protocol:
>
> From fcb81aa89b6819f95349a4ed8c30f0629430aa1d Mon Sep 17 00:00:00 2001
>From: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
>Date: Thu, 17 Jun 2010 16:02:14 +0200
>Subject: [PATCH] ixgbe: skip non IPv4 packets in ATR filter
>
>It may crash on short packets due to ip_hdr() access.
>
>Signed-off-by: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
>---
> drivers/net/ixgbe/ixgbe_main.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/net/ixgbe/ixgbe_main.c
>b/drivers/net/ixgbe/ixgbe_main.c
>index b2af2f6..3581dbe 100644
>--- a/drivers/net/ixgbe/ixgbe_main.c
>+++ b/drivers/net/ixgbe/ixgbe_main.c
>@@ -6019,7 +6019,6 @@ static void ixgbe_tx_queue(struct ixgbe_adapter
>*adapter,
> static void ixgbe_atr(struct ixgbe_adapter *adapter, struct sk_buff *skb,
> int queue, u32 tx_flags)
> {
>- /* Right now, we support IPv4 only */
> struct ixgbe_atr_input atr_input;
> struct tcphdr *th;
> struct iphdr *iph = ip_hdr(skb);
>@@ -6028,6 +6027,10 @@ static void ixgbe_atr(struct ixgbe_adapter
>*adapter, struct sk_buff *skb,
> u32 src_ipv4_addr, dst_ipv4_addr;
> u8 l4type = 0;
>
>+ /* Right now, we support IPv4 only */
>+ if (skb->protocol != htons(ETH_P_IP))
>+ return;
>+
> /* check if we're UDP or TCP */
> if (iph->protocol == IPPROTO_TCP) {
> th = tcp_hdr(skb);
>--
>1.5.6.5
>
>--
>Guillaume Gaudonville
>guillaume.gaudonville@6wind.com
>
>--
>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
This patch has been pulled into our internal tree for testing.
Thanks,
-Don
<donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the net tree
From: Paul E. McKenney @ 2010-06-21 17:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Jiri Pirko, David Miller, netdev
In-Reply-To: <20100621161609.935d0085.sfr@canb.auug.org.au>
On Mon, Jun 21, 2010 at 04:16:09PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> net/bridge/br_fdb.c net/bridge/netfilter/ebt_redirect.c
> net/bridge/netfilter/ebt_ulog.c net/bridge/netfilter/ebtables.c
> net/netfilter/nfnetlink_log.c between commit
> f350a0a87374418635689471606454abc7beaa3a ("bridge: use rx_handler_data
> pointer to store net_bridge_port pointer") from the net tree and commit
> 81bdf5bd7349bd4523538cbd7878f334bc2bfe14 ("net: Make accesses to
> ->br_port safe for sparse RCU") from the tip tree.
>
> The net tree commit looks like a superset of the tip tree commit, so I
> effectively reverted the tip tree commit.
I defer to Jiri on this one, and will withdraw my patch.
Thanx, Paul
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Stephen Hemminger @ 2010-06-21 17:25 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Andreas Klauer, netdev, Octavian Purdila
In-Reply-To: <20100621162518.GA5972@nuttenaction>
The OOPS is here
static void ndisc_send_na(struct net_device *dev, struct neighbour *neigh,
const struct in6_addr *daddr,
const struct in6_addr *solicited_addr,
int router, int solicited, int override, int inc_opt)
{
...
/* for anycast or proxy, solicited_addr != src_addr */
ifp = ipv6_get_ifaddr(dev_net(dev), solicited_addr, dev, 1);
if (ifp) {
src_addr = solicited_addr;
if (ifp->flags & IFA_F_OPTIMISTIC)
override = 0;
in6_ifa_put(ifp);
} else {
if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
inet6_sk(dev_net(dev)->ipv6.ndisc_sk)->srcprefs,
&tmpaddr))
return;
src_addr = &tmpaddr;
}
icmp6h.icmp6_router = router;
icmp6h.icmp6_solicited = solicited;
icmp6h.icmp6_override = override;
inc_opt |= ifp->idev->cnf.force_tllao;
And it caused by this recent commit.
Author: Octavian Purdila <opurdila@ixiacom.com> 2009-10-02 04:39:15
Committer: David S. Miller <davem@davemloft.net> 2009-10-07 01:10:45
Parent: d1f8297a96b0d70f17704296a6666468f2087ce6 (Revert "sit: stateless autoconf for isatap")
Child: d7fc02c7bae7b1cf69269992cf880a43a350cdaa (Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6)
Branches: addrconf, master, remotes/origin/master
Follows: v2.6.32-rc3
Precedes: v2.6.33-rc1
make TLLAO option for NA packets configurable
On Friday 02 October 2009 20:53:51 you wrote:
> This is good although I would have shortened the name.
Ah, I knew I forgot something :) Here is v4.
tavi
>From 24d96d825b9fa832b22878cc6c990d5711968734 Mon Sep 17 00:00:00 2001
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Fri, 2 Oct 2009 00:51:15 +0300
Subject: [PATCH] ipv6: new sysctl for sending TLLAO with unicast NAs
Neighbor advertisements responding to unicast neighbor solicitations
did not include the target link-layer address option. This patch adds
a new sysctl option (disabled by default) which controls whether this
option should be sent even with unicast NAs.
The need for this arose because certain routers expect the TLLAO in
some situations even as a response to unicast NS packets.
Moreover, RFC 2461 recommends sending this to avoid a race condition
(section 4.4, Target link-layer address)
Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is not handling the case of ifp == NULL.
Maybe the following (move the assignment into the if block).
--- a/net/ipv6/ndisc.c 2010-06-21 10:22:20.825637690 -0700
+++ b/net/ipv6/ndisc.c 2010-06-21 10:24:31.573011996 -0700
@@ -586,6 +586,7 @@ static void ndisc_send_na(struct net_dev
src_addr = solicited_addr;
if (ifp->flags & IFA_F_OPTIMISTIC)
override = 0;
+ inc_opt |= ifp->idev->cnf.force_tllao;
in6_ifa_put(ifp);
} else {
if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
@@ -599,7 +600,6 @@ static void ndisc_send_na(struct net_dev
icmp6h.icmp6_solicited = solicited;
icmp6h.icmp6_override = override;
- inc_opt |= ifp->idev->cnf.force_tllao;
__ndisc_send(dev, neigh, daddr, src_addr,
&icmp6h, solicited_addr,
inc_opt ? ND_OPT_TARGET_LL_ADDR : 0);
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Andreas Klauer @ 2010-06-21 16:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20100621091946.63f26b21@nehalam>
On Mon, Jun 21, 2010 at 09:19:46AM -0700, Stephen Hemminger wrote:
> Unfortunately, Greg seems to be slow in getting 2.6.34.1 out.
> These patches are related:
>
> http://marc.info/?l=linux-netdev&m=127472600330413
> http://marc.info/?l=linux-netdev&m=127472599530407
Thank you for your reply. I will test if these patches help ASAP.
In the meantime, I also reproduced the issue with 2.6.33.5.
Regards
Andreas Klauer
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Hagen Paul Pfeifer @ 2010-06-21 16:25 UTC (permalink / raw)
To: Andreas Klauer; +Cc: netdev
In-Reply-To: <20100621153018.GA2433@EIS>
* Andreas Klauer | 2010-06-21 17:30:18 [+0200]:
>Hi,
>
>no one replied so far - am I reporting this to the wrong place?
>Please advise.
It is the right place, some guys are in holiday but probably you can git
bisect the problem?
HGN
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Stephen Hemminger @ 2010-06-21 16:19 UTC (permalink / raw)
To: Andreas Klauer; +Cc: netdev
In-Reply-To: <20100621153018.GA2433@EIS>
On Mon, 21 Jun 2010 17:30:18 +0200
Andreas Klauer <Andreas.Klauer@metamorpher.de> wrote:
> Hi,
>
> no one replied so far - am I reporting this to the wrong place?
> Please advise.
>
> I've done some more testing; I can reproduce the issue now on different
> hardware (my desktop at home), with a clean environment (freshly boot-
> strapped Debian Lenny). Which should make things more interesting.
>
> The issue seems to be compiler related. It occurs if the kernel is
> compiled with Debian Lenny "gcc (Debian 4.3.2-1.1) 4.3.2". It does
> not occur (or at least I can't reproduce it) if the kernel was
> compiled with Gentoo "gcc (Gentoo 4.4.4 p1.0) 4.4.4".
>
> Screenshot:
> http://www.metamorpher.de/kernel/panic2.jpg
>
> Steps to reproduce:
> http://www.metamorpher.de/kernel/steps-to-reproduce.txt
>
> kernel config and lspci also available here:
> http://www.metamorpher.de/kernel/
>
> Regards
> Andreas Klauer
> --
> 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
Unfortunately, Greg seems to be slow in getting 2.6.34.1 out.
These patches are related:
http://marc.info/?l=linux-netdev&m=127472600330413
http://marc.info/?l=linux-netdev&m=127472599530407
--
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Andreas Klauer @ 2010-06-21 15:30 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100619175352.GA8482@EIS>
Hi,
no one replied so far - am I reporting this to the wrong place?
Please advise.
I've done some more testing; I can reproduce the issue now on different
hardware (my desktop at home), with a clean environment (freshly boot-
strapped Debian Lenny). Which should make things more interesting.
The issue seems to be compiler related. It occurs if the kernel is
compiled with Debian Lenny "gcc (Debian 4.3.2-1.1) 4.3.2". It does
not occur (or at least I can't reproduce it) if the kernel was
compiled with Gentoo "gcc (Gentoo 4.4.4 p1.0) 4.4.4".
Screenshot:
http://www.metamorpher.de/kernel/panic2.jpg
Steps to reproduce:
http://www.metamorpher.de/kernel/steps-to-reproduce.txt
kernel config and lspci also available here:
http://www.metamorpher.de/kernel/
Regards
Andreas Klauer
^ permalink raw reply
* [PATCH 2/2 v2] Driver core: reduce duplicated code
From: Uwe Kleine-König @ 2010-06-21 14:11 UTC (permalink / raw)
To: Greg KH
Cc: Randy Dunlap, Dmitry Torokhov, Uwe Kleine-König,
Anisse Astier, Greg Kroah-Hartman, Magnus Damm, Rafael J. Wysocki,
Paul Mundt, Eric Miao, linux-doc, linux-kernel, netdev
In-Reply-To: <20100618073950.GA12822@pengutronix.de>
This makes the two similar functions platform_device_register_simple
and platform_device_register_data one line inline functions using a new
generic function platform_device_register_resndata.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
still unsolved is the naming issue, what do you think about
platform_device_register?
I marked the new function as __init_or_module in a separate patch to
make reverting it a bit easier, still I think it should be possible to
fix the caller if a problem occurs.
I changed the semantic slightly to only call
platform_device_add_resources if data != NULL instead of size != 0. The
idea is to support wrappers like:
#define add_blablub(id, pdata) \
platform_device_register_resndata(NULL, "blablub", id, \
NULL, 0, pdata, sizeof(struct blablub_platform_data))
that don't fail if pdata=NULL. Ditto for res.
Best regards
Uwe
changed since v1:
- fix docbook to pick up platform_device_register_simple and
platform_device_register_data after moving them to
<linux/platform_device.h>
- only add_resources and add_data if res and data are non-NULL resp.
Documentation/DocBook/device-drivers.tmpl | 1 +
drivers/base/platform.c | 104 +++++++---------------------
include/linux/platform_device.h | 62 ++++++++++++++++-
3 files changed, 85 insertions(+), 82 deletions(-)
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
index 1b2dd4f..ecd35e9 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -111,6 +111,7 @@ X!Edrivers/base/attribute_container.c
<!--
X!Edrivers/base/interface.c
-->
+!Iinclude/linux/platform_device.h
!Edrivers/base/platform.c
!Edrivers/base/bus.c
</sect1>
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 26eb69d..ffcfd73 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -344,108 +344,56 @@ void platform_device_unregister(struct platform_device *pdev)
EXPORT_SYMBOL_GPL(platform_device_unregister);
/**
- * platform_device_register_simple - add a platform-level device and its resources
- * @name: base name of the device we're adding
- * @id: instance id
- * @res: set of resources that needs to be allocated for the device
- * @num: number of resources
- *
- * This function creates a simple platform device that requires minimal
- * resource and memory management. Canned release function freeing memory
- * allocated for the device allows drivers using such devices to be
- * unloaded without waiting for the last reference to the device to be
- * dropped.
+ * platform_device_register_resndata - add a platform-level device with
+ * resources and platform-specific data
*
- * This interface is primarily intended for use with legacy drivers which
- * probe hardware directly. Because such drivers create sysfs device nodes
- * themselves, rather than letting system infrastructure handle such device
- * enumeration tasks, they don't fully conform to the Linux driver model.
- * In particular, when such drivers are built as modules, they can't be
- * "hotplugged".
- *
- * Returns &struct platform_device pointer on success, or ERR_PTR() on error.
- */
-struct platform_device *platform_device_register_simple(const char *name,
- int id,
- const struct resource *res,
- unsigned int num)
-{
- struct platform_device *pdev;
- int retval;
-
- pdev = platform_device_alloc(name, id);
- if (!pdev) {
- retval = -ENOMEM;
- goto error;
- }
-
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
-
- retval = platform_device_add(pdev);
- if (retval)
- goto error;
-
- return pdev;
-
-error:
- platform_device_put(pdev);
- return ERR_PTR(retval);
-}
-EXPORT_SYMBOL_GPL(platform_device_register_simple);
-
-/**
- * platform_device_register_data - add a platform-level device with platform-specific data
* @parent: parent device for the device we're adding
* @name: base name of the device we're adding
* @id: instance id
+ * @res: set of resources that needs to be allocated for the device
+ * @num: number of resources
* @data: platform specific data for this platform device
* @size: size of platform specific data
*
- * This function creates a simple platform device that requires minimal
- * resource and memory management. Canned release function freeing memory
- * allocated for the device allows drivers using such devices to be
- * unloaded without waiting for the last reference to the device to be
- * dropped.
- *
* Returns &struct platform_device pointer on success, or ERR_PTR() on error.
*/
-struct platform_device *platform_device_register_data(
+struct platform_device *platform_device_register_resndata(
struct device *parent,
const char *name, int id,
+ const struct resource *res, unsigned int num,
const void *data, size_t size)
{
+ int ret = -ENOMEM;
struct platform_device *pdev;
- int retval;
pdev = platform_device_alloc(name, id);
- if (!pdev) {
- retval = -ENOMEM;
- goto error;
- }
+ if (!pdev)
+ goto err;
pdev->dev.parent = parent;
- if (size) {
- retval = platform_device_add_data(pdev, data, size);
- if (retval)
- goto error;
+ if (res) {
+ ret = platform_device_add_resources(pdev, res, num);
+ if (ret)
+ goto err;
}
- retval = platform_device_add(pdev);
- if (retval)
- goto error;
+ if (data) {
+ ret = platform_device_add_data(pdev, data, size);
+ if (ret)
+ goto err;
+ }
- return pdev;
+ ret = platform_device_add(pdev);
+ if (ret) {
+err:
+ platform_device_put(pdev);
+ return ERR_PTR(ret);
+ }
-error:
- platform_device_put(pdev);
- return ERR_PTR(retval);
+ return pdev;
}
-EXPORT_SYMBOL_GPL(platform_device_register_data);
+EXPORT_SYMBOL_GPL(platform_device_register_resndata);
static int platform_drv_probe(struct device *_dev)
{
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 5417944..d7ecad0 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -43,10 +43,64 @@ extern struct resource *platform_get_resource_byname(struct platform_device *, u
extern int platform_get_irq_byname(struct platform_device *, const char *);
extern int platform_add_devices(struct platform_device **, int);
-extern struct platform_device *platform_device_register_simple(const char *, int id,
- const struct resource *, unsigned int);
-extern struct platform_device *platform_device_register_data(struct device *,
- const char *, int, const void *, size_t);
+extern struct platform_device *platform_device_register_resndata(
+ struct device *parent, const char *name, int id,
+ const struct resource *res, unsigned int num,
+ const void *data, size_t size);
+
+/**
+ * platform_device_register_simple - add a platform-level device and its resources
+ * @name: base name of the device we're adding
+ * @id: instance id
+ * @res: set of resources that needs to be allocated for the device
+ * @num: number of resources
+ *
+ * This function creates a simple platform device that requires minimal
+ * resource and memory management. Canned release function freeing memory
+ * allocated for the device allows drivers using such devices to be
+ * unloaded without waiting for the last reference to the device to be
+ * dropped.
+ *
+ * This interface is primarily intended for use with legacy drivers which
+ * probe hardware directly. Because such drivers create sysfs device nodes
+ * themselves, rather than letting system infrastructure handle such device
+ * enumeration tasks, they don't fully conform to the Linux driver model.
+ * In particular, when such drivers are built as modules, they can't be
+ * "hotplugged".
+ *
+ * Returns &struct platform_device pointer on success, or ERR_PTR() on error.
+ */
+static inline struct platform_device *platform_device_register_simple(
+ const char *name, int id,
+ const struct resource *res, unsigned int num)
+{
+ return platform_device_register_resndata(NULL, name, id,
+ res, num, NULL, 0);
+}
+
+/**
+ * platform_device_register_data - add a platform-level device with platform-specific data
+ * @parent: parent device for the device we're adding
+ * @name: base name of the device we're adding
+ * @id: instance id
+ * @data: platform specific data for this platform device
+ * @size: size of platform specific data
+ *
+ * This function creates a simple platform device that requires minimal
+ * resource and memory management. Canned release function freeing memory
+ * allocated for the device allows drivers using such devices to be
+ * unloaded without waiting for the last reference to the device to be
+ * dropped.
+ *
+ * Returns &struct platform_device pointer on success, or ERR_PTR() on error.
+ */
+static inline struct platform_device *platform_device_register_data(
+ struct device *parent, const char *name, int id,
+ const void *data, size_t size)
+{
+ return platform_device_register_resndata(parent, name, id,
+ NULL, 0, data, size);
+}
extern struct platform_device *platform_device_alloc(const char *name, int id);
extern int platform_device_add_resources(struct platform_device *pdev,
--
1.7.1
^ permalink raw reply related
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Nick Bowler @ 2010-06-21 13:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <lc60d4toGTL.A.QzD._LpHMB@chimera>
On 00:11 Mon 21 Jun , Rafael J. Wysocki wrote:
> If you know of any other unresolved regressions from 2.6.34, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
Didn't see this one in the list:
Why is kslowd accumulating so much CPU time?
http://thread.gmane.org/gmane.linux.kernel/996907
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* [PATCH] NET: MIPSsim: Fix modpost warning.
From: Ralf Baechle @ 2010-06-21 13:44 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
$ make CONFIG_DEBUG_SECTION_MISMATCH=y
[...]
WARNING: drivers/net/built-in.o(.data+0x0): Section mismatch in reference from the variable mipsnet_driver to the function .init.text:mipsnet_probe()
The variable mipsnet_driver references
the function __init mipsnet_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
[...]
Fixed by making mipsnet_probe __devinit.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
drivers/net/mipsnet.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mipsnet.c b/drivers/net/mipsnet.c
index 8e9704f..869f0ea 100644
--- a/drivers/net/mipsnet.c
+++ b/drivers/net/mipsnet.c
@@ -247,7 +247,7 @@ static const struct net_device_ops mipsnet_netdev_ops = {
.ndo_set_mac_address = eth_mac_addr,
};
-static int __init mipsnet_probe(struct platform_device *dev)
+static int __devinit mipsnet_probe(struct platform_device *dev)
{
struct net_device *netdev;
int err;
^ permalink raw reply related
* PATCH: uninitialized memory access in tcp_parse_options
From: Mathieu Lacage @ 2010-06-21 13:34 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
valgrind reports the following error:
==15996== Conditional jump or move depends on uninitialised value(s)
==15996== at 0x6E63E4C: tcp_parse_options (tcp_input.c:3776)
==15996== by 0x6E856A3: tcp_check_req (tcp_minisocks.c:532)
==15996== by 0x6E7F0C6: tcp_v4_hnd_req (tcp_ipv4.c:1492)
==15996== by 0x6E7F55A: tcp_v4_do_rcv (tcp_ipv4.c:1571)
==15996== by 0x6E808C5: tcp_v4_rcv (tcp_ipv4.c:1690)
==15996== by 0x6E2DA7B: ip_local_deliver_finish (ip_input.c:231)
==15996== by 0x6E2DE0C: ip_local_deliver (netfilter.h:206)
==15996== by 0x6E2E940: ip_rcv_finish (dst.h:255)
==15996== by 0x6E2F17C: ip_rcv (netfilter.h:206)
==15996== by 0x6D53D0E: __netif_receive_skb (dev.c:2873)
==15996== by 0x6D5521F: process_backlog (dev.c:3305)
==15996== by 0x6D55A20: net_rx_action (dev.c:3435)
The attached patch (generated against net-next-2.6) fixes that error by
making sure that user_mss is correctly initialized at the start of
tcp_parse_options, just like saw_tstamp is initialized at the start of
this function. To try to be coherent, this patch also removes the
redundant initialization of saw_tstamp from the caller, tcp_check_req.
hope this helps,
Mathieu
--
Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
Tel: +33 4 9238 5056
[-- Attachment #2: tcp-options.patch --]
[-- Type: text/x-patch, Size: 855 bytes --]
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ae3ec15..8b713ab 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3751,6 +3751,7 @@ void tcp_parse_options(struct sk_buff *skb, struct tcp_options_received *opt_rx,
ptr = (unsigned char *)(th + 1);
opt_rx->saw_tstamp = 0;
+ opt_rx->user_mss = 0;
while (length > 0) {
int opcode = *ptr++;
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 794c2e1..21e47e7 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -527,7 +527,6 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
__be32 flg = tcp_flag_word(th) & (TCP_FLAG_RST|TCP_FLAG_SYN|TCP_FLAG_ACK);
int paws_reject = 0;
- tmp_opt.saw_tstamp = 0;
if (th->doff > (sizeof(struct tcphdr)>>2)) {
tcp_parse_options(skb, &tmp_opt, &hash_location, 0);
^ permalink raw reply related
* [PATCH net-next-2.6] sfc: Implement ethtool register dump operation
From: Ben Hutchings @ 2010-06-21 13:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/ethtool.c | 16 +++
drivers/net/sfc/io.h | 7 +
drivers/net/sfc/nic.c | 266 +++++++++++++++++++++++++++++++++++++++++++++
drivers/net/sfc/nic.h | 3 +
4 files changed, 292 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
index 22026bf..81b7f39 100644
--- a/drivers/net/sfc/ethtool.c
+++ b/drivers/net/sfc/ethtool.c
@@ -242,6 +242,20 @@ static void efx_ethtool_get_drvinfo(struct net_device *net_dev,
strlcpy(info->bus_info, pci_name(efx->pci_dev), sizeof(info->bus_info));
}
+static int efx_ethtool_get_regs_len(struct net_device *net_dev)
+{
+ return efx_nic_get_regs_len(netdev_priv(net_dev));
+}
+
+static void efx_ethtool_get_regs(struct net_device *net_dev,
+ struct ethtool_regs *regs, void *buf)
+{
+ struct efx_nic *efx = netdev_priv(net_dev);
+
+ regs->version = efx->type->revision;
+ efx_nic_get_regs(efx, buf);
+}
+
/**
* efx_fill_test - fill in an individual self-test entry
* @test_index: Index of the test
@@ -834,6 +848,8 @@ const struct ethtool_ops efx_ethtool_ops = {
.get_settings = efx_ethtool_get_settings,
.set_settings = efx_ethtool_set_settings,
.get_drvinfo = efx_ethtool_get_drvinfo,
+ .get_regs_len = efx_ethtool_get_regs_len,
+ .get_regs = efx_ethtool_get_regs,
.nway_reset = efx_ethtool_nway_reset,
.get_link = efx_ethtool_get_link,
.get_eeprom_len = efx_ethtool_get_eeprom_len,
diff --git a/drivers/net/sfc/io.h b/drivers/net/sfc/io.h
index b89177c..4317574 100644
--- a/drivers/net/sfc/io.h
+++ b/drivers/net/sfc/io.h
@@ -211,6 +211,13 @@ static inline void efx_writed_table(struct efx_nic *efx, efx_dword_t *value,
efx_writed(efx, value, reg + index * sizeof(efx_oword_t));
}
+/* Read from a dword register forming part of a table */
+static inline void efx_readd_table(struct efx_nic *efx, efx_dword_t *value,
+ unsigned int reg, unsigned int index)
+{
+ efx_readd(efx, value, reg + index * sizeof(efx_dword_t));
+}
+
/* Page-mapped register block size */
#define EFX_PAGE_BLOCK_SIZE 0x2000
diff --git a/drivers/net/sfc/nic.c b/drivers/net/sfc/nic.c
index 0ee6fd3..67235f1 100644
--- a/drivers/net/sfc/nic.c
+++ b/drivers/net/sfc/nic.c
@@ -1627,3 +1627,269 @@ void efx_nic_init_common(struct efx_nic *efx)
EFX_SET_OWORD_FIELD(temp, FRF_BZ_TX_FLUSH_MIN_LEN_EN, 1);
efx_writeo(efx, &temp, FR_AZ_TX_RESERVED);
}
+
+/* Register dump */
+
+#define REGISTER_REVISION_A 1
+#define REGISTER_REVISION_B 2
+#define REGISTER_REVISION_C 3
+#define REGISTER_REVISION_Z 3 /* latest revision */
+
+struct efx_nic_reg {
+ u32 offset:24;
+ u32 min_revision:2, max_revision:2;
+};
+
+#define REGISTER(name, min_rev, max_rev) { \
+ FR_ ## min_rev ## max_rev ## _ ## name, \
+ REGISTER_REVISION_ ## min_rev, REGISTER_REVISION_ ## max_rev \
+}
+#define REGISTER_AA(name) REGISTER(name, A, A)
+#define REGISTER_AB(name) REGISTER(name, A, B)
+#define REGISTER_AZ(name) REGISTER(name, A, Z)
+#define REGISTER_BB(name) REGISTER(name, B, B)
+#define REGISTER_BZ(name) REGISTER(name, B, Z)
+#define REGISTER_CZ(name) REGISTER(name, C, Z)
+
+static const struct efx_nic_reg efx_nic_regs[] = {
+ REGISTER_AZ(ADR_REGION),
+ REGISTER_AZ(INT_EN_KER),
+ REGISTER_BZ(INT_EN_CHAR),
+ REGISTER_AZ(INT_ADR_KER),
+ REGISTER_BZ(INT_ADR_CHAR),
+ /* INT_ACK_KER is WO */
+ /* INT_ISR0 is RC */
+ REGISTER_AZ(HW_INIT),
+ REGISTER_CZ(USR_EV_CFG),
+ REGISTER_AB(EE_SPI_HCMD),
+ REGISTER_AB(EE_SPI_HADR),
+ REGISTER_AB(EE_SPI_HDATA),
+ REGISTER_AB(EE_BASE_PAGE),
+ REGISTER_AB(EE_VPD_CFG0),
+ /* EE_VPD_SW_CNTL and EE_VPD_SW_DATA are not used */
+ /* PMBX_DBG_IADDR and PBMX_DBG_IDATA are indirect */
+ /* PCIE_CORE_INDIRECT is indirect */
+ REGISTER_AB(NIC_STAT),
+ REGISTER_AB(GPIO_CTL),
+ REGISTER_AB(GLB_CTL),
+ /* FATAL_INTR_KER and FATAL_INTR_CHAR are partly RC */
+ REGISTER_BZ(DP_CTRL),
+ REGISTER_AZ(MEM_STAT),
+ REGISTER_AZ(CS_DEBUG),
+ REGISTER_AZ(ALTERA_BUILD),
+ REGISTER_AZ(CSR_SPARE),
+ REGISTER_AB(PCIE_SD_CTL0123),
+ REGISTER_AB(PCIE_SD_CTL45),
+ REGISTER_AB(PCIE_PCS_CTL_STAT),
+ /* DEBUG_DATA_OUT is not used */
+ /* DRV_EV is WO */
+ REGISTER_AZ(EVQ_CTL),
+ REGISTER_AZ(EVQ_CNT1),
+ REGISTER_AZ(EVQ_CNT2),
+ REGISTER_AZ(BUF_TBL_CFG),
+ REGISTER_AZ(SRM_RX_DC_CFG),
+ REGISTER_AZ(SRM_TX_DC_CFG),
+ REGISTER_AZ(SRM_CFG),
+ /* BUF_TBL_UPD is WO */
+ REGISTER_AZ(SRM_UPD_EVQ),
+ REGISTER_AZ(SRAM_PARITY),
+ REGISTER_AZ(RX_CFG),
+ REGISTER_BZ(RX_FILTER_CTL),
+ /* RX_FLUSH_DESCQ is WO */
+ REGISTER_AZ(RX_DC_CFG),
+ REGISTER_AZ(RX_DC_PF_WM),
+ REGISTER_BZ(RX_RSS_TKEY),
+ /* RX_NODESC_DROP is RC */
+ REGISTER_AA(RX_SELF_RST),
+ /* RX_DEBUG, RX_PUSH_DROP are not used */
+ REGISTER_CZ(RX_RSS_IPV6_REG1),
+ REGISTER_CZ(RX_RSS_IPV6_REG2),
+ REGISTER_CZ(RX_RSS_IPV6_REG3),
+ /* TX_FLUSH_DESCQ is WO */
+ REGISTER_AZ(TX_DC_CFG),
+ REGISTER_AA(TX_CHKSM_CFG),
+ REGISTER_AZ(TX_CFG),
+ /* TX_PUSH_DROP is not used */
+ REGISTER_AZ(TX_RESERVED),
+ REGISTER_BZ(TX_PACE),
+ /* TX_PACE_DROP_QID is RC */
+ REGISTER_BB(TX_VLAN),
+ REGISTER_BZ(TX_IPFIL_PORTEN),
+ REGISTER_AB(MD_TXD),
+ REGISTER_AB(MD_RXD),
+ REGISTER_AB(MD_CS),
+ REGISTER_AB(MD_PHY_ADR),
+ REGISTER_AB(MD_ID),
+ /* MD_STAT is RC */
+ REGISTER_AB(MAC_STAT_DMA),
+ REGISTER_AB(MAC_CTRL),
+ REGISTER_BB(GEN_MODE),
+ REGISTER_AB(MAC_MC_HASH_REG0),
+ REGISTER_AB(MAC_MC_HASH_REG1),
+ REGISTER_AB(GM_CFG1),
+ REGISTER_AB(GM_CFG2),
+ /* GM_IPG and GM_HD are not used */
+ REGISTER_AB(GM_MAX_FLEN),
+ /* GM_TEST is not used */
+ REGISTER_AB(GM_ADR1),
+ REGISTER_AB(GM_ADR2),
+ REGISTER_AB(GMF_CFG0),
+ REGISTER_AB(GMF_CFG1),
+ REGISTER_AB(GMF_CFG2),
+ REGISTER_AB(GMF_CFG3),
+ REGISTER_AB(GMF_CFG4),
+ REGISTER_AB(GMF_CFG5),
+ REGISTER_BB(TX_SRC_MAC_CTL),
+ REGISTER_AB(XM_ADR_LO),
+ REGISTER_AB(XM_ADR_HI),
+ REGISTER_AB(XM_GLB_CFG),
+ REGISTER_AB(XM_TX_CFG),
+ REGISTER_AB(XM_RX_CFG),
+ REGISTER_AB(XM_MGT_INT_MASK),
+ REGISTER_AB(XM_FC),
+ REGISTER_AB(XM_PAUSE_TIME),
+ REGISTER_AB(XM_TX_PARAM),
+ REGISTER_AB(XM_RX_PARAM),
+ /* XM_MGT_INT_MSK (note no 'A') is RC */
+ REGISTER_AB(XX_PWR_RST),
+ REGISTER_AB(XX_SD_CTL),
+ REGISTER_AB(XX_TXDRV_CTL),
+ /* XX_PRBS_CTL, XX_PRBS_CHK and XX_PRBS_ERR are not used */
+ /* XX_CORE_STAT is partly RC */
+};
+
+struct efx_nic_reg_table {
+ u32 offset:24;
+ u32 min_revision:2, max_revision:2;
+ u32 step:6, rows:21;
+};
+
+#define REGISTER_TABLE_DIMENSIONS(_, offset, min_rev, max_rev, step, rows) { \
+ offset, \
+ REGISTER_REVISION_ ## min_rev, REGISTER_REVISION_ ## max_rev, \
+ step, rows \
+}
+#define REGISTER_TABLE(name, min_rev, max_rev) \
+ REGISTER_TABLE_DIMENSIONS( \
+ name, FR_ ## min_rev ## max_rev ## _ ## name, \
+ min_rev, max_rev, \
+ FR_ ## min_rev ## max_rev ## _ ## name ## _STEP, \
+ FR_ ## min_rev ## max_rev ## _ ## name ## _ROWS)
+#define REGISTER_TABLE_AA(name) REGISTER_TABLE(name, A, A)
+#define REGISTER_TABLE_AZ(name) REGISTER_TABLE(name, A, Z)
+#define REGISTER_TABLE_BB(name) REGISTER_TABLE(name, B, B)
+#define REGISTER_TABLE_BZ(name) REGISTER_TABLE(name, B, Z)
+#define REGISTER_TABLE_BB_CZ(name) \
+ REGISTER_TABLE_DIMENSIONS(name, FR_BZ_ ## name, B, B, \
+ FR_BZ_ ## name ## _STEP, \
+ FR_BB_ ## name ## _ROWS), \
+ REGISTER_TABLE_DIMENSIONS(name, FR_BZ_ ## name, C, Z, \
+ FR_BZ_ ## name ## _STEP, \
+ FR_CZ_ ## name ## _ROWS)
+#define REGISTER_TABLE_CZ(name) REGISTER_TABLE(name, C, Z)
+
+static const struct efx_nic_reg_table efx_nic_reg_tables[] = {
+ /* DRIVER is not used */
+ /* EVQ_RPTR, TIMER_COMMAND, USR_EV and {RX,TX}_DESC_UPD are WO */
+ REGISTER_TABLE_BB(TX_IPFIL_TBL),
+ REGISTER_TABLE_BB(TX_SRC_MAC_TBL),
+ REGISTER_TABLE_AA(RX_DESC_PTR_TBL_KER),
+ REGISTER_TABLE_BB_CZ(RX_DESC_PTR_TBL),
+ REGISTER_TABLE_AA(TX_DESC_PTR_TBL_KER),
+ REGISTER_TABLE_BB_CZ(TX_DESC_PTR_TBL),
+ REGISTER_TABLE_AA(EVQ_PTR_TBL_KER),
+ REGISTER_TABLE_BB_CZ(EVQ_PTR_TBL),
+ /* The register buffer is allocated with slab, so we can't
+ * reasonably read all of the buffer table (up to 8MB!).
+ * However this driver will only use a few entries. Reading
+ * 1K entries allows for some expansion of queue count and
+ * size before we need to change the version. */
+ REGISTER_TABLE_DIMENSIONS(BUF_FULL_TBL_KER, FR_AA_BUF_FULL_TBL_KER,
+ A, A, 8, 1024),
+ REGISTER_TABLE_DIMENSIONS(BUF_FULL_TBL, FR_BZ_BUF_FULL_TBL,
+ B, Z, 8, 1024),
+ /* RX_FILTER_TBL{0,1} is huge and not used by this driver */
+ REGISTER_TABLE_CZ(RX_MAC_FILTER_TBL0),
+ REGISTER_TABLE_BB_CZ(TIMER_TBL),
+ REGISTER_TABLE_BB_CZ(TX_PACE_TBL),
+ REGISTER_TABLE_BZ(RX_INDIRECTION_TBL),
+ /* TX_FILTER_TBL0 is huge and not used by this driver */
+ REGISTER_TABLE_CZ(TX_MAC_FILTER_TBL0),
+ REGISTER_TABLE_CZ(MC_TREG_SMEM),
+ /* MSIX_PBA_TABLE is not mapped */
+ /* SRM_DBG is not mapped (and is redundant with BUF_FLL_TBL) */
+};
+
+size_t efx_nic_get_regs_len(struct efx_nic *efx)
+{
+ const struct efx_nic_reg *reg;
+ const struct efx_nic_reg_table *table;
+ size_t len = 0;
+
+ for (reg = efx_nic_regs;
+ reg < efx_nic_regs + ARRAY_SIZE(efx_nic_regs);
+ reg++)
+ if (efx->type->revision >= reg->min_revision &&
+ efx->type->revision <= reg->max_revision)
+ len += sizeof(efx_oword_t);
+
+ for (table = efx_nic_reg_tables;
+ table < efx_nic_reg_tables + ARRAY_SIZE(efx_nic_reg_tables);
+ table++)
+ if (efx->type->revision >= table->min_revision &&
+ efx->type->revision <= table->max_revision)
+ len += table->rows * min_t(size_t, table->step, 16);
+
+ return len;
+}
+
+void efx_nic_get_regs(struct efx_nic *efx, void *buf)
+{
+ const struct efx_nic_reg *reg;
+ const struct efx_nic_reg_table *table;
+
+ for (reg = efx_nic_regs;
+ reg < efx_nic_regs + ARRAY_SIZE(efx_nic_regs);
+ reg++) {
+ if (efx->type->revision >= reg->min_revision &&
+ efx->type->revision <= reg->max_revision) {
+ efx_reado(efx, (efx_oword_t *)buf, reg->offset);
+ buf += sizeof(efx_oword_t);
+ }
+ }
+
+ for (table = efx_nic_reg_tables;
+ table < efx_nic_reg_tables + ARRAY_SIZE(efx_nic_reg_tables);
+ table++) {
+ size_t size, i;
+
+ if (!(efx->type->revision >= table->min_revision &&
+ efx->type->revision <= table->max_revision))
+ continue;
+
+ size = min_t(size_t, table->step, 16);
+
+ for (i = 0; i < table->rows; i++) {
+ switch (table->step) {
+ case 4: /* 32-bit register or SRAM */
+ efx_readd_table(efx, buf, table->offset, i);
+ break;
+ case 8: /* 64-bit SRAM */
+ efx_sram_readq(efx,
+ efx->membase + table->offset,
+ buf, i);
+ break;
+ case 16: /* 128-bit register */
+ efx_reado_table(efx, buf, table->offset, i);
+ break;
+ case 32: /* 128-bit register, interleaved */
+ efx_reado_table(efx, buf, table->offset, 2 * i);
+ break;
+ default:
+ WARN_ON(1);
+ return;
+ }
+ buf += size;
+ }
+ }
+}
diff --git a/drivers/net/sfc/nic.h b/drivers/net/sfc/nic.h
index 95770e1..534461f 100644
--- a/drivers/net/sfc/nic.h
+++ b/drivers/net/sfc/nic.h
@@ -222,6 +222,9 @@ extern int efx_nic_test_registers(struct efx_nic *efx,
const struct efx_nic_register_test *regs,
size_t n_regs);
+extern size_t efx_nic_get_regs_len(struct efx_nic *efx);
+extern void efx_nic_get_regs(struct efx_nic *efx, void *buf);
+
/**************************************************************************
*
* Falcon MAC stats
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* [PATCH] kernel 2.6.35: ixgbe: skip non IPv4 packets in ATR filter
From: Guillaume Gaudonville @ 2010-06-21 13:05 UTC (permalink / raw)
To: netdev; +Cc: Kirsher, Jeffrey T, Waskiewicz Jr, Peter P,
Chilakala, Mallikarjuna
Hello,
In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just
add a test to check skb->protocol:
From fcb81aa89b6819f95349a4ed8c30f0629430aa1d Mon Sep 17 00:00:00 2001
From: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
Date: Thu, 17 Jun 2010 16:02:14 +0200
Subject: [PATCH] ixgbe: skip non IPv4 packets in ATR filter
It may crash on short packets due to ip_hdr() access.
Signed-off-by: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
---
drivers/net/ixgbe/ixgbe_main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index b2af2f6..3581dbe 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6019,7 +6019,6 @@ static void ixgbe_tx_queue(struct ixgbe_adapter
*adapter,
static void ixgbe_atr(struct ixgbe_adapter *adapter, struct sk_buff *skb,
int queue, u32 tx_flags)
{
- /* Right now, we support IPv4 only */
struct ixgbe_atr_input atr_input;
struct tcphdr *th;
struct iphdr *iph = ip_hdr(skb);
@@ -6028,6 +6027,10 @@ static void ixgbe_atr(struct ixgbe_adapter
*adapter, struct sk_buff *skb,
u32 src_ipv4_addr, dst_ipv4_addr;
u8 l4type = 0;
+ /* Right now, we support IPv4 only */
+ if (skb->protocol != htons(ETH_P_IP))
+ return;
+
/* check if we're UDP or TCP */
if (iph->protocol == IPPROTO_TCP) {
th = tcp_hdr(skb);
--
1.5.6.5
--
Guillaume Gaudonville
guillaume.gaudonville@6wind.com
^ permalink raw reply related
* Re: [PATCH for-2.6.35] virtio_net: fix oom handling on tx
From: Michael S. Tsirkin @ 2010-06-21 10:53 UTC (permalink / raw)
To: Rusty Russell
Cc: Stephen Hemminger, Sridhar Samudrala, virtualization, Jiri Pirko,
Shirley Ma, netdev, linux-kernel
In-Reply-To: <201006211953.44724.rusty@rustcorp.com.au>
On Mon, Jun 21, 2010 at 07:53:43PM +0930, Rusty Russell wrote:
> On Mon, 21 Jun 2010 06:03:16 pm Michael S. Tsirkin wrote:
> > On Mon, Jun 21, 2010 at 12:13:49PM +0930, Rusty Russell wrote:
> > > - return NETDEV_TX_BUSY;
> > > + kfree_skb(skb);
> > > + return NETDEV_TX_OK;
> >
> > If we do so, let's increment the dropped counter and/or error counter?
>
> Yep, here's the extra change:
Looks good to me.
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -571,14 +571,16 @@ static netdev_tx_t start_xmit(struct sk_
> /* This can happen with OOM and indirect buffers. */
> if (unlikely(capacity < 0)) {
> if (net_ratelimit()) {
> - if (likely(capacity == -ENOMEM))
> + if (likely(capacity == -ENOMEM)) {
> dev_warn(&dev->dev,
> "TX queue failure: out of memory\n");
> - else
> + } else {
> + dev->stats.tx_fifo_errors++;
> dev_warn(&dev->dev,
> "Unexpected TX queue failure: %d\n",
> capacity);
> }
> + dev->stats.tx_dropped++;
> kfree_skb(skb);
> return NETDEV_TX_OK;
> }
^ permalink raw reply
* Re: [PATCH for-2.6.35] virtio_net: fix oom handling on tx
From: Rusty Russell @ 2010-06-21 10:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, Sridhar Samudrala, virtualization, Jiri Pirko,
Shirley Ma, netdev, linux-kernel
In-Reply-To: <20100621083315.GA8665@redhat.com>
On Mon, 21 Jun 2010 06:03:16 pm Michael S. Tsirkin wrote:
> On Mon, Jun 21, 2010 at 12:13:49PM +0930, Rusty Russell wrote:
> > - return NETDEV_TX_BUSY;
> > + kfree_skb(skb);
> > + return NETDEV_TX_OK;
>
> If we do so, let's increment the dropped counter and/or error counter?
Yep, here's the extra change:
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -571,14 +571,16 @@ static netdev_tx_t start_xmit(struct sk_
/* This can happen with OOM and indirect buffers. */
if (unlikely(capacity < 0)) {
if (net_ratelimit()) {
- if (likely(capacity == -ENOMEM))
+ if (likely(capacity == -ENOMEM)) {
dev_warn(&dev->dev,
"TX queue failure: out of memory\n");
- else
+ } else {
+ dev->stats.tx_fifo_errors++;
dev_warn(&dev->dev,
"Unexpected TX queue failure: %d\n",
capacity);
}
+ dev->stats.tx_dropped++;
kfree_skb(skb);
return NETDEV_TX_OK;
}
^ 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