* [PATCH] netfilter: Add missing CONFIG_SYSCTL checks in ipv6's nf_conntrack_reasm.c
From: David Miller @ 2010-10-26 16:10 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, kaber
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
I just committed this to net-2.6, just FYI.
net/ipv6/netfilter/nf_conntrack_reasm.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 489d71b..3a3f129 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -625,21 +625,24 @@ int nf_ct_frag6_init(void)
inet_frags_init_net(&nf_init_frags);
inet_frags_init(&nf_frags);
+#ifdef CONFIG_SYSCTL
nf_ct_frag6_sysctl_header = register_sysctl_paths(nf_net_netfilter_sysctl_path,
nf_ct_frag6_sysctl_table);
if (!nf_ct_frag6_sysctl_header) {
inet_frags_fini(&nf_frags);
return -ENOMEM;
}
+#endif
return 0;
}
void nf_ct_frag6_cleanup(void)
{
+#ifdef CONFIG_SYSCTL
unregister_sysctl_table(nf_ct_frag6_sysctl_header);
nf_ct_frag6_sysctl_header = NULL;
-
+#endif
inet_frags_fini(&nf_frags);
nf_init_frags.low_thresh = 0;
--
1.7.3.2
^ permalink raw reply related
* [PATCH] drivers/net: sgiseeq: fix return on error
From: Nicolas Kaiser @ 2010-10-26 16:45 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
If we continue on error, we'd likely free the IRQ that we
didn't get, right?
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
---
drivers/net/sgiseeq.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c
index 9265315..3a0cc63 100644
--- a/drivers/net/sgiseeq.c
+++ b/drivers/net/sgiseeq.c
@@ -531,7 +531,7 @@ static int sgiseeq_open(struct net_device *dev)
if (request_irq(irq, sgiseeq_interrupt, 0, sgiseeqstr, dev)) {
printk(KERN_ERR "Seeq8003: Can't get irq %d\n", dev->irq);
- err = -EAGAIN;
+ return -EAGAIN;
}
err = init_seeq(dev, sp, sregs);
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Brian Haley @ 2010-10-26 16:58 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: Stephen Hemminger, netdev
In-Reply-To: <AANLkTinGpt=EQX3aXRaj5mEUMDNpyEapbs4VyOwgtN55@mail.gmail.com>
On 10/26/2010 01:44 AM, Lorenzo Colitti wrote:
> On Mon, Oct 25, 2010 at 9:38 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
>> This is incorrect. When link is lost, routes and address should not be
>> flushed. They should be marked as tentative and then go through DAD again
>> on the new network.
>
> That won't help the case I am trying to fix, which is the case where
> the new link has a global prefix different than the old link. Marking
> the addresses as tentative will simply make them pass DAD and come
> back as soon as link comes back. But since they don't match the prefix
> that is assigned to the new link, they are unusable, because packets
> can't be routed back to them.
The old addresses will become deprecated, and eventually get removed, but
it will take 2 hours.
>> If you do it this way, you break routing protocols when link is brought
>> down and back up.
>
> The only addresses and routes flushed in this way should be ones that
> aren't manually configured, i.e., the ones created by autoconf
> (addrconf.c:2720 onwards). These won't be used by routing protocols,
> except for link-local addresses. So I assume you're talking about
> link-local here.
I posted a very similar patch recently:
http://marc.info/?l=linux-netdev&m=128415231909522&w=2
But the first response pointed out that I didn't test this with just a
simple link flap, in which case all the IPv6 addresses are deleted,
and all sessions using them die. Not good. This changes the current
behavior, and isn't what happens with IPv4 either.
Having these addresses restart DAD is probably about as much as we
can do I think, unless we add a per-device sysctl to remove the addresses
(which I think has been shot-down before). Is this a mobile device that
is actually changing it's point of attachment?
-Brian
^ permalink raw reply
* Re: [PATCH] drivers/net: sgiseeq: fix return on error
From: David Miller @ 2010-10-26 17:02 UTC (permalink / raw)
To: nikai; +Cc: netdev, linux-kernel
In-Reply-To: <20101026184505.077246a2@absol.kitzblitz>
From: Nicolas Kaiser <nikai@nikai.net>
Date: Tue, 26 Oct 2010 18:45:05 +0200
> If we continue on error, we'd likely free the IRQ that we
> didn't get, right?
>
> Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Yep, applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next-2.6] tg3: use dma_alloc_coherent() instead of pci_alloc_consistent()
From: Matt Carlson @ 2010-10-26 17:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: Amit Salecha, Matthew Carlson, davem@davemloft.net,
netdev@vger.kernel.org, Ameen Rahman, Anirban Chakraborty,
Michael Chan
In-Reply-To: <1288094593.3169.95.camel@edumazet-laptop>
On Tue, Oct 26, 2010 at 05:03:13AM -0700, Eric Dumazet wrote:
> Le mardi 26 octobre 2010 ?? 12:30 +0200, Eric Dumazet a ??crit :
>
> > By the way, you should use dma_alloc_coherent() instead of
> > pci_alloc_consistent() so that you can use GFP_KERNEL allocations
> > instead of GFP_ATOMIC, it might help in low memory conditions (if you
> > dont hold a spinlock at this point)
> >
>
> tg3 being often used as a reference network driver, I believe we should
> change its allocations before too many people copy paste suboptimal
> pci_alloc_consistent() stuff...
>
> Matt, could you please queue this patch and submit it to David when
> net-next-2.6 reopens ?
Sure. Thanks for the patch.
> Thanks
>
> [PATCH] tg3: use dma_alloc_coherent() instead of pci_alloc_consistent()
>
> Using dma_alloc_coherent() permits to use GFP_KERNEL allocations instead
> of GFP_ATOMIC ones. Its better when a machine is out of memory, because
> this allows driver to sleep to get its memory and succeed its init,
> especially when allocating high order pages.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Matt Carlson <mcarlson@broadcom.com>
> CC: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/tg3.c | 73 ++++++++++++++++++++++++--------------------
> 1 file changed, 41 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 852e917..7dfa579 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -6339,13 +6339,13 @@ static void tg3_rx_prodring_fini(struct tg3 *tp,
> kfree(tpr->rx_jmb_buffers);
> tpr->rx_jmb_buffers = NULL;
> if (tpr->rx_std) {
> - pci_free_consistent(tp->pdev, TG3_RX_STD_RING_BYTES(tp),
> - tpr->rx_std, tpr->rx_std_mapping);
> + dma_free_coherent(&tp->pdev->dev, TG3_RX_STD_RING_BYTES(tp),
> + tpr->rx_std, tpr->rx_std_mapping);
> tpr->rx_std = NULL;
> }
> if (tpr->rx_jmb) {
> - pci_free_consistent(tp->pdev, TG3_RX_JMB_RING_BYTES(tp),
> - tpr->rx_jmb, tpr->rx_jmb_mapping);
> + dma_free_coherent(&tp->pdev->dev, TG3_RX_JMB_RING_BYTES(tp),
> + tpr->rx_jmb, tpr->rx_jmb_mapping);
> tpr->rx_jmb = NULL;
> }
> }
> @@ -6358,8 +6358,10 @@ static int tg3_rx_prodring_init(struct tg3 *tp,
> if (!tpr->rx_std_buffers)
> return -ENOMEM;
>
> - tpr->rx_std = pci_alloc_consistent(tp->pdev, TG3_RX_STD_RING_BYTES(tp),
> - &tpr->rx_std_mapping);
> + tpr->rx_std = dma_alloc_coherent(&tp->pdev->dev,
> + TG3_RX_STD_RING_BYTES(tp),
> + &tpr->rx_std_mapping,
> + GFP_KERNEL);
> if (!tpr->rx_std)
> goto err_out;
>
> @@ -6370,9 +6372,10 @@ static int tg3_rx_prodring_init(struct tg3 *tp,
> if (!tpr->rx_jmb_buffers)
> goto err_out;
>
> - tpr->rx_jmb = pci_alloc_consistent(tp->pdev,
> - TG3_RX_JMB_RING_BYTES(tp),
> - &tpr->rx_jmb_mapping);
> + tpr->rx_jmb = dma_alloc_coherent(&tp->pdev->dev,
> + TG3_RX_JMB_RING_BYTES(tp),
> + &tpr->rx_jmb_mapping,
> + GFP_KERNEL);
> if (!tpr->rx_jmb)
> goto err_out;
> }
> @@ -6491,7 +6494,7 @@ static void tg3_free_consistent(struct tg3 *tp)
> struct tg3_napi *tnapi = &tp->napi[i];
>
> if (tnapi->tx_ring) {
> - pci_free_consistent(tp->pdev, TG3_TX_RING_BYTES,
> + dma_free_coherent(&tp->pdev->dev, TG3_TX_RING_BYTES,
> tnapi->tx_ring, tnapi->tx_desc_mapping);
> tnapi->tx_ring = NULL;
> }
> @@ -6500,25 +6503,26 @@ static void tg3_free_consistent(struct tg3 *tp)
> tnapi->tx_buffers = NULL;
>
> if (tnapi->rx_rcb) {
> - pci_free_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES(tp),
> - tnapi->rx_rcb,
> - tnapi->rx_rcb_mapping);
> + dma_free_coherent(&tp->pdev->dev,
> + TG3_RX_RCB_RING_BYTES(tp),
> + tnapi->rx_rcb,
> + tnapi->rx_rcb_mapping);
> tnapi->rx_rcb = NULL;
> }
>
> tg3_rx_prodring_fini(tp, &tnapi->prodring);
>
> if (tnapi->hw_status) {
> - pci_free_consistent(tp->pdev, TG3_HW_STATUS_SIZE,
> - tnapi->hw_status,
> - tnapi->status_mapping);
> + dma_free_coherent(&tp->pdev->dev, TG3_HW_STATUS_SIZE,
> + tnapi->hw_status,
> + tnapi->status_mapping);
> tnapi->hw_status = NULL;
> }
> }
>
> if (tp->hw_stats) {
> - pci_free_consistent(tp->pdev, sizeof(struct tg3_hw_stats),
> - tp->hw_stats, tp->stats_mapping);
> + dma_free_coherent(&tp->pdev->dev, sizeof(struct tg3_hw_stats),
> + tp->hw_stats, tp->stats_mapping);
> tp->hw_stats = NULL;
> }
> }
> @@ -6531,9 +6535,10 @@ static int tg3_alloc_consistent(struct tg3 *tp)
> {
> int i;
>
> - tp->hw_stats = pci_alloc_consistent(tp->pdev,
> - sizeof(struct tg3_hw_stats),
> - &tp->stats_mapping);
> + tp->hw_stats = dma_alloc_coherent(&tp->pdev->dev,
> + sizeof(struct tg3_hw_stats),
> + &tp->stats_mapping,
> + GFP_KERNEL);
> if (!tp->hw_stats)
> goto err_out;
>
> @@ -6543,9 +6548,10 @@ static int tg3_alloc_consistent(struct tg3 *tp)
> struct tg3_napi *tnapi = &tp->napi[i];
> struct tg3_hw_status *sblk;
>
> - tnapi->hw_status = pci_alloc_consistent(tp->pdev,
> - TG3_HW_STATUS_SIZE,
> - &tnapi->status_mapping);
> + tnapi->hw_status = dma_alloc_coherent(&tp->pdev->dev,
> + TG3_HW_STATUS_SIZE,
> + &tnapi->status_mapping,
> + GFP_KERNEL);
> if (!tnapi->hw_status)
> goto err_out;
>
> @@ -6566,9 +6572,10 @@ static int tg3_alloc_consistent(struct tg3 *tp)
> if (!tnapi->tx_buffers)
> goto err_out;
>
> - tnapi->tx_ring = pci_alloc_consistent(tp->pdev,
> - TG3_TX_RING_BYTES,
> - &tnapi->tx_desc_mapping);
> + tnapi->tx_ring = dma_alloc_coherent(&tp->pdev->dev,
> + TG3_TX_RING_BYTES,
> + &tnapi->tx_desc_mapping,
> + GFP_KERNEL);
> if (!tnapi->tx_ring)
> goto err_out;
> }
> @@ -6601,9 +6608,10 @@ static int tg3_alloc_consistent(struct tg3 *tp)
> if (!i && (tp->tg3_flags3 & TG3_FLG3_ENABLE_RSS))
> continue;
>
> - tnapi->rx_rcb = pci_alloc_consistent(tp->pdev,
> - TG3_RX_RCB_RING_BYTES(tp),
> - &tnapi->rx_rcb_mapping);
> + tnapi->rx_rcb = dma_alloc_coherent(&tp->pdev->dev,
> + TG3_RX_RCB_RING_BYTES(tp),
> + &tnapi->rx_rcb_mapping,
> + GFP_KERNEL);
> if (!tnapi->rx_rcb)
> goto err_out;
>
> @@ -14159,7 +14167,8 @@ static int __devinit tg3_test_dma(struct tg3 *tp)
> u32 *buf, saved_dma_rwctrl;
> int ret = 0;
>
> - buf = pci_alloc_consistent(tp->pdev, TEST_BUFFER_SIZE, &buf_dma);
> + buf = dma_alloc_coherent(&tp->pdev->dev, TEST_BUFFER_SIZE,
> + &buf_dma, GFP_KERNEL);
> if (!buf) {
> ret = -ENOMEM;
> goto out_nofree;
> @@ -14343,7 +14352,7 @@ static int __devinit tg3_test_dma(struct tg3 *tp)
> }
>
> out:
> - pci_free_consistent(tp->pdev, TEST_BUFFER_SIZE, buf, buf_dma);
> + dma_free_coherent(&tp->pdev->dev, TEST_BUFFER_SIZE, buf, buf_dma);
> out_nofree:
> return ret;
> }
>
>
>
^ permalink raw reply
* [PATCH 2.6.36/stable v2] vlan: Fix crash when hwaccel rx pkt for non-existant vlan.
From: Ben Greear @ 2010-10-26 17:06 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
The vlan_hwaccel_do_receive code expected skb->dev to always
be a vlan device, but if the NIC was promisc, and the VLAN
for a particular VID was not configured, then this method
could receive a packet where skb->dev was NOT a vlan
device. This caused access of bad memory and a crash.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v1 -> v2: Simplify patch..no need for setting pkt-type, etc.
:100644 100644 0eb96f7... 0687b6c... M net/8021q/vlan_core.c
:100644 100644 660dd41... 5dc45b9... M net/core/dev.c
net/8021q/vlan_core.c | 3 +++
net/core/dev.c | 5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 0eb96f7..0687b6c 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -43,6 +43,9 @@ int vlan_hwaccel_do_receive(struct sk_buff *skb)
struct net_device *dev = skb->dev;
struct vlan_rx_stats *rx_stats;
+ if (!is_vlan_dev(dev))
+ return 0;
+
skb->dev = vlan_dev_info(dev)->real_dev;
netif_nit_deliver(skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 660dd41..5dc45b9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2828,8 +2828,9 @@ static int __netif_receive_skb(struct sk_buff *skb)
if (!netdev_tstamp_prequeue)
net_timestamp_check(skb);
- if (vlan_tx_tag_present(skb) && vlan_hwaccel_do_receive(skb))
- return NET_RX_SUCCESS;
+ if (vlan_tx_tag_present(skb))
+ /* This method cannot fail at this time. */
+ vlan_hwaccel_do_receive(skb);
/* if we've gotten here through NAPI, check netpoll */
if (netpoll_receive_skb(skb))
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-26 17:09 UTC (permalink / raw)
To: Brian Haley; +Cc: Stephen Hemminger, netdev
In-Reply-To: <4CC708CE.4040404@hp.com>
On Tue, Oct 26, 2010 at 9:58 AM, Brian Haley <brian.haley@hp.com> wrote:
> > That won't help the case I am trying to fix, which is the case where
> > the new link has a global prefix different than the old link. Marking
> > the addresses as tentative will simply make them pass DAD and come
> > back as soon as link comes back. But since they don't match the prefix
> > that is assigned to the new link, they are unusable, because packets
> > can't be routed back to them.
>
> The old addresses will become deprecated, and eventually get removed, but
> it will take 2 hours.
Yes, but they become deprecated only after the preferred lifetime is
expires. Until that happens, the kernel considers them fair game and
will use them for outgoing connections, without knowing that they
won't work. So the user just sees connection timeouts and thinks that
IPv6 is slow.
> http://marc.info/?l=linux-netdev&m=128415231909522&w=2
>
> But the first response pointed out that I didn't test this with just a
> simple link flap, in which case all the IPv6 addresses are deleted,
> and all sessions using them die. Not good. This changes the current
> behavior, and isn't what happens with IPv4 either.
Actually, I just tested this and it works fine. I opened a telnet
session to ipv6.google.com port 80, and while the TCP connection was
open I reassociated with the same wifi link. During the flap, the
patch removed and then readded the same global IPv6 address. While it
was doing it, I typed GET / HTTP/1.0\n\n in the telnet window. When
the address came back, the response came back fine. The connection was
not reset.
> Having these addresses restart DAD is probably about as much as we
> can do I think, unless we add a per-device sysctl to remove the addresses
> (which I think has been shot-down before).
As before, just setting them tentative won't help that case I am
trying to fix. They have to be removed.
> Is this a mobile device that is actually changing it's point of attachment?
This is a laptop that is changing SSIDs, plugging into wired/wireless,
etc. At work we have multiple wireless networks with their own IPv6
ranges. The typical case is that I am connected to the corp network,
then I associate with the guest network... and IPv6 is broken, because
the kernel wants to use my old address and gateway, which don't work.
I'm also doing lab testing of IPv6-capable home routers, each of which
has its own wireless network. As you can imagine, after a couple of
switches, I end up with three IPv6 addresses and between three sets of
default gateways, only one of which works.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: David Miller @ 2010-10-26 17:10 UTC (permalink / raw)
To: brian.haley; +Cc: lorenzo, shemminger, netdev
In-Reply-To: <4CC708CE.4040404@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Tue, 26 Oct 2010 12:58:54 -0400
> Having these addresses restart DAD is probably about as much as we
> can do I think, unless we add a per-device sysctl to remove the addresses
> (which I think has been shot-down before).
It would be fundamentally flawed, in my opinion, if the normal
mechanisms of ipv6 cannot handle this situation adequately.
That's really why I don't even want to consider the "blow away
the addresses" sysctl option.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-26 17:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20101026082832.4c5af2ef@nehalam>
On Tue, Oct 26, 2010 at 8:28 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
>> That won't help the case I am trying to fix, which is the case where
>> the new link has a global prefix different than the old link. Marking
>> the addresses as tentative will simply make them pass DAD and come
>> back as soon as link comes back. But since they don't match the prefix
>> that is assigned to the new link, they are unusable, because packets
>> can't be routed back to them.
>
> For IPv4 this is already handled by network manager.
> Why couldn't the same apply to IPv6?
I think addresses should be deleted by the entity that configured
them. In IPv4, the addresses are created by userspace daemons like
networkmanager or DHCP, and so they should be deleted by
networkmanager as well. In IPv6, autoconf addresses are created by the
kernel, and so should be deleted by the kernel.
Otherwise, userspace daemons that are not IPv6 aware must listen to
see what addresses are created, deleting them if they think they need
to go away, and possibly even racing with the kernel (e.g., imagine
networkmanager purging IPv6 addresses just before the kernel processes
an RA that adds new IPv6 addresses).
>> What's the additional failure scenario? Will it help if I make it so
>> that link-local addresses aren't touched at all?
>
> Link-local works fine.
Ok, so if global addresses work, then the patch doesn't need to do
anything special with link-local?
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-26 17:13 UTC (permalink / raw)
To: David Miller; +Cc: brian.haley, shemminger, netdev
In-Reply-To: <20101026.101038.260090183.davem@davemloft.net>
On Tue, Oct 26, 2010 at 10:10 AM, David Miller <davem@davemloft.net> wrote:
> It would be fundamentally flawed, in my opinion, if the normal
> mechanisms of ipv6 cannot handle this situation adequately.
I think they can. When you associate with a new link, you naturally
set up link-local addresses, perform DAD for them, and send router
solicitations. You just need to make sure you don't have old addresses
from a previous link you were on before.
Removing autoconfigured addresses is what the kernel currently does
when the link goes down. The patch just makes sure it happens when
carrier is lost as well, since losing link might mean that when
carrier comes back, the host might be on a different link than it was
before.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: David Miller @ 2010-10-26 17:21 UTC (permalink / raw)
To: lorenzo; +Cc: brian.haley, shemminger, netdev
In-Reply-To: <AANLkTin-u_bZj6_wpoV6fNaLg81JbFN0EvhNrA6wX6SG@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 26 Oct 2010 10:13:45 -0700
> Removing autoconfigured addresses is what the kernel currently does
> when the link goes down. The patch just makes sure it happens when
> carrier is lost as well, since losing link might mean that when
> carrier comes back, the host might be on a different link than it was
> before.
I just think validating that fact would be a better approach than
simply assuming link down/up means link change.
^ permalink raw reply
* [PATCH] ipv4: Flush per-ns routing cache more sanely.
From: David Miller @ 2010-10-26 17:34 UTC (permalink / raw)
To: netdev; +Cc: daniel.lezcano, ebiederm
Flush the routing cache only of entries that match the
network namespace in which the purge event occurred.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Could I get some testing and performance analysis feedback
on this change? I don't want it to just die :-)
THanks!
diff --git a/include/net/route.h b/include/net/route.h
index 7e5e73b..8d24761 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -106,7 +106,7 @@ extern int ip_rt_init(void);
extern void ip_rt_redirect(__be32 old_gw, __be32 dst, __be32 new_gw,
__be32 src, struct net_device *dev);
extern void rt_cache_flush(struct net *net, int how);
-extern void rt_cache_flush_batch(void);
+extern void rt_cache_flush_batch(struct net *net);
extern int __ip_route_output_key(struct net *, struct rtable **, const struct flowi *flp);
extern int ip_route_output_key(struct net *, struct rtable **, struct flowi *flp);
extern int ip_route_output_flow(struct net *, struct rtable **rp, struct flowi *flp, struct sock *sk, int flags);
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 36e27c2..828d471 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -999,7 +999,7 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
rt_cache_flush(dev_net(dev), 0);
break;
case NETDEV_UNREGISTER_BATCH:
- rt_cache_flush_batch();
+ rt_cache_flush_batch(dev_net(dev));
break;
}
return NOTIFY_DONE;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d6cb2bf..f6860eb 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -712,13 +712,14 @@ static inline int rt_is_expired(struct rtable *rth)
* Can be called by a softirq or a process.
* In the later case, we want to be reschedule if necessary
*/
-static void rt_do_flush(int process_context)
+static void rt_do_flush(struct net *net, int process_context)
{
unsigned int i;
struct rtable *rth, *next;
- struct rtable * tail;
for (i = 0; i <= rt_hash_mask; i++) {
+ struct rtable *list, **pprev;
+
if (process_context && need_resched())
cond_resched();
rth = rt_hash_table[i].chain;
@@ -726,41 +727,28 @@ static void rt_do_flush(int process_context)
continue;
spin_lock_bh(rt_hash_lock_addr(i));
-#ifdef CONFIG_NET_NS
- {
- struct rtable ** prev, * p;
- rth = rt_hash_table[i].chain;
+ list = NULL;
+ pprev = &rt_hash_table[i].chain;
+ rth = *pprev;
+ while (rth) {
+ next = rth->dst.rt_next;
+ if (net_eq(dev_net(rth->dst.dev), net)) {
+ *pprev = next;
- /* defer releasing the head of the list after spin_unlock */
- for (tail = rth; tail; tail = tail->dst.rt_next)
- if (!rt_is_expired(tail))
- break;
- if (rth != tail)
- rt_hash_table[i].chain = tail;
-
- /* call rt_free on entries after the tail requiring flush */
- prev = &rt_hash_table[i].chain;
- for (p = *prev; p; p = next) {
- next = p->dst.rt_next;
- if (!rt_is_expired(p)) {
- prev = &p->dst.rt_next;
+ rth->dst.rt_next = list;
+ list = rth;
} else {
- *prev = next;
- rt_free(p);
+ pprev = &rth->dst.rt_next;
}
+ rth = next;
}
- }
-#else
- rth = rt_hash_table[i].chain;
- rt_hash_table[i].chain = NULL;
- tail = NULL;
-#endif
+
spin_unlock_bh(rt_hash_lock_addr(i));
- for (; rth != tail; rth = next) {
- next = rth->dst.rt_next;
- rt_free(rth);
+ for (; list; list = next) {
+ next = list->dst.rt_next;
+ rt_free(list);
}
}
}
@@ -906,13 +894,13 @@ void rt_cache_flush(struct net *net, int delay)
{
rt_cache_invalidate(net);
if (delay >= 0)
- rt_do_flush(!in_softirq());
+ rt_do_flush(net, !in_softirq());
}
/* Flush previous cache invalidated entries from the cache */
-void rt_cache_flush_batch(void)
+void rt_cache_flush_batch(struct net *net)
{
- rt_do_flush(!in_softirq());
+ rt_do_flush(net, !in_softirq());
}
static void rt_emergency_hash_rebuild(struct net *net)
^ permalink raw reply related
* RE: __bad_udelay in network driver breaks build
From: Duyck, Alexander H @ 2010-10-26 17:34 UTC (permalink / raw)
To: Andi Kleen, David Miller
Cc: netdev@vger.kernel.org, Kirsher, Jeffrey T, Rose, Gregory V
In-Reply-To: <20101025221042.GE17622@basil.fritz.box>
>-----Original Message-----
>From: Andi Kleen [mailto:andi@firstfloor.org]
>Sent: Monday, October 25, 2010 3:11 PM
>To: David Miller
>Cc: andi@firstfloor.org; netdev@vger.kernel.org; Kirsher, Jeffrey T;
>Duyck, Alexander H
>Subject: Re: __bad_udelay in network driver breaks build
>
>On Mon, Oct 25, 2010 at 01:05:13PM -0700, David Miller wrote:
>> From: Andi Kleen <andi@firstfloor.org>
>> Date: Mon, 18 Oct 2010 13:52:30 +0200
>>
>> >
>> > Current Linus master x86-64 allyesconfig fails with
>> >
>> > drivers/built-in.o: In function `tms380tr_chipset_init':
>> > tms380tr.c:(.text+0x10f02de): undefined reference to
>`__bad_udelay'
>> > tms380tr.c:(.text+0x10f03ab): undefined reference to
>`__bad_udelay'
>> > tms380tr.c:(.text+0x10f0400): undefined reference to
>`__bad_udelay'
>> > tms380tr.c:(.text+0x10f07b2): undefined reference to
>`__bad_udelay'
>> > tms380tr.c:(.text+0x10f08ed): undefined reference to
>`__bad_udelay'
>> > make[2]: *** [.tmp_vmlinux1] Error 1
>>
>> Let me know if this fixes things:
>
>Fixes that problem, but now I get (with Linus' latest again and a gcc
>4.6
>snapshot)
>
>In file included from /home/lsrc/git/linux-
>2.6/drivers/net/igbvf/ethtool.c:36:0:
>/home/lsrc/git/linux-2.6/drivers/net/igbvf/igbvf.h:129:15: error:
>duplicate member 'page'
>make[5]: *** [drivers/net/igbvf/ethtool.o] Error 1
>make[4]: *** [drivers/net/igbvf] Error 2
>
>struct igbvf_buffer {
> dma_addr_t dma;
> struct sk_buff *skb;
> union {
> /* Tx */
> struct {
> unsigned long time_stamp;
> u16 length;
> u16 next_to_watch;
> u16 mapped_as_page;
> };
> /* Rx */
> struct {
> struct page *page; <--------------- No 1
> u64 page_dma;
> unsigned int page_offset;
> };
> };
> struct page *page; <------------ No 2
>};
>
>Hmm conflict of a member with a transparent union.
>Maybe older gccs didn't catch that. But it looks very broken
>
>Alexander, can you sort out which "page" member should be used where?
>
>And there's another problem in SCSI which I'll report separately.
>
>-Andi
Yeah, I'm pretty sure the 2nd page pointer shouldn't be there. We will look into correcting that.
Thanks,
Alex
^ permalink raw reply
* RE: __bad_udelay in network driver breaks build
From: Rose, Gregory V @ 2010-10-26 17:36 UTC (permalink / raw)
To: Duyck, Alexander H, Andi Kleen, David Miller
Cc: netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F25BCE9E78C@orsmsx501.amr.corp.intel.com>
> -----Original Message-----
> From: Duyck, Alexander H
> Sent: Tuesday, October 26, 2010 10:35 AM
> To: Andi Kleen; David Miller
> Cc: netdev@vger.kernel.org; Kirsher, Jeffrey T; Rose, Gregory V
> Subject: RE: __bad_udelay in network driver breaks build
>
> >-----Original Message-----
> >From: Andi Kleen [mailto:andi@firstfloor.org]
> >Sent: Monday, October 25, 2010 3:11 PM
> >To: David Miller
> >Cc: andi@firstfloor.org; netdev@vger.kernel.org; Kirsher, Jeffrey T;
> >Duyck, Alexander H
> >Subject: Re: __bad_udelay in network driver breaks build
> >
> >On Mon, Oct 25, 2010 at 01:05:13PM -0700, David Miller wrote:
> >> From: Andi Kleen <andi@firstfloor.org>
> >> Date: Mon, 18 Oct 2010 13:52:30 +0200
> >>
> >> >
> >> > Current Linus master x86-64 allyesconfig fails with
> >> >
> >> > drivers/built-in.o: In function `tms380tr_chipset_init':
> >> > tms380tr.c:(.text+0x10f02de): undefined reference to
> >`__bad_udelay'
> >> > tms380tr.c:(.text+0x10f03ab): undefined reference to
> >`__bad_udelay'
> >> > tms380tr.c:(.text+0x10f0400): undefined reference to
> >`__bad_udelay'
> >> > tms380tr.c:(.text+0x10f07b2): undefined reference to
> >`__bad_udelay'
> >> > tms380tr.c:(.text+0x10f08ed): undefined reference to
> >`__bad_udelay'
> >> > make[2]: *** [.tmp_vmlinux1] Error 1
> >>
> >> Let me know if this fixes things:
> >
> >Fixes that problem, but now I get (with Linus' latest again and a gcc
> >4.6
> >snapshot)
> >
> >In file included from /home/lsrc/git/linux-
> >2.6/drivers/net/igbvf/ethtool.c:36:0:
> >/home/lsrc/git/linux-2.6/drivers/net/igbvf/igbvf.h:129:15: error:
> >duplicate member 'page'
> >make[5]: *** [drivers/net/igbvf/ethtool.o] Error 1
> >make[4]: *** [drivers/net/igbvf] Error 2
> >
> >struct igbvf_buffer {
> > dma_addr_t dma;
> > struct sk_buff *skb;
> > union {
> > /* Tx */
> > struct {
> > unsigned long time_stamp;
> > u16 length;
> > u16 next_to_watch;
> > u16 mapped_as_page;
> > };
> > /* Rx */
> > struct {
> > struct page *page; <--------------- No 1
> > u64 page_dma;
> > unsigned int page_offset;
> > };
> > };
> > struct page *page; <------------ No 2
> >};
> >
> >Hmm conflict of a member with a transparent union.
> >Maybe older gccs didn't catch that. But it looks very broken
> >
> >Alexander, can you sort out which "page" member should be used where?
> >
> >And there's another problem in SCSI which I'll report separately.
> >
> >-Andi
>
> Yeah, I'm pretty sure the 2nd page pointer shouldn't be there. We will
> look into correcting that.
>
> Thanks,
>
> Alex
I'll post a patch to correct this directly.
Thanks,
- Greg
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-26 17:37 UTC (permalink / raw)
To: David Miller; +Cc: brian.haley, shemminger, netdev
In-Reply-To: <20101026.102145.246528067.davem@davemloft.net>
On Tue, Oct 26, 2010 at 10:21 AM, David Miller <davem@davemloft.net> wrote:
>> Removing autoconfigured addresses is what the kernel currently does
>> when the link goes down. The patch just makes sure it happens when
>> carrier is lost as well, since losing link might mean that when
>> carrier comes back, the host might be on a different link than it was
>> before.
>
> I just think validating that fact would be a better approach than
> simply assuming link down/up means link change.
So when the link comes back, we'd have to wait for all RAs to come in
(there could be multiple routers on a link, each announcing different
prefixes), and when this is all done, compare the list of addresses to
the prefixes that are currently on the link and delete the ones that
don't match. We'd have to do the same with default routers and /64
routes to all the link prefixes.
Also, we'd have to figure out how long to wait for RAs, and when to
time out if there are no RAs. Bear in mind that for as long as you
have an invalid IPv6 address, you can't reach dual-stack websites at
all (well, technically you can, but only if you're prepared to wait 3
minutes for the connection to time out). The damage starts when
associating to the link and only stops when the addresses and routes
are removed.
Is the extra complexity worth it? This patch is three lines, deals
with what I think is the common case, and has no obvious downsides
we've spotted so far. And at least in my testing, it's a definite
improvement. Would you be opposed to doing something like this as a
first cut and iterating or backing out if it turns out to be
insufficient or broken?
^ permalink raw reply
* Re: [PATCH] gianfar: Fix crashes on RX path
From: David Miller @ 2010-10-26 17:42 UTC (permalink / raw)
To: jarkao2
Cc: eric.dumazet, eminak71, akpm, netdev, bugzilla-daemon,
bugme-daemon, avorontsov, afleming
In-Reply-To: <20101022085248.GA8571@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Fri, 22 Oct 2010 08:52:48 +0000
> On Fri, Oct 22, 2010 at 06:52:31AM +0000, Jarek Poplawski wrote:
>> On Fri, Oct 22, 2010 at 08:11:57AM +0200, Eric Dumazet wrote:
> ...
>> > Gianfar claims to be multiqueue, but only one cpu can run gfar_poll()
>> > and call gfar_clean_tx_ring() / gfar_clean_rx_ring()
>> >
>> > If not, there would be more bugs than only rx_recycle thing
>>
>> I didn't find what prevents running gfar_poll on many cpus and don't
>> claim there is no more bugs around.
>
> On the other hand, I don't see your point in the code below either.
> These're only per gfargrp queues - not per device, aren't they?
I am still not at the point where I feel confortable applying this bug
fix, in fact I am very far from that.
None of the logic is consistent in what we are saying causes the
problem.
Anything that would make the RX recycling code racy and corrupt
recycling queue of the gianfar driver, would also corrupt all of the
other RX side and other driver state.
The NAPI state is unary for gianfar, and inside of that singular
->poll() instance it iterates over the queues.
The only asynchronous path could be netpoll, but again that would
break lots of other things.
I want to be shown a code path that results in the recycle SKB
queue getting accessed in parallel on two cpus without protection
so we can understand what it is that we are fixing.
On another note, I also agree that removing this RX recycling crud
wouldn't be a bad idea. In addition to the MTU changing concerns Eric
Dumazet brought up, there are many other (less broken) ways to achieve
whatever performance gains recycling gives these devices.
Thanks.
^ permalink raw reply
* Re: [RFC] Make the ip6_tunnel reflect the true mtu.
From: David Miller @ 2010-10-26 17:44 UTC (permalink / raw)
To: Anders.Franzen; +Cc: eric.dumazet, netdev
In-Reply-To: <1287499123-25018-1-git-send-email-Anders.Franzen@ericsson.com>
From: Anders.Franzen@ericsson.com
Date: Tue, 19 Oct 2010 16:38:43 +0200
> From: Anders Franzen <anders.franzen@ericsson.com>
>
> The ip6_tunnel always assumes it consumes 40 bytes (ip6 hdr) of the mtu of the
> underlaying device. So for a normal ethernet bearer, the mtu of the ip6_tunnel is
> 1460.
> However, when creating a tunnel the encap limit option is enabled by default, and it
> consumes 8 bytes more, so the true mtu shall be 1452.
>
> I dont really know if this breaks some statement in some RFC, so this is a request for
> comments.
This patch looks fine to me, but please fully resubmit this with a
proper "Signed-off-by: " tag as per Documentation/SubmittingPatches
Thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: David Miller @ 2010-10-26 17:47 UTC (permalink / raw)
To: lorenzo; +Cc: brian.haley, shemminger, netdev
In-Reply-To: <AANLkTi=P80OUBSy3xCt_qOjPGTwNjrtFL1iLJnkc9joq@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 26 Oct 2010 10:37:53 -0700
> So when the link comes back, we'd have to wait for all RAs to come in
> (there could be multiple routers on a link, each announcing different
> prefixes), and when this is all done, compare the list of addresses to
> the prefixes that are currently on the link and delete the ones that
> don't match. We'd have to do the same with default routers and /64
> routes to all the link prefixes.
Why would you do this when there are link layer indications that
we are attached to a different network?
The only thing missing is a new device notification type, some code to
generate it in the wireless subsystem, and an ipv6 handler to zap the
addresses when received.
Please think out of the box for a second, thanks :-)
^ permalink raw reply
* Re: [PATCH] can: mcp251x: fix reception of standard RTR frames
From: David Miller @ 2010-10-26 17:49 UTC (permalink / raw)
To: mkl; +Cc: socketcan-core, netdev
In-Reply-To: <1287679030-13993-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu, 21 Oct 2010 18:37:10 +0200
> This patch sets the missing CAN_RTR_FLAG if a standard RTR frame is
> received.
> (For extended frames the CAN_RTR_FLAG was already set correctly.)
>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH] can: flexcan: fix use after free of priv
From: David Miller @ 2010-10-26 17:49 UTC (permalink / raw)
To: mkl-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1287673678-27510-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Date: Thu, 21 Oct 2010 17:07:58 +0200
> The priv is part of the memory allocated by alloc_candev().
> This patch moved the free it after last usage of priv.
>
> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-26 17:50 UTC (permalink / raw)
To: David Miller; +Cc: brian.haley, shemminger, netdev
In-Reply-To: <20101026.104710.232747902.davem@davemloft.net>
On Tue, Oct 26, 2010 at 10:47 AM, David Miller <davem@davemloft.net> wrote:
> Why would you do this when there are link layer indications that
> we are attached to a different network?
Are there? For wifi you could look at the SSID (though even that is no
guarantee - for example enterprise networks commonly use just a few
SSIDs, but have different IP address ranges on a per-controller or
per-radio basis). But what about wired? Remember, the same thing
happens when you unplug your laptop's ethernet port and plug it in to
another network.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: David Miller @ 2010-10-26 17:52 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CC61B1B.3090602-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Tomoya <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Tue, 26 Oct 2010 09:04:43 +0900
> Hi David,
>
>> This patch has been corrupted by your email client.
>
> Sorry, it seems my e-mail client setting was reset to default.
There are still problems.
This is beyond frustrating.
> index 55ec324..2889e11 100755
Why does the pch_can.c file have execute permission in your tree?
It doesn't in net-next-2.6 and that is what you should be generating
patches against.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: David Miller @ 2010-10-26 17:55 UTC (permalink / raw)
To: lorenzo; +Cc: brian.haley, shemminger, netdev
In-Reply-To: <AANLkTi=DPaxVLzasA_xs0rPQGBFtfbS7aThx54OT798H@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 26 Oct 2010 10:50:20 -0700
> On Tue, Oct 26, 2010 at 10:47 AM, David Miller <davem@davemloft.net> wrote:
>> Why would you do this when there are link layer indications that
>> we are attached to a different network?
>
> Are there? For wifi you could look at the SSID (though even that is no
I'm saying to check the AP's MAC.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: David Miller @ 2010-10-26 17:55 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20101026.105206.15244527.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Tue, 26 Oct 2010 10:52:06 -0700 (PDT)
> It doesn't in net-next-2.6 and that is what you should be generating
^^^^^^^^^^^^
> patches against.
I mean net-2.6 of course.
^ permalink raw reply
* Re: [PATCH v2 11/14] bnx2x: Update bnx2x to use new vlan accleration.
From: Jesse Gross @ 2010-10-26 17:57 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: David Miller, netdev@vger.kernel.org, Hao Zheng, Eilon Greenstein
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDEE6B1428@SJEXCHCCR02.corp.ad.broadcom.com>
On Tue, Oct 26, 2010 at 2:14 AM, Vladislav Zolotarov <vladz@broadcom.com> wrote:
>>
>> Even though the fix prevents the panic, I'm still a little concerned
>> that you ran into it at all when vlan stripping was disabled. That
>> function should only be called when a tag was received by the card.
>> Is it possible that __vlan_hwaccel_put_tag is being called even in
>> cases when no tag was stripped?
>
> Correct, and that's because u've patched the driver to put it the
> following way:
>
> if (le16_to_cpu(cqe->fast_path_cqe.pars_flags.flags) &
> PARSING_FLAGS_VLAN)
> __vlan_hwaccel_put_tag(skb, le16_to_cpu(cqe->fast_path_cqe.vlan_tag));
>
> The condition above will be TRUE regardless VLAN stripping is enabled or
> disabled as the parsing flags come from our PARSER HW block and simply
> indicates whether this frame has a VLAN header or not. When I disabled a VLAN
> stripping I should have fixed this lines too but I think I didn't... ;)
>
>> Maybe we made a mistake when converting the driver?
>
> Since the driver always configures the VLAN stripping now, regardless the kernel
> configuration, I think your patch was just fine. ;)
Great. Thanks for the explanation and confirmation.
^ 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