* Re: [PATCH 0/6] llc2: Simplify llc_station
From: David Miller @ 2012-09-17 17:12 UTC (permalink / raw)
To: ben; +Cc: acme, netdev
In-Reply-To: <20120917.131017.1646567691887140571.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 17 Sep 2012 13:10:17 -0400 (EDT)
> From: David Miller <davem@davemloft.net>
> Date: Mon, 17 Sep 2012 13:05:31 -0400 (EDT)
>
>> From: Ben Hutchings <ben@decadent.org.uk>
>> Date: Sun, 16 Sep 2012 04:09:42 +0100
>>
>>> There seem to have been some grand plans for llc_station, but as they
>>> haven't been fulfilled it's just unnecessarily complicated.
>>
>> I went over these a few times, they look correct, so I am going
>> to apply them to net-next.
>>
>> If there are any problems let's hope that exposure in the tree
>> helps shake those out.
>
> It doesn't even build properly, please fix this and resubmit:
>
> ERROR: "sysctl_llc_station_ack_timeout" [net/llc/llc2.ko] undefined!
Actually, since I trusted you when you said you build tested this,
I pushed it out to net-next pre-maturely.
I'm going to fix this meanwhile by simply removing the sysctl that
references this symbol.
But you need to check for me whether that's ok or not.
^ permalink raw reply
* Re: [PATCH 0/6] llc2: Simplify llc_station
From: David Miller @ 2012-09-17 17:10 UTC (permalink / raw)
To: ben; +Cc: acme, netdev
In-Reply-To: <20120917.130531.941621987417626917.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 17 Sep 2012 13:05:31 -0400 (EDT)
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Sun, 16 Sep 2012 04:09:42 +0100
>
>> There seem to have been some grand plans for llc_station, but as they
>> haven't been fulfilled it's just unnecessarily complicated.
>
> I went over these a few times, they look correct, so I am going
> to apply them to net-next.
>
> If there are any problems let's hope that exposure in the tree
> helps shake those out.
It doesn't even build properly, please fix this and resubmit:
ERROR: "sysctl_llc_station_ack_timeout" [net/llc/llc2.ko] undefined!
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: David Miller @ 2012-09-17 17:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1347901493.26523.151.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 17 Sep 2012 19:04:53 +0200
> On Mon, 2012-09-17 at 19:02 +0200, Eric Dumazet wrote:
>
>> A driver already exports a dev->gso_max_size, dev->gso_max_segs, I guess
>> it could export a dev->max_seg_order (default to 0)
>
> Oh well, if we use a per thread order-3 page, a driver wont define an
> order, but the max size of a segment (dev->max_seg_size).
Since you said that your audit showed that most can handle arbitrary
segment sizes, it's better to default to infinity or similar.
Otherwise we'll have to annotate almost every single driver with a
non-zero value, that's not an efficient way to handle this and
deploy the higher performance quickly.
^ permalink raw reply
* Re: [PATCH 0/6] llc2: Simplify llc_station
From: David Miller @ 2012-09-17 17:05 UTC (permalink / raw)
To: ben; +Cc: acme, netdev
In-Reply-To: <1347764982.13258.207.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 16 Sep 2012 04:09:42 +0100
> There seem to have been some grand plans for llc_station, but as they
> haven't been fulfilled it's just unnecessarily complicated.
I went over these a few times, they look correct, so I am going
to apply them to net-next.
If there are any problems let's hope that exposure in the tree
helps shake those out.
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: Eric Dumazet @ 2012-09-17 17:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1347901326.26523.149.camel@edumazet-glaptop>
On Mon, 2012-09-17 at 19:02 +0200, Eric Dumazet wrote:
> A driver already exports a dev->gso_max_size, dev->gso_max_segs, I guess
> it could export a dev->max_seg_order (default to 0)
Oh well, if we use a per thread order-3 page, a driver wont define an
order, but the max size of a segment (dev->max_seg_size).
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: Eric Dumazet @ 2012-09-17 17:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120917.121243.1665284878800146060.davem@davemloft.net>
On Mon, 2012-09-17 at 12:12 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 17 Sep 2012 09:49:04 +0200
>
> > 2) Use order-3 pages (or order-0 pages if page size is >= 32768)
>
> We could do with an audit to make sure drivers (and the stack in
> general) can handle SKB frags of length > PAGE_SIZE.
>
> I have no idea whether such problems might actually exist, but
> I can say it's a case that gets not so much testing.
I did a (quick) audit and it appears some NIC have limits like 16KB,
but they have helpers to support this, since some arches have
PAGE_SIZE=65536
ixgbe is an example, although it might need some tweaking if this code
path was not tested.
On the other hand, bnx2x has some special code to linearize too
fragmented skbs (in bnx2x_pkt_req_lin(), if skb_shinfo(skb)->nr_frags >=
10)
By the way I did more performance tests, and the speedup is more close
of 20 %
A driver already exports a dev->gso_max_size, dev->gso_max_segs, I guess
it could export a dev->max_seg_order (default to 0)
^ permalink raw reply
* Re: [PATCH] af_unux: old_cred is surplus
From: David Miller @ 2012-09-17 17:01 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20120917105234.30031.82700.stgit@localhost.localdomain>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Mon, 17 Sep 2012 11:52:41 +0100
> From: Alan Cox <alan@linux.intel.com>
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Very amusing, you found it worthwhile to remove a typo from
a comment and add one to the subject of your commit message
at the same time. It's a wash :-)
Applied to net-next with subject typo corrected.
^ permalink raw reply
* Re: [PATCH net-next 0/4] ipv6: fix the reassembly expire code in nf_conntrack
From: David Miller @ 2012-09-17 16:59 UTC (permalink / raw)
To: amwang; +Cc: netdev, netfilter-devel, herbert
In-Reply-To: <20120917.125419.1478223385564528540.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 17 Sep 2012 12:54:19 -0400 (EDT)
> From: Cong Wang <amwang@redhat.com>
> Date: Thu, 13 Sep 2012 14:25:37 +0800
>
>> ipv6: add a new namespace for nf_conntrack_reasm
>> ipv6: unify conntrack reassembly expire code with
>> ipv6: make ip6_frag_nqueues() and ip6_frag_mem() static
>> ipv6: unify fragment thresh handling code
>>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> These changes look great, all applied to net-next, thanks.
I have to ask if you actually build tested this change at all:
net/ipv6/proc.c: In function ‘sockstat6_seq_show’:
net/ipv6/proc.c:46:10: error: implicit declaration of function ‘ip6_frag_nqueues’ [-Werror=implicit-function-declaration]
net/ipv6/proc.c:46:10: error: implicit declaration of function ‘ip6_frag_mem’ [-Werror=implicit-function-declaration]
It is absolutely impossible for you to have enabled ipv6 and not gotten
that build error.
The only logical explanation is that you didn't commit the changes
to net/ipv6/proc.c in your tree when you put together these patches.
Please fix this up and resubmit the full series.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] ipv6: fix the reassembly expire code in nf_conntrack
From: David Miller @ 2012-09-17 16:54 UTC (permalink / raw)
To: amwang; +Cc: netdev, netfilter-devel, herbert
In-Reply-To: <1347517541-10653-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Thu, 13 Sep 2012 14:25:37 +0800
> ipv6: add a new namespace for nf_conntrack_reasm
> ipv6: unify conntrack reassembly expire code with
> ipv6: make ip6_frag_nqueues() and ip6_frag_mem() static
> ipv6: unify fragment thresh handling code
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
These changes look great, all applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] Take care of xfrm policy when checking dst entries
From: David Miller @ 2012-09-17 16:49 UTC (permalink / raw)
To: nicolas.dichtel
Cc: vyasevich, eric.dumazet, sds, james.l.morris, eparis, sri,
linux-sctp, netdev
In-Reply-To: <1347350987-8054-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 11 Sep 2012 10:09:43 +0200
> The goal of these patches is to fix the following problem: a session is
> established (TCP, SCTP) and after a new policy is inserted. The current
> code does not recalculate the route, thus the traffic is not encrypted.
>
> The patch propose to check flow_cache_genid value when checking a dst
> entry, which is incremented each time a policy is inserted or deleted.
>
> v2: use net->ipv4.rt_genid instead of flow_cache_genid (and thus save a test
> in fast path). Also move it to net->rt_genid, to be able to use it for IPv6
> too. Note that IPv6 will have one more test in fast path.
>
> v3: remove unrelated "#ifdef CONFIG_XFRM" in IPv6 part
> bump rt_genid in selinux code (same place than flow_cache_genid)
>
> Patches are tested with TCP and SCTP, IPv4 and IPv6.
These patches don't apply cleanly at all.
In the net/ipv4/route.c code we don't initialize the genid to zero,
we stick a random value there.
And we don't increment it by one on flushes, instead we increment
it by a random amount.
I wonder what tree these were even against, the differences were
so great.
^ permalink raw reply
* Re: [net-next 0/6][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-09-17 16:44 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: matthew.vick, netdev, gospo, sassmann
In-Reply-To: <1347873709-2190-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 17 Sep 2012 02:21:43 -0700
> The following are changes since commit ba01dfe18241bf89b058fd8a60218b218ad2bb30:
> Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>
> Matthew Vick (6):
> igb: Tidy up wrapping for CONFIG_IGB_PTP.
> igb: Update PTP function names/variables and locations.
> igb: Correct PTP support query from ethtool.
> igb: Store the MAC address in the name in the PTP struct.
> igb: Prevent dropped Tx timestamps via work items and interrupts.
> igb: Add 1588 support to I210/I211.
Pulled, thanks for fixing this up.
^ permalink raw reply
* RE: [net] e1000: Small packets may get corrupted during padding by HW
From: Dave, Tushar N @ 2012-09-17 16:39 UTC (permalink / raw)
To: David Miller
Cc: Fastabend, John R, mirqus@gmail.com, Kirsher, Jeffrey T,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20120917.123113.458101376016589070.davem@davemloft.net>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of David Miller
>Sent: Monday, September 17, 2012 9:31 AM
>To: Dave, Tushar N
>Cc: Fastabend, John R; mirqus@gmail.com; Kirsher, Jeffrey T;
>netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
>Subject: Re: [net] e1000: Small packets may get corrupted during padding
>by HW
>
>From: "Dave, Tushar N" <tushar.n.dave@intel.com>
>Date: Mon, 17 Sep 2012 07:33:12 +0000
>
>> No because it is quite normal to have packet < ETH_ZLEN. e.g. ARP
>packets.
>
>You're optimizing for ARP packets? You're kidding right?
ARP packet was just an example. I should have thought of better example.
^ permalink raw reply
* Re: [net] e1000: Small packets may get corrupted during padding by HW
From: David Miller @ 2012-09-17 16:31 UTC (permalink / raw)
To: tushar.n.dave
Cc: john.r.fastabend, mirqus, jeffrey.t.kirsher, netdev, gospo,
sassmann
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA89130DC3631@ORSMSX102.amr.corp.intel.com>
From: "Dave, Tushar N" <tushar.n.dave@intel.com>
Date: Mon, 17 Sep 2012 07:33:12 +0000
> No because it is quite normal to have packet < ETH_ZLEN. e.g. ARP packets.
You're optimizing for ARP packets? You're kidding right?
^ permalink raw reply
* Re: [PATCH] ncm: allow for NULL terminations
From: Alan Cox @ 2012-09-17 16:31 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1347896724.2685.2.camel@bwh-desktop.uk.solarflarecom.com>
On Mon, 17 Sep 2012 16:45:24 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Mon, 2012-09-17 at 11:58 +0100, Alan Cox wrote:
> > From: Alan Cox <alan@linux.intel.com>
> >
> > The strings are passed to snprintf so must be null terminated. It seems the
> > copy length is incorrectly set.
>
> Please use strlcpy() instead. (I thought someone had already gone round
> the get_drvinfo implementations and fixed them to do that, actually.)
There are still plenty of them. I'm just noting they are one out. I'm
doing a first pass over a whole pile of stuff so if you'd prefer it in a
different form treat it as a note to the maintainer than their code is
buggy as I probably won't be back round to it for a couple of months
judging by the size of the audit pile I'm working down.
Alan
^ permalink raw reply
* Re: interrupt coalescing and CSUM offload
From: Stephen Hemminger @ 2012-09-17 16:18 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OFF8862166.946F925C-ONC1257A7A.00386AD8-C1257A7A.0042C1CF@transmode.se>
On Sat, 15 Sep 2012 14:09:09 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Stephen Hemminger <shemminger@vyatta.com> wrote on 2012/09/14 18:32:52:
> >
> > On Fri, 14 Sep 2012 16:35:13 +0200
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > >
> > > I am adding interrupt coalescing to the ucc_geth driver. Unfortunately
> > > there is only support for RX interrupt coalescing.
> > > I wonder if there is any way "simulate" TX interrupt coalescing?
> > >
> > > I am also looking at adding HWCSUM support but this device can only do
> > > IP header CSUM offload. This doesn't seem to be an option in Linux?
> > > As I understand it, one must do CSUM offload for the whole frame, both
> > > IP header and TCP/UDP csums?
> > >
> > > Jocke
> >
> > There are a few drivers that turn off TX interrupt completely.
> > They cleanup TX buffers on next send and have a timer to cleanup
>
> Only on send? Currently ucc_geth does TX free in napi(where RX is processed too).
> It would be nice if one could indicate to the drivers xmit() if there
> are more frames to be sent. Then xmit() could choose not to turn on TX irq for
> preceding frames.
> > as well. This has performance benefits, but it does cause issues
> > with local flow control (the freeing of skb is used to rate
> > limit local traffic).
>
> Was my reasoning correct w.r.t CSUM?
>
I header checksum is useless to Linux. The IP header is so short that
it is already in the CPU cache and costs nothing to compute or check.
The only checksuming that matters is the data (TCP or UDP).
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: David Miller @ 2012-09-17 16:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1347868144.26523.71.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 17 Sep 2012 09:49:04 +0200
> 2) Use order-3 pages (or order-0 pages if page size is >= 32768)
We could do with an audit to make sure drivers (and the stack in
general) can handle SKB frags of length > PAGE_SIZE.
I have no idea whether such problems might actually exist, but
I can say it's a case that gets not so much testing.
^ permalink raw reply
* Re: [patch net] sky2: fix rx filter setup on link up
From: Stephen Hemminger @ 2012-09-17 16:12 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, mlindner, linux-kernel
In-Reply-To: <1347894617-13614-1-git-send-email-jiri@resnulli.us>
On Mon, 17 Sep 2012 17:10:17 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> In my case I have following problem. sky2_set_multicast() sets registers
> GM_MC_ADDR_H[1-4] correctly to:
> 0000 0800 0001 0410
> However, when adapter gets link and sky2_link_up() is called, the values
> are for some reason different:
> 0000 0800 0016 0410
Rather than papering over the problem, it would be better to
trace back what is setting those registers and fix that code.
> This in my case prevents iface to be able to receive packets with dst mac
> 01:80:C2:00:00:02 (LACPDU dst mac), which I set up previously by
> SIOCADDMULTI.
>
> So remember computed rx_filter data and write it to GM_MC_ADDR_H[1-4] on
> link_up.
>
Please do some more root cause analysis. Just save/restoring the
registers is just a temporary workaround.
^ permalink raw reply
* D-Link DGE-530T and r8169.c
From: James R. Hay @ 2012-09-17 15:51 UTC (permalink / raw)
To: romieu, nic_swsd; +Cc: netdev
Good morning,
It appears that D-Link has changed the ID of the DGE-530T NIC from
1186:4300: to 1186:4302: which means the RTL8169 driver in the linux
kernel does not recognize newer DGE-530T cards.
At link 199 of r8169.c is the following:
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
While I changed the 0x4300 to 0x4302 and recompiled the kernel to get the
driver to recognize the card I believe that the appropriate fix would be
to add the following line immediately after:
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302), 0, 0, RTL_CFG_0 },
Since I only have the one machine here on which to test this driver I am
hoping that any further testing needed can be done by someone so that this
can make its way inte the kernel source code.
Jim.
James R. Hay jrhay@HayA.QC.CA
Hay-Net Networks http://www.hay-net.net
P.O. Box 46051
Pointe Claire, QC
H9R 5R4
^ permalink raw reply
* Re: [PATCH] ncm: allow for NULL terminations
From: Ben Hutchings @ 2012-09-17 15:45 UTC (permalink / raw)
To: Alan Cox; +Cc: netdev
In-Reply-To: <20120917105853.30298.29234.stgit@localhost.localdomain>
On Mon, 2012-09-17 at 11:58 +0100, Alan Cox wrote:
> From: Alan Cox <alan@linux.intel.com>
>
> The strings are passed to snprintf so must be null terminated. It seems the
> copy length is incorrectly set.
Please use strlcpy() instead. (I thought someone had already gone round
the get_drvinfo implementations and fixed them to do that, actually.)
Ben.
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/net/usb/cdc_ncm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index 4cd582a..af8cce7 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -145,10 +145,10 @@ cdc_ncm_get_drvinfo(struct net_device *net, struct ethtool_drvinfo *info)
> {
> struct usbnet *dev = netdev_priv(net);
>
> - strncpy(info->driver, dev->driver_name, sizeof(info->driver));
> - strncpy(info->version, DRIVER_VERSION, sizeof(info->version));
> + strncpy(info->driver, dev->driver_name, sizeof(info->driver) - 1);
> + strncpy(info->version, DRIVER_VERSION, sizeof(info->version) - 1);
> strncpy(info->fw_version, dev->driver_info->description,
> - sizeof(info->fw_version));
> + sizeof(info->fw_version) - 1);
> usb_make_path(dev->udev, info->bus_info, sizeof(info->bus_info));
> }
>
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Possible networking regression in 3.6.0
From: Chris Clayton @ 2012-09-17 15:44 UTC (permalink / raw)
To: netdev
Hi,
I'm having a problem with networking. I'm running Windows XP as a KVM
guest on a laptop running kernel 3.6.0-rc6. The identical configuration
works fine with kernels 3.5.4 and 3.4.11 (and has done so, largely
unchanged, since since KVM was introduced in 2.6.<whatever>.)
The configuration is:
XP guest: 192.168.200.1 (gateway 192.168.200.254)
tap0: 192.168.200.254
host: 192.168.0.40 (gateway 192.168.0.1)
router: 192.168.0.1
The script that starts up the firewall includes the following commands:
# Load the connection-sharing for qemu/kvm guests
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
...
# allow traffic to and from the qemu/kvm virtual networks
NETS="200 201"
for net in $NETS; do
iptables -A INPUT -s 192.168.$net.0/24 -j ACCEPT
iptables -A OUTPUT -d 192.168.$net.0/24 -j ACCEPT
done
...
The network-related modules that are loaded are:
$ lsmod
Module Size Used by
tun 12412 0
xt_state 891 1
iptable_filter 852 1
ipt_MASQUERADE 1222 1
iptable_nat 3087 1
nf_nat 10901 2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4 4942 4 nf_nat,iptable_nat
nf_defrag_ipv4 815 1 nf_conntrack_ipv4
nf_conntrack 37644 5
ipt_MASQUERADE,nf_nat,xt_state,iptable_nat,nf_conntrack_ipv4
...
r8169 47159 0
From the host I can successfully ping the guest, tap0 and the router as
you would expect, but from the guest, although I can ping the host and
tap0, I cannot ping the router. In practice, this means I have no
internet access from the guest. As I say, this configuration works
perfectly under 3.5.x and 3.4.x kernels.
I'll do a coarse-grained "bisect" of Linus' 3.6 release candidates and
report back, but does anyone have any prime-suspect patches that may be
at the cause of this problem?
Let me know if there are any other diagnostics I can provide. Also, as
I'm not subscribed to netdev, please cc me to any reply.
Thanks,
Chris
^ permalink raw reply
* Re: Regarding group_forward_mask in bridge in 3.4 kernel
From: John Fastabend @ 2012-09-17 15:24 UTC (permalink / raw)
To: Ajith Adapa; +Cc: netdev, Stephen Hemminger
In-Reply-To: <CADAe=++yAm3t-ZqMKy9h-Rda5=pOYQD2-cKUd3S1VKmBZQfT9A@mail.gmail.com>
On 9/17/2012 7:43 AM, Ajith Adapa wrote:
> Hi,
>
> I am trying to enable group_fwd_mask in bridge by giving the below
> command so that it can forward provider bpdu's whose destination
> address is 01-80-C2-00-00-08.
>
> echo 8 > /sys/class/net/vpc1_br/bridge/group_fwd_mask
>
wrong value see the logic you quoted use 1 << 8
echo 256 > /sys/class/net/...
Your example fwds non-TPMR addresses 01-80-c2-00-00-03.
[...]
> Am I giving wrong value for group_fwd_mask ??
Yep wrong value.
> I tried other values but seems only 8 and 0 is accepted.
The logic makes an attempt to restrict forwarding by masking 0x4007u,
catching many known control protocols.
See commit for details,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=515853ccecc6987dfb8ed809dd8bf8900286f29e
.John
^ permalink raw reply
* Re: NULL deref in bnx2 / crashes ? ( was: netconsole leads to stalled CPU task )
From: Cong Wang @ 2012-09-17 15:17 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Eric Dumazet, netdev
In-Reply-To: <CAF6-1L4VaG4JAK0kYYizMvhBcaUM5x3uatA7JpzZqzcJ+fmGww@mail.gmail.com>
On 09/17/2012 06:57 PM, Sylvain Munaut wrote:
> Hi,
>
>>> Anyway, I think Eric is right, the bug may be in other place. I am wondering
>>> if the attached patch could help? It seems in netpoll tx path, we miss the
>>> chance of calling ->ndo_select_queue().
>>>
>>> Please give it a try.
>>
>> This fixes the NULL deref as well. I applied your patch over vanilla
>> 3.6-rc5 (so without eric's patch) and I can load netconsole without it
>> crashing directly.
>>
>> I will try to put a bit of load on the machine and see how it behaves,
>> if it solves the hung cpu tasks as well.
>
> So far so good, the machine is still alive and well after 3 days with
> netconsole enabled.
>
Great!
Thanks a lot for testing, Sylvain! I will post the patch tomorrow, as I
need some sleep now. :)
^ permalink raw reply
* [patch net] sky2: fix rx filter setup on link up
From: Jiri Pirko @ 2012-09-17 15:10 UTC (permalink / raw)
To: netdev; +Cc: davem, mlindner, shemminger, linux-kernel
In my case I have following problem. sky2_set_multicast() sets registers
GM_MC_ADDR_H[1-4] correctly to:
0000 0800 0001 0410
However, when adapter gets link and sky2_link_up() is called, the values
are for some reason different:
0000 0800 0016 0410
This in my case prevents iface to be able to receive packets with dst mac
01:80:C2:00:00:02 (LACPDU dst mac), which I set up previously by
SIOCADDMULTI.
So remember computed rx_filter data and write it to GM_MC_ADDR_H[1-4] on
link_up.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/ethernet/marvell/sky2.c | 30 ++++++++++++++++++++++--------
drivers/net/ethernet/marvell/sky2.h | 2 ++
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index 2b0748d..5293ff4 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -2186,6 +2186,8 @@ static u16 sky2_phy_speed(const struct sky2_hw *hw, u16 aux)
}
}
+static void sky2_write_rx_filter(struct sky2_port *sky2, u8 *filter);
+
static void sky2_link_up(struct sky2_port *sky2)
{
struct sky2_hw *hw = sky2->hw;
@@ -2211,6 +2213,9 @@ static void sky2_link_up(struct sky2_port *sky2)
sky2_write8(hw, SK_REG(port, LNK_LED_REG),
LINKLED_ON | LINKLED_BLINK_OFF | LINKLED_LINKSYNC_OFF);
+ /* Refresh RX filter */
+ sky2_write_rx_filter(sky2, sky2->rx_filter);
+
netif_info(sky2, link, sky2->netdev,
"Link is up at %d Mbps, %s duplex, flow control %s\n",
sky2->speed,
@@ -3849,6 +3854,21 @@ static inline void sky2_add_filter(u8 filter[8], const u8 *addr)
filter[bit >> 3] |= 1 << (bit & 7);
}
+static void sky2_write_rx_filter(struct sky2_port *sky2, u8 *filter)
+{
+ struct sky2_hw *hw = sky2->hw;
+ unsigned port = sky2->port;
+
+ gma_write16(hw, port, GM_MC_ADDR_H1,
+ (u16) filter[0] | ((u16) filter[1] << 8));
+ gma_write16(hw, port, GM_MC_ADDR_H2,
+ (u16) filter[2] | ((u16) filter[3] << 8));
+ gma_write16(hw, port, GM_MC_ADDR_H3,
+ (u16) filter[4] | ((u16) filter[5] << 8));
+ gma_write16(hw, port, GM_MC_ADDR_H4,
+ (u16) filter[6] | ((u16) filter[7] << 8));
+}
+
static void sky2_set_multicast(struct net_device *dev)
{
struct sky2_port *sky2 = netdev_priv(dev);
@@ -3882,14 +3902,8 @@ static void sky2_set_multicast(struct net_device *dev)
sky2_add_filter(filter, ha->addr);
}
- gma_write16(hw, port, GM_MC_ADDR_H1,
- (u16) filter[0] | ((u16) filter[1] << 8));
- gma_write16(hw, port, GM_MC_ADDR_H2,
- (u16) filter[2] | ((u16) filter[3] << 8));
- gma_write16(hw, port, GM_MC_ADDR_H3,
- (u16) filter[4] | ((u16) filter[5] << 8));
- gma_write16(hw, port, GM_MC_ADDR_H4,
- (u16) filter[6] | ((u16) filter[7] << 8));
+ sky2_write_rx_filter(sky2, filter);
+ memcpy(sky2->rx_filter, filter, sizeof(sky2->rx_filter));
gma_write16(hw, port, GM_RX_CTRL, reg);
}
diff --git a/drivers/net/ethernet/marvell/sky2.h b/drivers/net/ethernet/marvell/sky2.h
index 615ac63..513c266 100644
--- a/drivers/net/ethernet/marvell/sky2.h
+++ b/drivers/net/ethernet/marvell/sky2.h
@@ -2272,6 +2272,8 @@ struct sky2_port {
#ifdef CONFIG_SKY2_DEBUG
struct dentry *debugfs;
#endif
+
+ u8 rx_filter[8];
};
struct sky2_hw {
--
1.7.11.4
^ permalink raw reply related
* Re: [RFT] sky2: fix status length check on older chips
From: Ivan Minev @ 2012-09-17 14:20 UTC (permalink / raw)
To: netdev
In-Reply-To: <20120427135514.48b03ce8@nehalam.linuxnetplumber.net>
Still vlan don't work and have rx lenght errors chipset:88E8072 rev 10
^ permalink raw reply
* Regarding group_forward_mask in bridge in 3.4 kernel
From: Ajith Adapa @ 2012-09-17 14:43 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Hi,
I am trying to enable group_fwd_mask in bridge by giving the below
command so that it can forward provider bpdu's whose destination
address is 01-80-C2-00-00-08.
echo 8 > /sys/class/net/vpc1_br/bridge/group_fwd_mask
But still the provider BPDU's are dropped by the bridge. After some
debugging I have found that logic in br_input.c has some issue
switch (dest[5]) {
case 0x00: /* Bridge Group Address */
/* If STP is turned off,
then must forward to keep loop detection */
if (p->br->stp_enabled == BR_NO_STP)
goto forward;
break;
case 0x01: /* IEEE MAC (Pause) */
goto drop;
default:
/* Allow selective forwarding for most other
protocols */
if (p->br->group_fwd_mask & (1u << dest[5]))
goto forward;
}
In my case dest[5] is 8 and p->br->group_fwd_mask is 8. The default
case is triggered but the expression in if condition
is always ZERO as a result BPDU is not forwarded.
Am I giving wrong value for group_fwd_mask ?? I tried other values but
seems only 8 and 0 is accepted.
Regards,
Ajith
^ 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