* Re: [PATCH] be2net: Fix a potential crash during shutdown.
From: David Miller @ 2011-04-06 19:40 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20110406155313.GA2246@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Wed, 6 Apr 2011 10:53:13 -0500
> adapter could remain uninitialized if probe fails for some reason.
> A null pointer access could cause a crash if be_shutdown
> is called after that.
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Applied to net-2.6, thank you.
^ permalink raw reply
* Re: [PATCH 1/1] bna: Fix for handling firmware heartbeat failure
From: David Miller @ 2011-04-06 19:39 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team, ddutt
In-Reply-To: <1301941799-25324-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Mon, 4 Apr 2011 11:29:59 -0700
> This patch contains a fix for gracefully handling firmware heartbeat
> failure instead of forcing panic.
>
> Signed-off-by: Debashis Dutt <ddutt@brocade.com>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: convert protocol handling to RCU
From: David Miller @ 2011-04-06 19:36 UTC (permalink / raw)
To: kurt.van.dijck; +Cc: socketcan, netdev, eric.dumazet, urs
In-Reply-To: <20110406153440.GA2277@kurt.e-circ.dyndns.org>
From: Kurt Van Dijck <kurt.van.dijck@eia.be>
Date: Wed, 6 Apr 2011 17:34:40 +0200
> Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 0/8] netfilter: netfilter fixes for 2.6.39-rc1
From: David Miller @ 2011-04-06 19:32 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1302008659-21141-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Tue, 5 Apr 2011 15:04:11 +0200
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks a lot Patrick.
^ permalink raw reply
* Re: pull request: sfc-next-2.6 2011-04-05
From: David Miller @ 2011-04-06 19:29 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers, shemminger, mirq-linux
In-Reply-To: <1302026446.2932.56.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 05 Apr 2011 19:00:46 +0100
> The following changes since commit 9b12c75bf4d58dd85c987ee7b6a4356fdc7c1222:
>
> net: Order ports in same order as addresses in flow objects. (2011-03-31 18:03:35 -0700)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next-2.6.git for-davem
>
> 1. Implement generic features interface in sfc.
> 2. Update ethtool_ops documentation.
> 3. Reimplement ETHTOOL_PHYS_ID as dicussed, dropping the RTNL lock.
...
Pulled, thanks a lot Ben!
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Neil Horman @ 2011-04-06 19:19 UTC (permalink / raw)
To: Brian Haley
Cc: Eric Dumazet, netdev, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Tom Herbert
In-Reply-To: <4D9CB697.3050209@hp.com>
On Wed, Apr 06, 2011 at 02:53:11PM -0400, Brian Haley wrote:
> On 04/06/2011 02:39 PM, Neil Horman wrote:
> > Also, do we have a macro already to see if an ipv6 address is all zeros? I'm
> > not finding one, but I'd hate to re-invent the wheel if I'm just missing it.
>
> ipv6_addr_any() inline in ipv6.h
>
Ah thanks!
Neil
> -Brian
>
^ permalink raw reply
* Re: [PATCH/RFC] can: mcp251x: Allow pass IRQ flags through platform data.
From: David Miller @ 2011-04-06 19:24 UTC (permalink / raw)
To: eballetbo-VIneJrwqLopBDgjK7y7TUQ
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1302023321-25182-1-git-send-email-eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
From: Enric Balletbo i Serra <eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
Date: Tue, 5 Apr 2011 19:08:41 +0200
> When an interrupt occurs, the INT pin is driven low by the
> MCP251x controller (falling edge) but in some cases the INT
> pin can be connected to the MPU through a transistor or level
> translator which inverts this signal. In this case interrupt
> should be configured in rising edge.
>
> This patch adds support to pass the IRQ flags via
> mcp251x_platform_data.
>
> Signed-off-by: Enric Balletbo i Serra <eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] smsc911x: fix mac_lock acquision before calling smsc911x_mac_read
From: David Miller @ 2011-04-06 19:23 UTC (permalink / raw)
To: eballetbo; +Cc: steve.glendinning, netdev
In-Reply-To: <1302022369-24285-1-git-send-email-eballetbo@iseebcn.com>
From: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Date: Tue, 5 Apr 2011 18:52:49 +0200
> When SMSC911X_SAVE_MAC_ADDRESS flag is enabled the driver calls
> smsc911x_mac_read and smsc911x_mac_read function without acquiring mac_lock
> spinlock
>
> This patch fixes following warning
...
> Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Applied, thank you.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: David Miller @ 2011-04-06 19:12 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: fedora-kernel-list, jesse.brandeburg, netdev
In-Reply-To: <BANLkTikZfp_GLyNRufAzqv3Yeb5d12BPDA@mail.gmail.com>
From: Jesse Brandeburg <jesse.brandeburg@gmail.com>
Date: Wed, 6 Apr 2011 11:51:06 -0700
> perf showed netfilter being prominent, and removing it gives me much
> higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
> good thing to be able to disable netfilter if you want to?
CONFIG_NETFILTER=y is the only possible non-disabled setting, as it's
a boolean.
All that is enabling is the hooks, and it's not possible to provide
netfilter at all without the hooks being compiled into the kernel
image.
Fedora by default is also probably installing several defauly
netfilter rules, make sure to remove them.
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Brian Haley @ 2011-04-06 18:53 UTC (permalink / raw)
To: Neil Horman
Cc: Eric Dumazet, netdev, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Tom Herbert
In-Reply-To: <20110406183913.GB6825@hmsreliant.think-freely.org>
On 04/06/2011 02:39 PM, Neil Horman wrote:
> Also, do we have a macro already to see if an ipv6 address is all zeros? I'm
> not finding one, but I'd hate to re-invent the wheel if I'm just missing it.
ipv6_addr_any() inline in ipv6.h
-Brian
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Felipe Balbi @ 2011-04-06 18:59 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Greg KH, Grant Likely, Andres Salomon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
khali-PUYAD+kWke1g9hUCZPvPmw, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Mocean Laboratories
In-Reply-To: <20110406184733.GD2757@sortiz-mobl>
Hi,
On Wed, Apr 06, 2011 at 08:47:34PM +0200, Samuel Ortiz wrote:
> > > > What is a "MFD cell pointer" and why is it needed in struct device?
> > > An MFD cell is an MFD instantiated device.
> > > MFD (Multi Function Device) drivers instantiate platform devices. Those
> > > devices drivers sometimes need a platform data pointer, sometimes an MFD
> > > specific pointer, and sometimes both. Also, some of those drivers have been
> > > implemented as MFD sub drivers, while others know nothing about MFD and just
> > > expect a plain platform_data pointer.
> >
> > That sounds like a bug in those drivers, why not fix them to properly
> > pass in the correct pointer?
> Because they're drivers for generic IPs, not MFD ones. By forcing them to use
> MFD specific structure and APIs, we make it more difficult for platform code
> to instantiate them.
I agree. What I do on those cases is to have a simple platform_device
for the core IP driver and use platform_device_id tables to do runtime
checks of the small differences. If one platform X doesn't use a
platform_bus, it uses e.g. PCI, then you make a PCI "bridge" which
allocates a platform_device with the correct name and adds that to the
driver model.
See [1] (for the core driver) and [2] (for a PCI bridge driver) for an
example of what I'm talking about.
> The timberdale MFD for example is built with a Xilinx SPI controller, and a
> Micrel ks8842 ethernet switch IP. Forcing those devices into being MFD devices
> would mean any platform willing to instantiate them would have to use the MFD
> APIs. That sounds a bit artificial to me.
do they share any address space ? If they do, then you'd need something
to synchronize, right ? If they don't, then you just add two separate
devices, they don't have to be MFD.
> Although there is currently no drivers instantiated by both an MFD driver
> and some platform code, Grant complaint about the Xilinx SPI driver moving
> from a platform driver to an MFD one makes sense to me.
I don't think so. That's not really an MFD device is it ? It's just two
different IPs instantianted on the same ASIC/FPGA, right ? Unless they
share the register space, IMHO, there's no need to make them MFD.
[1] http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/core.c
[2] http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/dwc3-haps.c
--
balbi
^ permalink raw reply
* fedora 14 kernel performance with ip forwarding workload
From: Jesse Brandeburg @ 2011-04-06 18:51 UTC (permalink / raw)
To: fedora-kernel-list; +Cc: Jesse Brandeburg, NetDEV list
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Samuel Ortiz @ 2011-04-06 18:47 UTC (permalink / raw)
To: Greg KH
Cc: Grant Likely, Andres Salomon, linux-kernel, Mark Brown, khali,
ben-linux, Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c, linux-media, netdev, spi-devel-general,
Mocean Laboratories
In-Reply-To: <20110406175647.GA8048@suse.de>
On Wed, Apr 06, 2011 at 10:56:47AM -0700, Greg KH wrote:
> On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote:
> > Hi Greg,
> >
> > On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote:
> > > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> > > > --- a/include/linux/device.h
> > > > +++ b/include/linux/device.h
> > > > @@ -33,6 +33,7 @@ struct class;
> > > > struct subsys_private;
> > > > struct bus_type;
> > > > struct device_node;
> > > > +struct mfd_cell;
> > > >
> > > > struct bus_attribute {
> > > > struct attribute attr;
> > > > @@ -444,6 +445,8 @@ struct device {
> > > > struct device_node *of_node; /* associated device tree node */
> > > > const struct of_device_id *of_match; /* matching of_device_id from driver */
> > > >
> > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */
> > > > +
> > >
> > > What is a "MFD cell pointer" and why is it needed in struct device?
> > An MFD cell is an MFD instantiated device.
> > MFD (Multi Function Device) drivers instantiate platform devices. Those
> > devices drivers sometimes need a platform data pointer, sometimes an MFD
> > specific pointer, and sometimes both. Also, some of those drivers have been
> > implemented as MFD sub drivers, while others know nothing about MFD and just
> > expect a plain platform_data pointer.
>
> That sounds like a bug in those drivers, why not fix them to properly
> pass in the correct pointer?
Because they're drivers for generic IPs, not MFD ones. By forcing them to use
MFD specific structure and APIs, we make it more difficult for platform code
to instantiate them.
The timberdale MFD for example is built with a Xilinx SPI controller, and a
Micrel ks8842 ethernet switch IP. Forcing those devices into being MFD devices
would mean any platform willing to instantiate them would have to use the MFD
APIs. That sounds a bit artificial to me.
Although there is currently no drivers instantiated by both an MFD driver
and some platform code, Grant complaint about the Xilinx SPI driver moving
from a platform driver to an MFD one makes sense to me.
> > So, adding an MFD cell pointer to the device structure allows us to cleanly
> > pass both pieces of information, while keeping all the MFD sub drivers
> > independant from the MFD core if they want/can.
>
> They shouldn't be "independant",
Excuse my poor spelling.
> make them "dependant" and go from there.
That's what the code currently does.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: shutdown oops in xt_compat_calc_jump
From: dann frazier @ 2011-04-06 18:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Patrick McHardy, netdev, netfilter-devel@vger.kernel.org
In-Reply-To: <1302108567.3209.121.camel@edumazet-laptop>
On Wed, Apr 06, 2011 at 06:49:27PM +0200, Eric Dumazet wrote:
> Le mercredi 06 avril 2011 à 18:44 +0200, Eric Dumazet a écrit :
> > Le mercredi 06 avril 2011 à 10:25 -0600, dann frazier a écrit :
> >
> > > Thanks Eric. Unfortunately that didn't solve the problem I am seeing.
> > > I rebaselined (same kernel build as before), and found that I'm able
> > > to reproduce this 100% of the time by running only:
> > >
> > > sudo ebtables -t filter --init-table
> > >
> > > The backtrace I received was this:
> >
> >
> > Oh yeah, I forgot to remove the WARN_ON_ONCE(1) at the end of
> > xt_compat_calc_jump()
> >
> > I focused on restoring ebtables (for example ebtables -A INPUT ...)
> >
> > Just ignore the warning for the time being ;)
> >
> >
> > # ebtables -A INPUT -p arp -s 00:01:02:03:04:05 -j ACCEPT
> > # ebtables -A INPUT -p arp -s 00:01:02:03:04:06 -j ACCEPT
> > # ebtables -L
> > Bridge table: filter
> >
> > Bridge chain: INPUT, entries: 2, policy: ACCEPT
> > -p ARP -s 0:1:2:3:4:5 -j ACCEPT
> > -p ARP -s 0:1:2:3:4:6 -j ACCEPT
> >
> > Bridge chain: FORWARD, entries: 0, policy: ACCEPT
> >
> > Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
> >
Tested-by: dann frazier <dannf@dannf.org>
Thanks!
> [PATCH] netfilter: fix ebtables
>
> commit 255d0dc34068a976 (netfilter: x_table: speedup compat operations)
> made ebtables not working anymore.
>
> 1) xt_compat_calc_jump() is not an exact match lookup
> 2) compat_table_info() has a typo in xt_compat_init_offsets() call
> 3) compat_do_replace() misses a xt_compat_init_offsets() call
>
> Reported-by: dann frazier <dannf@dannf.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> V2: remove a comment from V1 (as Patrick suggested)
> remove the WARN_ON_ONCE() in xt_compat_calc_jump()
>
>
> net/bridge/netfilter/ebtables.c | 3 ++-
> net/netfilter/x_tables.c | 4 ++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
> index 893669c..c66aa80 100644
> --- a/net/bridge/netfilter/ebtables.c
> +++ b/net/bridge/netfilter/ebtables.c
> @@ -1766,7 +1766,7 @@ static int compat_table_info(const struct ebt_table_info *info,
>
> newinfo->entries_size = size;
>
> - xt_compat_init_offsets(AF_INET, info->nentries);
> + xt_compat_init_offsets(NFPROTO_BRIDGE, info->nentries);
> return EBT_ENTRY_ITERATE(entries, size, compat_calc_entry, info,
> entries, newinfo);
> }
> @@ -2240,6 +2240,7 @@ static int compat_do_replace(struct net *net, void __user *user,
>
> xt_compat_lock(NFPROTO_BRIDGE);
>
> + xt_compat_init_offsets(NFPROTO_BRIDGE, tmp.nentries);
> ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
> if (ret < 0)
> goto out_unlock;
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index a9adf4c..8a025a5 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -455,6 +455,7 @@ void xt_compat_flush_offsets(u_int8_t af)
> vfree(xt[af].compat_tab);
> xt[af].compat_tab = NULL;
> xt[af].number = 0;
> + xt[af].cur = 0;
> }
> }
> EXPORT_SYMBOL_GPL(xt_compat_flush_offsets);
> @@ -473,8 +474,7 @@ int xt_compat_calc_jump(u_int8_t af, unsigned int offset)
> else
> return mid ? tmp[mid - 1].delta : 0;
> }
> - WARN_ON_ONCE(1);
> - return 0;
> + return left ? tmp[left - 1].delta : 0;
> }
> EXPORT_SYMBOL_GPL(xt_compat_calc_jump);
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Neil Horman @ 2011-04-06 18:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, kuznet, pekkas, jmorris, yoshfuji, kaber,
therbert
In-Reply-To: <1302115064.3209.132.camel@edumazet-laptop>
On Wed, Apr 06, 2011 at 08:37:44PM +0200, Eric Dumazet wrote:
> Le mercredi 06 avril 2011 à 11:27 -0700, David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 06 Apr 2011 20:23:08 +0200
> >
> > > Le mercredi 06 avril 2011 à 11:17 -0700, David Miller a écrit :
> > >> From: Eric Dumazet <eric.dumazet@gmail.com>
> > >> Date: Wed, 06 Apr 2011 20:07:33 +0200
> > >>
> > >> > This is why we used on ipv4 :
> > >> >
> > >> > if (inet_sk(sk)->inet_daddr)
> > >> > sock_rps_save_rxhash(sk, skb->rxhash);
> > >> >
> > >> >
> > >> > Only arm RFS on UDP if socket is bound to a given remote peer.
> > >>
> > >> Agreed, Neil please make this change to your ipv6 code.
> > >
> > > BTW, do you guys know if NFS is using RFS right now (if TCP transport is
> > > used) ?
> >
> > It ought to be. Are you specifically concerned that it might be
> > missing the rxhash setting calls because of the APIs it uses to
> > do socket I/O?
> >
> > The SunRPC layer is a major user of tcp_read_sock(), for example.
> >
> > But the packet processing will be done via the normal means,
> > therefore we'll hit tcp_v4_do_rcv() and therefore save the
> > rxhash.
>
> Hmm, are multiple tcp sessions used between NFS client and server (One
> per cpu on client ?)
nope, its all nominally done per mount (i.e. all applications writing to a given
mount point will share the same socket).
Neil
>
>
>
>
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Neil Horman @ 2011-04-06 18:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Tom Herbert
In-Reply-To: <1302113253.3209.126.camel@edumazet-laptop>
On Wed, Apr 06, 2011 at 08:07:33PM +0200, Eric Dumazet wrote:
> Le mercredi 06 avril 2011 à 13:54 -0400, Neil Horman a écrit :
>
> > diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> > index d7037c0..aa3e327 100644
> > --- a/net/ipv6/udp.c
> > +++ b/net/ipv6/udp.c
> > @@ -505,6 +505,8 @@ int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff *skb)
> > int rc;
> > int is_udplite = IS_UDPLITE(sk);
> >
> > + sock_rps_save_rxhash(sk, skb->rxhash);
> > +
> > if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
> > goto drop;
> >
>
> Problem is every packet received might have a different rxhash if
> multiple senders are active.
>
> This can hurt performance (cache misses on RFS table) on a DNS server
> workload for example.
>
> This is why we used on ipv4 :
>
> if (inet_sk(sk)->inet_daddr)
> sock_rps_save_rxhash(sk, skb->rxhash);
>
Ok, I can absolutely do that, I'll respin shortly. Just to make sure I
understand how to do this, the ipv6 equivalant of inet_daddr is
inet6_sk(sk)->daddr, correct? I ask because the above v4 equivalent is stored in
the sk_common struct, and I want to make sure I'm testing the right data.
Also, do we have a macro already to see if an ipv6 address is all zeros? I'm
not finding one, but I'd hate to re-invent the wheel if I'm just missing it.
>
> Only arm RFS on UDP if socket is bound to a given remote peer.
>
> BTW you forgot Tom Herbert. (I added him in CC)
Thanks, sorry Tom, Just took the output of get_maintainers.pl without checking
all the results.
Neil
>
>
>
>
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Eric Dumazet @ 2011-04-06 18:38 UTC (permalink / raw)
To: Neil Horman
Cc: David Miller, netdev, kuznet, pekkas, jmorris, yoshfuji, kaber,
therbert
In-Reply-To: <20110406183318.GA6825@hmsreliant.think-freely.org>
Le mercredi 06 avril 2011 à 14:33 -0400, Neil Horman a écrit :
> Thats kind of a tricky question, are you referring to clients or servers? Both
> should be able to use RFS as Dave notes, but since sockets in NFS clients tend to be per
> mount, rather than per application (as RFS nominally expects when doing flow
> steering), theres likely to be some conflict in where RFS decides to steer
> packets for that NFS socket as different applications on different cpus make
> use of the same socket.
Yes, maybe there are some updates to make NFS scale better with
multiqueue NICS [ or RPS/RFS ]
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Greg KH @ 2011-04-06 18:38 UTC (permalink / raw)
To: Andres Salomon
Cc: Samuel Ortiz, Grant Likely, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mark Brown, khali-PUYAD+kWke1g9hUCZPvPmw,
ben-linux-elnMNo+KYs3YtjvyW6yDsg, Peter Korsgaard,
Mauro Carvalho Chehab, David Brownell,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Mocean Laboratories
In-Reply-To: <20110406112557.5c4c9bfe@debxo>
On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote:
> > > We've been faced with the problem of being able to pass both MFD
> > > related data and a platform_data pointer to some of those drivers.
> > > Squeezing the MFD bits in the sub driver platform_data pointer
> > > doesn't work for drivers that know nothing about MFDs. It also adds
> > > an additional dependency on the MFD API to all MFD sub drivers.
> > > That prevents any of those drivers to eventually be used as plain
> > > platform device drivers.
> >
> > Then they shouldn't be "plain" platform drivers, that should only be
> > reserved for drivers that are the "lowest" type. Just make them MFD
> > devices and go from there.
>
>
> The problem is of mixing "plain" platform devices and MFD devices.
Then don't do that.
> It's reasonable to assume that different hardware may be using
> one method or the other to create devices; in order to maintain
> compatibility with the driver, one either needs to use a plain platform
> device. Alternatively, if an MFD-specific device class is created,
> then MFD devices would start showing up in weird places.
Then fix it. Lots of other drivers handle different "bus types" just
fine (look at the EHCI USB driver for an example.) Don't polute the
driver core just because you don't want to fix up the individual driver
issues that are quite obvious.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Eric Dumazet @ 2011-04-06 18:37 UTC (permalink / raw)
To: David Miller
Cc: nhorman, netdev, kuznet, pekkas, jmorris, yoshfuji, kaber,
therbert
In-Reply-To: <20110406.112712.71110955.davem@davemloft.net>
Le mercredi 06 avril 2011 à 11:27 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Apr 2011 20:23:08 +0200
>
> > Le mercredi 06 avril 2011 à 11:17 -0700, David Miller a écrit :
> >> From: Eric Dumazet <eric.dumazet@gmail.com>
> >> Date: Wed, 06 Apr 2011 20:07:33 +0200
> >>
> >> > This is why we used on ipv4 :
> >> >
> >> > if (inet_sk(sk)->inet_daddr)
> >> > sock_rps_save_rxhash(sk, skb->rxhash);
> >> >
> >> >
> >> > Only arm RFS on UDP if socket is bound to a given remote peer.
> >>
> >> Agreed, Neil please make this change to your ipv6 code.
> >
> > BTW, do you guys know if NFS is using RFS right now (if TCP transport is
> > used) ?
>
> It ought to be. Are you specifically concerned that it might be
> missing the rxhash setting calls because of the APIs it uses to
> do socket I/O?
>
> The SunRPC layer is a major user of tcp_read_sock(), for example.
>
> But the packet processing will be done via the normal means,
> therefore we'll hit tcp_v4_do_rcv() and therefore save the
> rxhash.
Hmm, are multiple tcp sessions used between NFS client and server (One
per cpu on client ?)
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Neil Horman @ 2011-04-06 18:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, kuznet, pekkas, jmorris, yoshfuji, kaber,
therbert
In-Reply-To: <1302114188.3209.128.camel@edumazet-laptop>
On Wed, Apr 06, 2011 at 08:23:08PM +0200, Eric Dumazet wrote:
> Le mercredi 06 avril 2011 à 11:17 -0700, David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 06 Apr 2011 20:07:33 +0200
> >
> > > This is why we used on ipv4 :
> > >
> > > if (inet_sk(sk)->inet_daddr)
> > > sock_rps_save_rxhash(sk, skb->rxhash);
> > >
> > >
> > > Only arm RFS on UDP if socket is bound to a given remote peer.
> >
> > Agreed, Neil please make this change to your ipv6 code.
>
>
> BTW, do you guys know if NFS is using RFS right now (if TCP transport is
> used) ?
>
Thats kind of a tricky question, are you referring to clients or servers? Both
should be able to use RFS as Dave notes, but since sockets in NFS clients tend to be per
mount, rather than per application (as RFS nominally expects when doing flow
steering), theres likely to be some conflict in where RFS decides to steer
packets for that NFS socket as different applications on different cpus make
use of the same socket.
Neil
>
>
>
^ permalink raw reply
* mdiobus_register() issue for an SMSC8720a PHY
From: ANDY KENNEDY @ 2011-04-06 18:22 UTC (permalink / raw)
To: netdev
I'm attempting to bring up an SMSC8720a off of a *freaky* MDIO bus.
Attempting to register my bus has failed. The following is the oops I
get (with prink modifications by me) when attempting to register:
Adding MDIO bus device for eth0
Last one before. . .
###############################################################3
mdiobus_register:92
###############################################################3
mdiobus_register:98
###############################################################3
mdiobus_register:102
###############################################################3
mdiobus_register:106
###############################################################3
mdiobus_register:109
========================================================================
====== device_add:989
========================================================================
====== device_add:991
setup_parent is being called with dev = 0x8781da40, parent = 0x00000000
========================================================================
====== get_device_parent:663
========================================================================
====== get_device_parent:670
========================================================================
====== get_device_parent:683
========================================================================
====== get_device_parent:685
========================================================================
====== get_device_parent:689
dev = 0x8781da40
dev->class = 0x803c2ad4
dev->class->p = 0x00000000
dev->class->p->class_dirs = 0x00000048
CPU 0 Unable to handle kernel paging request at virtual address
00000048, epc == 8027c424, ra == 8027c41c
Oops[#1]:
Cpu 0
$ 0 : 00000000 00000000 00000000 00000002
$ 4 : 00000001 00000003 ffffffff 00000001
$ 8 : 804d9c8f 00000002 00000001 8036fde0
$12 : 3d3d3d3d 00000000 00000000 3d3d3d3d
$16 : 804e0000 8781da40 878046c0 00000000
$20 : 8781da04 8781da40 804e0000 00000000
$24 : 00000010 00000000
$28 : 87820000 87821de0 00000000 8027c41c
Hi : 00000000
Lo : 00000015
epc : 8027c424 0x8027c424
Not tainted
ra : 8027c41c 0x8027c41c
Status: 11008403 KERNEL EXL IE
Cause : 00800008
BadVA : 00000048
PrId : 0a019554 (MIPS 34Kc)
Modules linked in:
Process swapper (pid: 1, threadinfo=87820000, task=87818000,
tls=00000000)
Stack : ffffffea 00000048 ffffffff 00000001 8781da40 00000000 80390000
8027d060
80390000 8781da40 00000000 00000001 00000000 00000000 00000000
80105150
8781da40 8781da00 80370000 80390000 ffffffea 8781da04 8781da40
802a699c
00000000 80375930 0000006d 00000000 8781da00 803cbc70 00000000
00000000
00000000 00000000 00000000 00000000 00000000 803cbc58 00000000
00000000
...
Call Trace:[<8027d060>] 0x8027d060
[<80105150>] 0x80105150
[<802a699c>] 0x802a699c
[<803cbc70>] 0x803cbc70
[<803cbc58>] 0x803cbc58
[<803cbca8>] 0x803cbca8
[<80107db0>] 0x80107db0
[<801d1250>] 0x801d1250
[<8015bed0>] 0x8015bed0
[<803c89dc>] 0x803c89dc
[<80109180>] 0x80109180
[<803c8914>] 0x803c8914
[<80109170>] 0x80109170
Code: 24a50048 8e220094 8c420038 <8c440048> 24420048 0809f114
2484fffc 8c85000c 54b20005
Disabling lock debugging due to kernel taint
note: swapper[1] exited with preempt_count 1
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 5 seconds..
The three lines showing the NULL pointer dereference are made with the
following code added to get_device_parent():
printk("dev = 0x%08x\n", (uint32_t)dev);
printk("dev->class = 0x%08x\n", (uint32_t)dev->class);
printk("dev->class->p = 0x%08x\n", (uint32_t)dev->class->p);
printk("dev->class->p->class_dirs = 0x%08x\n",
(uint32_t)&dev->class->p->class_dirs); }
list_for_each_entry(k, &dev->class->p->class_dirs.list,
entry)
if (k->parent == parent_kobj) {
kobj = kobject_get(k);
break;
}
The code that attempts to register my MDIO bus is as follows:
static struct platform_device *pdev;
void __init mgt_eth_mdio_init(void)
{
struct mii_bus *mgt_mdio = mdiobus_alloc();
if (!mgt_mdio){
printk(KERN_EMERG "Cannot get memory for mgt_mdio\n");
return;
}
pdev = platform_device_register_simple("HOST ETH MDIO bus", 0,
NULL, 0);
if (IS_ERR(pdev)) {
printk(KERN_EMERG "Cannot create platform device for
MDIO Parent.\n");
return ;
}
iowrite32(0x13, MAP_ETH_MCFG);
mgt_mdio->name = "MGT_ETH_MDIO";
mgt_mdio->id[0] = '0';
mgt_mdio->read = mgt_eth_mdio_read;
mgt_mdio->write = mgt_eth_mdio_write;
mgt_mdio->irq = kzalloc(PHY_MAX_ADDR * sizeof(*mgt_mdio->irq),
GFP_KERNEL);
mgt_mdio->irq[0] = MGT_ETH_IRQ;
mgt_mdio->parent = &pdev->dev;
mgt_mdio->phy_mask = 0xfffffffe; //mask all but 0, it is the
only one.
// Last but not least, setup memory for the phy_map.
mgt_mdio->phy_map[0] = phy_device_create(mgt_mdio, 0, 0);
dev_set_drvdata(&pdev->dev, mgt_mdio);
printk("Last one before. . . \n");
// Shortly after this line, the system prints the Oops above
mdiobus_register(mgt_mdio);
printk("Probably don't see this.\n");
}
What am I doing wrong? Also, why do I get the message "Disabling lock
debugging due to kernel taint" when above it the kernel reports "Not
tainted"?
Andy Fleming suggested that I was not initializing my platform_device
correctly, so I, based upon his suggestion, added the dev_set_drvdata()
line. This made no effect.
If you see something I'm doing wrong, please advise.
Andy Kennedy
^ permalink raw reply
* Re: [PATCH v2 net-next 3/9] tg3: Reintroduce 5717_PLUS
From: David Miller @ 2011-04-06 18:28 UTC (permalink / raw)
To: mcarlson; +Cc: joe, netdev
In-Reply-To: <20110406173325.GA14870@mcarlson.broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Wed, 6 Apr 2011 10:33:26 -0700
> For the record though, I did consider using the TG3_FLG3_5717_PLUS flag.
> I'm uncomfortable with using it here because this is more of a server
> class device feature. Should another mobile or desktop device be
> created in the future, I'd have to devise this type of flag to identify
> what feature I'm really talking about. I thought it prudent to just
> take care of that now.
>
> (Not that this is a compelling argument, but it also is a handy way to
> enable and disable the feature while debugging.)
I think the current approach is fine, getting these feature tests right
is indeed non-trivial :-)
I'll apply this patch series to net-next-2.6 and if some tweaks are
still desired, please send them as follow-up patches.
Thanks!
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: David Miller @ 2011-04-06 18:27 UTC (permalink / raw)
To: eric.dumazet
Cc: nhorman, netdev, kuznet, pekkas, jmorris, yoshfuji, kaber,
therbert
In-Reply-To: <1302114188.3209.128.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Apr 2011 20:23:08 +0200
> Le mercredi 06 avril 2011 à 11:17 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Wed, 06 Apr 2011 20:07:33 +0200
>>
>> > This is why we used on ipv4 :
>> >
>> > if (inet_sk(sk)->inet_daddr)
>> > sock_rps_save_rxhash(sk, skb->rxhash);
>> >
>> >
>> > Only arm RFS on UDP if socket is bound to a given remote peer.
>>
>> Agreed, Neil please make this change to your ipv6 code.
>
> BTW, do you guys know if NFS is using RFS right now (if TCP transport is
> used) ?
It ought to be. Are you specifically concerned that it might be
missing the rxhash setting calls because of the APIs it uses to
do socket I/O?
The SunRPC layer is a major user of tcp_read_sock(), for example.
But the packet processing will be done via the normal means,
therefore we'll hit tcp_v4_do_rcv() and therefore save the
rxhash.
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Andres Salomon @ 2011-04-06 18:25 UTC (permalink / raw)
To: Greg KH
Cc: Samuel Ortiz, Grant Likely, linux-kernel, Mark Brown, khali,
ben-linux, Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c, linux-media, netdev, spi-devel-general,
Mocean Laboratories
In-Reply-To: <20110406175647.GA8048@suse.de>
On Wed, 6 Apr 2011 10:56:47 -0700
Greg KH <gregkh@suse.de> wrote:
> On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote:
> > Hi Greg,
> >
> > On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote:
> > > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> > > > --- a/include/linux/device.h
> > > > +++ b/include/linux/device.h
> > > > @@ -33,6 +33,7 @@ struct class;
> > > > struct subsys_private;
> > > > struct bus_type;
> > > > struct device_node;
> > > > +struct mfd_cell;
> > > >
> > > > struct bus_attribute {
> > > > struct attribute attr;
> > > > @@ -444,6 +445,8 @@ struct device {
> > > > struct device_node *of_node; /* associated
> > > > device tree node */ const struct of_device_id *of_match; /*
> > > > matching of_device_id from driver */
> > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer
> > > > */ +
> > >
> > > What is a "MFD cell pointer" and why is it needed in struct
> > > device?
> > An MFD cell is an MFD instantiated device.
> > MFD (Multi Function Device) drivers instantiate platform devices.
> > Those devices drivers sometimes need a platform data pointer,
> > sometimes an MFD specific pointer, and sometimes both. Also, some
> > of those drivers have been implemented as MFD sub drivers, while
> > others know nothing about MFD and just expect a plain platform_data
> > pointer.
>
> That sounds like a bug in those drivers, why not fix them to properly
> pass in the correct pointer?
I'm still trying to understand if this is a theoretical problem, or if
Grant has actually experienced a regression. His mention of bisecting
made it sound like the latter was the case, but I've yet to hear of
specifically what drivers this was breaking. Samuel described some
potential driver breakage, but nothing concrete.
I do agree that this needs a better solution, given the theoretical
breakage.
>
> > We've been faced with the problem of being able to pass both MFD
> > related data and a platform_data pointer to some of those drivers.
> > Squeezing the MFD bits in the sub driver platform_data pointer
> > doesn't work for drivers that know nothing about MFDs. It also adds
> > an additional dependency on the MFD API to all MFD sub drivers.
> > That prevents any of those drivers to eventually be used as plain
> > platform device drivers.
>
> Then they shouldn't be "plain" platform drivers, that should only be
> reserved for drivers that are the "lowest" type. Just make them MFD
> devices and go from there.
The problem is of mixing "plain" platform devices and MFD devices.
It's reasonable to assume that different hardware may be using
one method or the other to create devices; in order to maintain
compatibility with the driver, one either needs to use a plain platform
device. Alternatively, if an MFD-specific device class is created,
then MFD devices would start showing up in weird places.
>
> > So, adding an MFD cell pointer to the device structure allows us to
> > cleanly pass both pieces of information, while keeping all the MFD
> > sub drivers independant from the MFD core if they want/can.
>
> They shouldn't be "independant", make them "dependant" and go from
> there.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Eric Dumazet @ 2011-04-06 18:23 UTC (permalink / raw)
To: David Miller
Cc: nhorman, netdev, kuznet, pekkas, jmorris, yoshfuji, kaber,
therbert
In-Reply-To: <20110406.111712.226782643.davem@davemloft.net>
Le mercredi 06 avril 2011 à 11:17 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Apr 2011 20:07:33 +0200
>
> > This is why we used on ipv4 :
> >
> > if (inet_sk(sk)->inet_daddr)
> > sock_rps_save_rxhash(sk, skb->rxhash);
> >
> >
> > Only arm RFS on UDP if socket is bound to a given remote peer.
>
> Agreed, Neil please make this change to your ipv6 code.
BTW, do you guys know if NFS is using RFS right now (if TCP transport is
used) ?
^ 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