* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-30 18:36 UTC (permalink / raw)
To: Simon Horman
Cc: Ben Hutchings, Kirsher, Jeffrey T, davem@davemloft.net,
shemminger@vyatta.com, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <20091130060323.GA17989@verge.net.au>
>From: Simon Horman [mailto:horms@verge.net.au]
>Sent: Sunday, November 29, 2009 10:03 PM
>> The issue of which VF goes with which PF device can be deduced in
>> userspace via sysfs.
>
>Does this mean that the configuration of filtering for a VF needs
>to be done where the interface for the VF exists - e.g. in a KVM
>guest/Xen domU?
>
No, all of the configuration is done through the PF device. What I was saying was that, given a specific VF PCI device (which would be passed through to the VM), you can use sysfs to determine which PF owns it, and then run the ip command to tell the PF to configure the VF.
>In terms of dealing with interfaces and the way that tools such as ip work
>that makes a lot of sense. But I wonder if it actually makes more sense
>from an administrative point of view to have this configuration go through
>the PF - e.g. the KVM host/Xen domO.
>From a policy and security standpoint, you can't allow the VM to handle its own hardware configuration. The host/hypervisor/VM Manager/boss has to handle this or you lose many of the advantages of virtualization (i.e. isolation, security, stability, etc).
-Mitch
^ permalink raw reply
* RE: [RFC PATCH v3 0/8] CAIF Protocol Stack
From: Sjur Brændeland @ 2009-11-30 18:26 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, stefano.babic, randy.dunlap, Kim Lilliestierna XX
In-Reply-To: <4B13EE0C.7080000@trash.net>
Patrick McHardy wrote:
>
> Please add the changelog to the respective patches and give them
> meaningful subjects. Its impossible to review patches if you don't
> even know what they're supposed to do.
OK, I'll do so next time.
Patch 7/8 contains some documentation about CAIF.
BR/Sjur Brændeland
^ permalink raw reply
* Re: scp stalls mysteriously
From: Frederic Leroy @ 2009-11-30 18:50 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev, Asdo
In-Reply-To: <alpine.DEB.2.00.0911281257270.25587@melkinpaasi.cs.helsinki.fi>
Le Sat, 28 Nov 2009 13:31:14 +0200 (EET),
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> I restored Ccs. Please keep them.
Sorry,
> On Sat, 28 Nov 2009, Frederic Leroy wrote:
>
> > Le Sat, 28 Nov 2009 00:12:23 +0200 (EET),
> > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> >
> > > On Fri, 27 Nov 2009, Frederic Leroy wrote:
> > >
> > > > I put traces of stall here :
> > > > http://www.starox.org/pub/scp_stall/
> [...]
> Perhaps having the /proc/net/tcp would at least tell what state the
> timer is (if I cannot reproduce right away). ...It is rather strange
> that two independent mechanisms for loss recovery seem both to fail
> to get triggered here, no traces of retransmission whatsoever. I
> think it is for now enough to concentrate on what happens on
> 192.168.1.15 (=houba?) and get tcpdump and proc/net/tcp from there,
> the other end/direction has very little significance here (except for
> the fact that bidirectionality might be needed to actually trigger
> it). You could even think of getting proc/net/tcp a bit more often,
> right from the start:
>
> while [ : ]; do grep ":0016" /proc/net/tcp; sleep 0.1; done | tee
> scp_stall-houba.x.proc_net_tcp
>
> ...Please wait at least 2 minutes before hitting ctrl-c or otherwise
> artificially intervening.
You're right, 192.168.1.15 is houba.
The faulty behaviour comes back today, I did new captures on
192.168.1.15 only :
http://www.starox.org/pub/scp_stall/scp_stall-houba.2.pcap
http://www.starox.org/pub/scp_stall/scp_stall-houba.2.proc_net_tcp
http://www.starox.org/pub/scp_stall/scp_stall-houba.3.pcap
http://www.starox.org/pub/scp_stall/scp_stall-houba.3.proc_net_tcp
Which tool do you use to analyze /proc/net/tcp ?
--
Frédéric Leroy
^ permalink raw reply
* Re: [PATCH 01/20] net: NETDEV_UNREGISTER_PERNET -> NETDEV_UNREGISTER_BATCH
From: Eric W. Biederman @ 2009-11-30 19:00 UTC (permalink / raw)
To: Octavian Purdila
Cc: David Miller, netdev, jamal, Daniel Lezcano, Alexey Dobriyan,
Patrick McHardy
In-Reply-To: <200911301408.33297.opurdila@ixiacom.com>
Octavian Purdila <opurdila@ixiacom.com> writes:
> On Monday 30 November 2009 03:45:58 you wrote:
>
>> + /* Process any work delayed until the end of the batch */
>> + dev = list_entry(head->next, struct net_device, unreg_list);
>> + call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
>>
>> - list_for_each_entry_safe(dev, aux, head, unreg_list) {
>> - int new_net = 1;
>> - list_for_each_entry(fdev, &pernet_list, unreg_list) {
>> - if (net_eq(dev_net(dev), dev_net(fdev))) {
>> - new_net = 0;
>> - dev_put(dev);
>> - break;
>> - }
>> - }
>> - if (new_net)
>> - list_move(&dev->unreg_list, &pernet_list);
>> - }
>>
>
> This implies that the devices we want to batch unregister needs to be part of
> the same namespace. It might be worth mentioning that in the
> unregister_netdevice_many() function comments.
No it does not. For the route cache flush we have already done the delayed
invalidate per namespace. So we only need to walk the route cache once and
simply remove the entries that have been invalidated.
For other cases if we really need it, I pass in the first entry of the
unregistration list so we can recover the list if needed.
The implication is that namespaces are not what is important when batching
so it doesn't make sense to turn our list into a pretzel providing information
that is not needed.
> And, fortunately, it seems that all of the current batch unregister users
> comply with this requirement.
The case I am working on for this patchset is batching of the destruction of
devices across namespace cleanup. This change reduces my total number of
walks of the route cache from many down to one.
Eric
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-11-30 19:10 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091130195004.38dbc319@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2004 bytes --]
On Mon, 30 Nov 2009, Frederic Leroy wrote:
> Le Sat, 28 Nov 2009 13:31:14 +0200 (EET),
> "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
>
> > On Sat, 28 Nov 2009, Frederic Leroy wrote:
> >
> > > Le Sat, 28 Nov 2009 00:12:23 +0200 (EET),
> > > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> > >
> > > > On Fri, 27 Nov 2009, Frederic Leroy wrote:
> > > >
> > > > > I put traces of stall here :
> > > > > http://www.starox.org/pub/scp_stall/
> > [...]
> > Perhaps having the /proc/net/tcp would at least tell what state the
> > timer is (if I cannot reproduce right away). ...It is rather strange
> > that two independent mechanisms for loss recovery seem both to fail
> > to get triggered here, no traces of retransmission whatsoever. I
> > think it is for now enough to concentrate on what happens on
> > 192.168.1.15 (=houba?) and get tcpdump and proc/net/tcp from there,
> > the other end/direction has very little significance here (except for
> > the fact that bidirectionality might be needed to actually trigger
> > it). You could even think of getting proc/net/tcp a bit more often,
> > right from the start:
> >
> > while [ : ]; do grep ":0016" /proc/net/tcp; sleep 0.1; done | tee
> > scp_stall-houba.x.proc_net_tcp
> >
> > ...Please wait at least 2 minutes before hitting ctrl-c or otherwise
> > artificially intervening.
>
> You're right, 192.168.1.15 is houba.
> The faulty behaviour comes back today, I did new captures on
> 192.168.1.15 only :
> http://www.starox.org/pub/scp_stall/scp_stall-houba.2.pcap
> http://www.starox.org/pub/scp_stall/scp_stall-houba.2.proc_net_tcp
> http://www.starox.org/pub/scp_stall/scp_stall-houba.3.pcap
> http://www.starox.org/pub/scp_stall/scp_stall-houba.3.proc_net_tcp
Thanks, I'll take a look.
> Which tool do you use to analyze /proc/net/tcp ?
I just recall the order of fields from net/ipv4/tcp_ipv4.c and apply my
knowledge about TCP internals from there on. ...I've no particularly fancy
tools for the job.
--
i.
^ permalink raw reply
* Re: [PATCH 0/20] Batch network namespace cleanup
From: Eric W. Biederman @ 2009-11-30 19:22 UTC (permalink / raw)
To: hadi; +Cc: David Miller, netdev, Daniel Lezcano, Alexey Dobriyan,
Patrick McHardy
In-Reply-To: <1259585043.873.21.camel@bigi>
jamal <hadi@cyberus.ca> writes:
> On Sun, 2009-11-29 at 17:46 -0800, Eric W. Biederman wrote:
>>
>> Recently Jamal and Daniel perform some experiments and found that
>> large numbers of network namespace exiting simultaneously is very
>> inefficient. 24+ minutes in some configurations. The cpu overhead
>> was negligible but it results in long hold times of net_mutex, and
>> memory being consumed a long time after the last user has gone away.
>>
>> I looked into it and discovered that by batching network namespace
>> cleanups I can reduce the time for 4k network namespaces exiting from
>> 5-7 minutes in my configuration to 44 seconds.
>
> Excellent work Eric. I have time today so i can test these patches
> status quo vs.
> This is against net-next?
Yes.
Eric
^ permalink raw reply
* Re: [PATCH 01/20] net: NETDEV_UNREGISTER_PERNET -> NETDEV_UNREGISTER_BATCH
From: Octavian Purdila @ 2009-11-30 19:25 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, netdev, jamal, Daniel Lezcano, Alexey Dobriyan,
Patrick McHardy
In-Reply-To: <m1hbsb7s86.fsf@fess.ebiederm.org>
On Monday 30 November 2009 21:00:41 you wrote:
> Octavian Purdila <opurdila@ixiacom.com> writes:
> > On Monday 30 November 2009 03:45:58 you wrote:
> >> + /* Process any work delayed until the end of the batch */
> >> + dev = list_entry(head->next, struct net_device, unreg_list);
> >> + call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
> >>
> >> - list_for_each_entry_safe(dev, aux, head, unreg_list) {
> >> - int new_net = 1;
> >> - list_for_each_entry(fdev, &pernet_list, unreg_list) {
> >> - if (net_eq(dev_net(dev), dev_net(fdev))) {
> >> - new_net = 0;
> >> - dev_put(dev);
> >> - break;
> >> - }
> >> - }
> >> - if (new_net)
> >> - list_move(&dev->unreg_list, &pernet_list);
> >> - }
> >
> > This implies that the devices we want to batch unregister needs to be
> > part of the same namespace. It might be worth mentioning that in the
> > unregister_netdevice_many() function comments.
>
> No it does not. For the route cache flush we have already done the delayed
> invalidate per namespace. So we only need to walk the route cache once and
> simply remove the entries that have been invalidated.
>
Right ! I thought that we need to do the cache cleaning per namespace, now my
patch looks really stupid :)
^ permalink raw reply
* Re: RFC: net 00/05: routing based send-to-self implementation
From: Eric W. Biederman @ 2009-11-30 19:32 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <20091130175529.7555.10132.sendpatchset@x2.localnet>
Patrick McHardy <kaber@trash.net> writes:
> These patches are yet another attempt at adding "send-to-self" functionality,
> allowing to send packets between two local interfaces over the wire. Unlike
> the approaches I've seen so far, this one is purely routing based.
> Especially the oif classification should also be useful for different setups.
Why not put each physical interface in a different network namespace?
That should work with no changes today.
Eric
^ permalink raw reply
* Re: RFC: net 00/05: routing based send-to-self implementation
From: Ben Greear @ 2009-11-30 19:37 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Patrick McHardy, netdev
In-Reply-To: <m1r5rf4xm9.fsf@fess.ebiederm.org>
On 11/30/2009 11:32 AM, Eric W. Biederman wrote:
> Patrick McHardy<kaber@trash.net> writes:
>
>> These patches are yet another attempt at adding "send-to-self" functionality,
>> allowing to send packets between two local interfaces over the wire. Unlike
>> the approaches I've seen so far, this one is purely routing based.
>> Especially the oif classification should also be useful for different setups.
>
> Why not put each physical interface in a different network namespace?
> That should work with no changes today.
This doesn't work if you want to have one application manage lots of interfaces
and send traffic between these interfaces. Certainly there are use-cases that
can use multiple name-spaces, but it's nice to have the option not to use them
as well.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [Bugme-new] [Bug 14691] New: Complete NAPI IRQ lockup in b44 driver: code fundamentally incompatible with netconsole requirements
From: Andreas Mohr @ 2009-11-30 19:39 UTC (permalink / raw)
To: Andrew Morton
Cc: davem, Gary Zambrano, bugzilla-daemon, bugme-daemon, netdev, andi
In-Reply-To: <20091125131631.46483ce0.akpm@linux-foundation.org>
Improved patch created by David Miller (thanks!).
>From my POV, this can be considered handled.
http://lkml.org/lkml/2009/11/30/51
http://patchwork.kernel.org/patch/63627/
Andreas Mohr
^ permalink raw reply
* Re: warning: massive change to conditional coding style in net?
From: Jarek Poplawski @ 2009-11-30 19:39 UTC (permalink / raw)
To: Alan Cox
Cc: William Allen Simpson, Linux Kernel Developers,
Linux Kernel Network Developers
In-Reply-To: <20091130135435.3895a437@lxorguk.ukuu.org.uk>
Alan Cox wrote, On 11/30/2009 02:54 PM:
>>> Miller (with Perches) changed hundreds (thousands?) of these to
>>> trailing form. This results in a number of hilarious examples --
>>> lines with both leading and trailing, lines with only &&, etc. A
>>> small sample for illustration:
>> Yes, it's even enough to make a grown man laugh....
>
> IMHO for left to right languages dangly bits want to be on the right,
> because that is where your eyes are when you hit the end of the previous
> line, so the dangly bit is already in your line of vision and probably
> even in focus.
Of course this is right. Plus "IMHO" "habit is the second nature", so
riding the same side of the road helps, even if it's the wrong side. ;-)
Jarek P.
^ permalink raw reply
* pull request: wireless-2.6 2009-11-30 (security fixes too)
From: John W. Linville @ 2009-11-30 19:47 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Linus,
If a) you have already taken Dave's latest pull request; and, b) you
don't want to wait for his next one to get the mac80211 security fixes
from Johannes, then you can at your discretion pull from here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git security
That branch is in the same line as the master branch I'm asking Dave to
pull, so I think that git will work all that out without messing the
history.
Dave,
Below are a couple of mac80211 security fixes from Johannes as well as a
number of not-quite-one-liners, all intended for 2.6.32. Please let me
know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 3e9848403ad59c53b31facb30b43ca80135ae0b9:
Eric Dumazet (1):
pktgen: Fix netdevice unregister
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
Gertjan van Wingerde (1):
rt2x00: Fix padding bug on L2PAD devices.
Jean Tourrilhes (1):
WE: Fix set events not propagated
Johannes Berg (2):
mac80211: fix two remote exploits
mac80211: fix spurious delBA handling
Larry Finger (2):
b43: avoid PPC fault during resume
b43legacy: avoid PPC fault during resume
Michael Buesch (1):
airo: Fix integer overflow warning
drivers/net/wireless/airo.c | 2 +-
drivers/net/wireless/b43/rfkill.c | 10 ++++++++--
drivers/net/wireless/b43legacy/rfkill.c | 7 +++++++
drivers/net/wireless/iwlwifi/iwl-tx.c | 10 +++++++++-
drivers/net/wireless/rt2x00/rt2x00queue.c | 2 +-
include/net/mac80211.h | 6 ++++++
net/mac80211/agg-rx.c | 4 ----
net/mac80211/agg-tx.c | 17 ++++++++---------
net/mac80211/ht.c | 8 +++-----
net/mac80211/ieee80211_i.h | 2 ++
net/wireless/wext.c | 3 ++-
11 files changed, 47 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index abf896a..02f70de 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -4806,7 +4806,7 @@ static int airo_config_commit(struct net_device *dev,
static inline int sniffing_mode(struct airo_info *ai)
{
- return le16_to_cpu(ai->config.rmode & RXMODE_MASK) >=
+ return (le16_to_cpu(ai->config.rmode) & le16_to_cpu(RXMODE_MASK)) >=
le16_to_cpu(RXMODE_RFMON);
}
diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c
index ffdce6f..78016ae 100644
--- a/drivers/net/wireless/b43/rfkill.c
+++ b/drivers/net/wireless/b43/rfkill.c
@@ -33,8 +33,14 @@ bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
& B43_MMIO_RADIO_HWENABLED_HI_MASK))
return 1;
} else {
- if (b43_status(dev) >= B43_STAT_STARTED &&
- b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
+ /* To prevent CPU fault on PPC, do not read a register
+ * unless the interface is started; however, on resume
+ * for hibernation, this routine is entered early. When
+ * that happens, unconditionally return TRUE.
+ */
+ if (b43_status(dev) < B43_STAT_STARTED)
+ return 1;
+ if (b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
& B43_MMIO_RADIO_HWENABLED_LO_MASK)
return 1;
}
diff --git a/drivers/net/wireless/b43legacy/rfkill.c b/drivers/net/wireless/b43legacy/rfkill.c
index 8783022..d579df7 100644
--- a/drivers/net/wireless/b43legacy/rfkill.c
+++ b/drivers/net/wireless/b43legacy/rfkill.c
@@ -34,6 +34,13 @@ bool b43legacy_is_hw_radio_enabled(struct b43legacy_wldev *dev)
& B43legacy_MMIO_RADIO_HWENABLED_HI_MASK))
return 1;
} else {
+ /* To prevent CPU fault on PPC, do not read a register
+ * unless the interface is started; however, on resume
+ * for hibernation, this routine is entered early. When
+ * that happens, unconditionally return TRUE.
+ */
+ if (b43legacy_status(dev) < B43legacy_STAT_STARTED)
+ return 1;
if (b43legacy_read16(dev, B43legacy_MMIO_RADIO_HWENABLED_LO)
& B43legacy_MMIO_RADIO_HWENABLED_LO_MASK)
return 1;
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index fb9bcfa..b7e196e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -1277,8 +1277,16 @@ int iwl_tx_agg_stop(struct iwl_priv *priv , const u8 *ra, u16 tid)
return -ENXIO;
}
+ if (priv->stations[sta_id].tid[tid].agg.state ==
+ IWL_EMPTYING_HW_QUEUE_ADDBA) {
+ IWL_DEBUG_HT(priv, "AGG stop before setup done\n");
+ ieee80211_stop_tx_ba_cb_irqsafe(priv->hw, ra, tid);
+ priv->stations[sta_id].tid[tid].agg.state = IWL_AGG_OFF;
+ return 0;
+ }
+
if (priv->stations[sta_id].tid[tid].agg.state != IWL_AGG_ON)
- IWL_WARN(priv, "Stopping AGG while state not IWL_AGG_ON\n");
+ IWL_WARN(priv, "Stopping AGG while state not ON or starting\n");
tid_data = &priv->stations[sta_id].tid[tid];
ssn = (tid_data->seq_number & IEEE80211_SCTL_SEQ) >> 4;
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 577029e..d7a7ede 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -213,7 +213,7 @@ void rt2x00queue_insert_l2pad(struct sk_buff *skb, unsigned int header_length)
skb_push(skb, header_align);
memmove(skb->data, skb->data + header_align, header_length);
memmove(skb->data + header_length + l2pad,
- skb->data + header_length + l2pad + header_align,
+ skb->data + header_length + l2pad + payload_align,
frame_length - header_length);
skbdesc->flags |= SKBDESC_L2_PADDED;
}
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index c75b960..998c30f 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1283,6 +1283,12 @@ enum ieee80211_filter_flags {
*
* These flags are used with the ampdu_action() callback in
* &struct ieee80211_ops to indicate which action is needed.
+ *
+ * Note that drivers MUST be able to deal with a TX aggregation
+ * session being stopped even before they OK'ed starting it by
+ * calling ieee80211_start_tx_ba_cb(_irqsafe), because the peer
+ * might receive the addBA frame and send a delBA right away!
+ *
* @IEEE80211_AMPDU_RX_START: start Rx aggregation
* @IEEE80211_AMPDU_RX_STOP: stop Rx aggregation
* @IEEE80211_AMPDU_TX_START: start Tx aggregation
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index bc064d7..ce8e0e7 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -85,10 +85,6 @@ void ieee80211_sta_stop_rx_ba_session(struct ieee80211_sub_if_data *sdata, u8 *r
struct ieee80211_local *local = sdata->local;
struct sta_info *sta;
- /* stop HW Rx aggregation. ampdu_action existence
- * already verified in session init so we add the BUG_ON */
- BUG_ON(!local->ops->ampdu_action);
-
rcu_read_lock();
sta = sta_info_get(local, ra);
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 206fd82..89e238b 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -123,13 +123,18 @@ void ieee80211_send_bar(struct ieee80211_sub_if_data *sdata, u8 *ra, u16 tid, u1
ieee80211_tx_skb(sdata, skb, 0);
}
-static int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
- enum ieee80211_back_parties initiator)
+int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
+ enum ieee80211_back_parties initiator)
{
struct ieee80211_local *local = sta->local;
int ret;
u8 *state;
+#ifdef CONFIG_MAC80211_HT_DEBUG
+ printk(KERN_DEBUG "Tx BA session stop requested for %pM tid %u\n",
+ sta->sta.addr, tid);
+#endif /* CONFIG_MAC80211_HT_DEBUG */
+
state = &sta->ampdu_mlme.tid_state_tx[tid];
if (*state == HT_AGG_STATE_OPERATIONAL)
@@ -143,7 +148,6 @@ static int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
/* HW shall not deny going back to legacy */
if (WARN_ON(ret)) {
- *state = HT_AGG_STATE_OPERATIONAL;
/*
* We may have pending packets get stuck in this case...
* Not bothering with a workaround for now.
@@ -525,11 +529,6 @@ int __ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
goto unlock;
}
-#ifdef CONFIG_MAC80211_HT_DEBUG
- printk(KERN_DEBUG "Tx BA session stop requested for %pM tid %u\n",
- sta->sta.addr, tid);
-#endif /* CONFIG_MAC80211_HT_DEBUG */
-
ret = ___ieee80211_stop_tx_ba_session(sta, tid, initiator);
unlock:
@@ -545,7 +544,7 @@ int ieee80211_stop_tx_ba_session(struct ieee80211_hw *hw,
struct sta_info *sta;
int ret = 0;
- if (WARN_ON(!local->ops->ampdu_action))
+ if (!local->ops->ampdu_action)
return -EINVAL;
if (tid >= STA_TID_NUM)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index 48ef1a2..cdc58e6 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -141,7 +141,6 @@ void ieee80211_process_delba(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta,
struct ieee80211_mgmt *mgmt, size_t len)
{
- struct ieee80211_local *local = sdata->local;
u16 tid, params;
u16 initiator;
@@ -161,10 +160,9 @@ void ieee80211_process_delba(struct ieee80211_sub_if_data *sdata,
WLAN_BACK_INITIATOR, 0);
else { /* WLAN_BACK_RECIPIENT */
spin_lock_bh(&sta->lock);
- sta->ampdu_mlme.tid_state_tx[tid] =
- HT_AGG_STATE_OPERATIONAL;
+ if (sta->ampdu_mlme.tid_state_tx[tid] & HT_ADDBA_REQUESTED_MSK)
+ ___ieee80211_stop_tx_ba_session(sta, tid,
+ WLAN_BACK_RECIPIENT);
spin_unlock_bh(&sta->lock);
- ieee80211_stop_tx_ba_session(&local->hw, sta->sta.addr, tid,
- WLAN_BACK_RECIPIENT);
}
}
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index a910bf1..10d316e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1091,6 +1091,8 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
int __ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
enum ieee80211_back_parties initiator);
+int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
+ enum ieee80211_back_parties initiator);
/* Spectrum management */
void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
diff --git a/net/wireless/wext.c b/net/wireless/wext.c
index 60fe577..eb32ff0 100644
--- a/net/wireless/wext.c
+++ b/net/wireless/wext.c
@@ -875,7 +875,8 @@ static int ioctl_standard_iw_point(struct iw_point *iwp, unsigned int cmd,
}
/* Generate an event to notify listeners of the change */
- if ((descr->flags & IW_DESCR_FLAG_EVENT) && err == -EIWCOMMIT) {
+ if ((descr->flags & IW_DESCR_FLAG_EVENT) &&
+ ((err == 0) || (err == -EIWCOMMIT))) {
union iwreq_data *data = (union iwreq_data *) iwp;
if (descr->flags & IW_DESCR_FLAG_RESTRICT)
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: RFC: net 00/05: routing based send-to-self implementation
From: Benjamin LaHaise @ 2009-11-30 20:04 UTC (permalink / raw)
To: Ben Greear; +Cc: Eric W. Biederman, Patrick McHardy, netdev
In-Reply-To: <4B141EFB.4070409@candelatech.com>
On Mon, Nov 30, 2009 at 11:37:31AM -0800, Ben Greear wrote:
> This doesn't work if you want to have one application manage lots of
> interfaces and send traffic between these interfaces. Certainly there are
> use-cases that can use multiple name-spaces, but it's nice to have the
> option not to use them as well.
Actually, it's quite doable from within one application. An application
I recently adapted to make use of multiple network namespaces within a single
process by way of pthreads and unshare(CLONE_NEWNET). The scheme I used
is to just open the socket in a new namespace in a thread. Since the
file descriptor table is still shared, it's easy to send/receive data from
any other thread, regardless of which virtual network namespace it's in.
All told, setting up virtual routers with namespaces is pretty easy.
-ben
^ permalink raw reply
* [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device
From: Andy Gospodarek @ 2009-11-30 20:14 UTC (permalink / raw)
To: netdev, fubar
This allows a bond device to specify an arp_ip_target as a host that is
not on the same vlan as the base bond device. A configuration like
this, now works:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
9: bond0.100@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 1000
ARP IP target/s (n.n.n.n form): 10.0.100.1
Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Permanent HW addr: 00:40:05:30:ff:30
Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:13:21:be:33:e9
I've tested this on 2.6.31 with devices and support VLAN acceleration
and those that do not as well as a backport on 2.6.18 with success.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
drivers/net/bonding/bond_main.c | 3 +++
net/8021q/vlan_core.c | 2 ++
net/core/dev.c | 6 +++---
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 726bd75..aee8973 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2691,6 +2691,9 @@ static int bond_arp_rcv(struct sk_buff *skb, struct net_device *dev, struct pack
unsigned char *arp_ptr;
__be32 sip, tip;
+ while (dev->priv_flags & IFF_802_1Q_VLAN)
+ dev = vlan_dev_real_dev(dev);
+
if (!(dev->priv_flags & IFF_BONDING) || !(dev->flags & IFF_MASTER))
goto out;
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index e75a2f3..8d8a778 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -14,6 +14,7 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
if (skb_bond_should_drop(skb))
goto drop;
+ skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
@@ -85,6 +86,7 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
if (skb_bond_should_drop(skb))
goto drop;
+ skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
diff --git a/net/core/dev.c b/net/core/dev.c
index 5d131c2..eeee269 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2439,8 +2439,8 @@ int netif_receive_skb(struct sk_buff *skb)
skb->skb_iif = skb->dev->ifindex;
null_or_orig = NULL;
- orig_dev = skb->dev;
- if (orig_dev->master) {
+ orig_dev = __dev_get_by_index(dev_net(skb->dev),skb->skb_iif);
+ if (orig_dev->master && !(skb->dev->priv_flags & IFF_802_1Q_VLAN)) {
if (skb_bond_should_drop(skb))
null_or_orig = orig_dev; /* deliver only exact match */
else
@@ -2492,7 +2492,7 @@ ncls:
&ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
if (ptype->type == type &&
(ptype->dev == null_or_orig || ptype->dev == skb->dev ||
- ptype->dev == orig_dev)) {
+ ptype->dev == orig_dev || ptype->dev == orig_dev->master)) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = ptype;
--
1.6.2.5
^ permalink raw reply related
* Re: RFC: net 00/05: routing based send-to-self implementation
From: Patrick McHardy @ 2009-11-30 20:15 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Ben Greear, Eric W. Biederman, netdev
In-Reply-To: <20091130200430.GS14610@kvack.org>
Benjamin LaHaise wrote:
> On Mon, Nov 30, 2009 at 11:37:31AM -0800, Ben Greear wrote:
>> This doesn't work if you want to have one application manage lots of
>> interfaces and send traffic between these interfaces. Certainly there are
>> use-cases that can use multiple name-spaces, but it's nice to have the
>> option not to use them as well.
>
> Actually, it's quite doable from within one application. An application
> I recently adapted to make use of multiple network namespaces within a single
> process by way of pthreads and unshare(CLONE_NEWNET). The scheme I used
> is to just open the socket in a new namespace in a thread. Since the
> file descriptor table is still shared, it's easy to send/receive data from
> any other thread, regardless of which virtual network namespace it's in.
> All told, setting up virtual routers with namespaces is pretty easy.
Yes, that works for creating sockets. Its gets more complicated
though if you want to change network configuration of those devices
once created and moved to a different namespace. Besides that you
might have to replicate your other configuration, like iptables rules,
routing rules and routes, xfrm policies etc.
^ permalink raw reply
* Re: RFC: net 00/05: routing based send-to-self implementation
From: Ben Greear @ 2009-11-30 20:15 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Eric W. Biederman, Patrick McHardy, netdev
In-Reply-To: <20091130200430.GS14610@kvack.org>
On 11/30/2009 12:04 PM, Benjamin LaHaise wrote:
> On Mon, Nov 30, 2009 at 11:37:31AM -0800, Ben Greear wrote:
>> This doesn't work if you want to have one application manage lots of
>> interfaces and send traffic between these interfaces. Certainly there are
>> use-cases that can use multiple name-spaces, but it's nice to have the
>> option not to use them as well.
>
> Actually, it's quite doable from within one application. An application
> I recently adapted to make use of multiple network namespaces within a single
> process by way of pthreads and unshare(CLONE_NEWNET). The scheme I used
> is to just open the socket in a new namespace in a thread. Since the
> file descriptor table is still shared, it's easy to send/receive data from
> any other thread, regardless of which virtual network namespace it's in.
> All told, setting up virtual routers with namespaces is pretty easy.
That still sounds more complicated than the proposed routing table changes,
at least for my application. Since I also want to gather stats, set/watch routes,
etc, on each network device, would I have to keep a thread and netlink socket
running in each name-space in order to see the various devices?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [tproxy,regression] tproxy broken in 2.6.32
From: David Miller @ 2009-11-30 20:17 UTC (permalink / raw)
To: hadi; +Cc: hidden, kaber, hidden, aschultz, tproxy, netdev
In-Reply-To: <1259583359.873.17.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Mon, 30 Nov 2009 07:15:59 -0500
> Dave, give me some short time to mull this over. I am not sure i like
> the sysctl approach - we may have to just revert the whole thing
> instead.
Ok, please come to some conclusion by the end of this week.
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-11-30 20:18 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091130195004.38dbc319@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3284 bytes --]
On Mon, 30 Nov 2009, Frederic Leroy wrote:
> Le Sat, 28 Nov 2009 13:31:14 +0200 (EET),
> "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
>
> > On Sat, 28 Nov 2009, Frederic Leroy wrote:
> >
> > > Le Sat, 28 Nov 2009 00:12:23 +0200 (EET),
> > > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> > >
> > > > On Fri, 27 Nov 2009, Frederic Leroy wrote:
> > > >
> > > > > I put traces of stall here :
> > > > > http://www.starox.org/pub/scp_stall/
> > [...]
> > Perhaps having the /proc/net/tcp would at least tell what state the
> > timer is (if I cannot reproduce right away). ...It is rather strange
> > that two independent mechanisms for loss recovery seem both to fail
> > to get triggered here, no traces of retransmission whatsoever. I
> > think it is for now enough to concentrate on what happens on
> > 192.168.1.15 (=houba?) and get tcpdump and proc/net/tcp from there,
> > the other end/direction has very little significance here (except for
> > the fact that bidirectionality might be needed to actually trigger
> > it). You could even think of getting proc/net/tcp a bit more often,
> > right from the start:
> >
> > while [ : ]; do grep ":0016" /proc/net/tcp; sleep 0.1; done | tee
> > scp_stall-houba.x.proc_net_tcp
> >
> > ...Please wait at least 2 minutes before hitting ctrl-c or otherwise
> > artificially intervening.
>
> You're right, 192.168.1.15 is houba.
> The faulty behaviour comes back today, I did new captures on
> 192.168.1.15 only :
> http://www.starox.org/pub/scp_stall/scp_stall-houba.2.pcap
> http://www.starox.org/pub/scp_stall/scp_stall-houba.2.proc_net_tcp
> http://www.starox.org/pub/scp_stall/scp_stall-houba.3.pcap
> http://www.starox.org/pub/scp_stall/scp_stall-houba.3.proc_net_tcp
>
> Which tool do you use to analyze /proc/net/tcp ?
Thanks, at least ....3.... shows that cwnd (congestion window, the 2nd to
last field in /proc/net/tcp) goes to zero which it never ever should.
...I'll start reading some code to figure out the cause for that.
How much is your RTT btw? The RTO timeout easily goes up to 120 secods
similar to what I found myself already. Thus I'm not sure if this stall
would be "infinite" after all.
I've some problem in .3. case in matching timing of the proc/net/tcp dump
and the tcpdump ... did you perhaps cut it somewhere? This might point out
to yet another problem, however, I'm not sure what I can atm trust in the
logs. ...Timestamps would probably help me a bit (I've changed also sleep
to do 0.01 granularity):
while [ : ]; do date "+%s.%N"; grep ":0016" /proc/net/tcp; sleep 0.01; done | tee scp_stall-houba.x.proc_net_tcp
(Please run start while loop before starting the transfer and all the way
until the connection is already killed and only then stop the loop).
What happened in .2. case I've very little idea, proc/net/tcp does claim
retransmission would have happened on TCP layer but that never went into
tcpdump log (the kind of thing might have happened in the .3. case too
which is why I asked for the timestamps for matching captures more exactly
but there were some retransmissions earlier in the log so I cannot be
sure). Can you also check that tcpdump doesn't lose any packets, it
should show: "0 packets dropped by kernel" when you ctrl-c it.
--
i.
^ permalink raw reply
* Re: ixgbe question
From: John Fastabend @ 2009-11-30 20:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Waskiewicz Jr, Peter P, robert@herjulf.net,
hawk@diku.dk, netdev@vger.kernel.org
In-Reply-To: <4B13C250.7020402@gmail.com>
Eric Dumazet wrote:
> David Miller a écrit :
>
>> From: John Fastabend <john.r.fastabend@intel.com>
>> Date: Tue, 24 Nov 2009 13:14:12 +0000
>>
>>
>>> Believe the below patch will break DCB and FCoE though, both features
>>> have the potential to set real_num_tx_queues to greater then the
>>> number of CPUs. This could result in real_num_tx_queues >
>>> num_tx_queues.
>>>
>>> The current solution isn't that great though, maybe we should set to
>>> the minimum of MAX_TX_QUEUES and num_possible_cpus() * 2 + 8.
>>>
>>> That should cover the maximum possible queues for DCB, FCoE and their
>>> combinations.
>>>
>>> general multiq = num_possible_cpus()
>>> DCB = 8 tx queue's
>>> FCoE = 2*num_possible_cpus()
>>> FCoE + DCB = 8 tx queues + num_possible_cpus
>>>
>> Eric, I'm tossing your patch because of this problem, just FYI.
>>
>
> Sure, I guess we need a more generic way to handle this.
>
>
Eric,
I'll resubmit your patch with a small update to fix my concerns soon.
thanks,
john.
^ permalink raw reply
* Re: dmfe/tulip device id overlap
From: David Miller @ 2009-11-30 20:21 UTC (permalink / raw)
To: ben; +Cc: brandon, grundler, tobias, kyle, netdev, grundler
In-Reply-To: <1259585185.3709.181.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 30 Nov 2009 12:46:25 +0000
> If the problem is that the drivers are not portable, then this makes
> sense. However, as I understand it, the problem is that the same device
> ids have been assigned to significantly different controllers/boards.
> In this case it may be better for both of the drivers to claim the
> device ids and to distinguish them at probe time.
It is going to be so easy to tell them apart.
Simply because onboard devices on Sparc are going to have
openfirmware, so there are going to be OF device properties and
whatnot we can probe for if necessary.
And the only difference the chips can have at this level is what kind
of PHY et al. are attached to the MAC. Fundamentally the devices are
going to be the same.
^ permalink raw reply
* Re: net 02/05: fib_rules: rename ifindex/ifname/FRA_IFNAME to iifindex/iifname/FRA_IIFNAME
From: Jarek Poplawski @ 2009-11-30 20:21 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <20091130175532.7555.11857.sendpatchset@x2.localnet>
Patrick McHardy wrote, On 11/30/2009 06:55 PM:
> commit dc4427ae3647195508b4df883050a9f0ef111165
> Author: Patrick McHardy <kaber@trash.net>
> Date: Mon Nov 30 15:54:05 2009 +0100
>
> net: fib_rules: rename ifindex/ifname/FRA_IFNAME to iifindex/iifname/FRA_IIFNAME
>
> The next patch will add oif classification, rename interface related members
> and attributes to reflect that they're used for iif classification.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> diff --git a/include/linux/fib_rules.h b/include/linux/fib_rules.h
> index c7e5b70..e3c91af 100644
> --- a/include/linux/fib_rules.h
> +++ b/include/linux/fib_rules.h
> @@ -8,7 +8,8 @@
> #define FIB_RULE_PERMANENT 0x00000001
> #define FIB_RULE_INVERT 0x00000002
> #define FIB_RULE_UNRESOLVED 0x00000004
> -#define FIB_RULE_DEV_DETACHED 0x00000008
> +#define FIB_RULE_IIF_DETACHED 0x00000008
> +#define FIB_RULE_DEV_DETACHED FIB_RULE_DEV_DETACHED
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Is it some trick?
Jarek P.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device
From: Patrick McHardy @ 2009-11-30 20:22 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, fubar
In-Reply-To: <20091130201453.GF1639@gospo.rdu.redhat.com>
Andy Gospodarek wrote:
> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> index e75a2f3..8d8a778 100644
> --- a/net/8021q/vlan_core.c
> +++ b/net/8021q/vlan_core.c
> @@ -14,6 +14,7 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
> if (skb_bond_should_drop(skb))
> goto drop;
>
> + skb->skb_iif = skb->dev->ifindex;
> __vlan_hwaccel_put_tag(skb, vlan_tci);
> skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
>
> @@ -85,6 +86,7 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
> if (skb_bond_should_drop(skb))
> goto drop;
>
> + skb->skb_iif = skb->dev->ifindex;
> __vlan_hwaccel_put_tag(skb, vlan_tci);
> skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
>
How about pulling the skb->iif assignment in netif_receive_skb() up
before the vlan_hwaccel_do_receive() call instead? I'd actually call
this a bug fix since hardware accelerated devices should not differ
from non-accelerated devices in their iif value.
^ permalink raw reply
* Re: net 02/05: fib_rules: rename ifindex/ifname/FRA_IFNAME to iifindex/iifname/FRA_IIFNAME
From: Patrick McHardy @ 2009-11-30 20:23 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <4B142941.2020302@gmail.com>
Jarek Poplawski wrote:
> Patrick McHardy wrote, On 11/30/2009 06:55 PM:
>
>> commit dc4427ae3647195508b4df883050a9f0ef111165
>> Author: Patrick McHardy <kaber@trash.net>
>> Date: Mon Nov 30 15:54:05 2009 +0100
>>
>> net: fib_rules: rename ifindex/ifname/FRA_IFNAME to iifindex/iifname/FRA_IIFNAME
>>
>> The next patch will add oif classification, rename interface related members
>> and attributes to reflect that they're used for iif classification.
>>
>> Signed-off-by: Patrick McHardy <kaber@trash.net>
>>
>> diff --git a/include/linux/fib_rules.h b/include/linux/fib_rules.h
>> index c7e5b70..e3c91af 100644
>> --- a/include/linux/fib_rules.h
>> +++ b/include/linux/fib_rules.h
>> @@ -8,7 +8,8 @@
>> #define FIB_RULE_PERMANENT 0x00000001
>> #define FIB_RULE_INVERT 0x00000002
>> #define FIB_RULE_UNRESOLVED 0x00000004
>> -#define FIB_RULE_DEV_DETACHED 0x00000008
>> +#define FIB_RULE_IIF_DETACHED 0x00000008
>> +#define FIB_RULE_DEV_DETACHED FIB_RULE_DEV_DETACHED
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Is it some trick?
D'oh, thanks for catching this :) I'll fix that up for the next
submission.
^ permalink raw reply
* Re: RFC: net 00/05: routing based send-to-self implementation
From: Benjamin LaHaise @ 2009-11-30 20:23 UTC (permalink / raw)
To: Ben Greear; +Cc: Eric W. Biederman, Patrick McHardy, netdev
In-Reply-To: <4B1427ED.6070808@candelatech.com>
On Mon, Nov 30, 2009 at 12:15:41PM -0800, Ben Greear wrote:
> That still sounds more complicated than the proposed routing table changes,
True. I agree that being able to accept self-addressed packets via a
sysctl can be useful.
> at least for my application. Since I also want to gather stats, set/watch
> routes,
> etc, on each network device, would I have to keep a thread and netlink
> socket
> running in each name-space in order to see the various devices?
Yes. My l2tp daemon is still single threaded internally, so it uses an
rpc through the threads to open UDP, netlink and L2TP sockets, then manages
everything from the main event loop. The thread has to be kept around to
keep the namespace's task id alive in case one wants to move anything in/out
of the namespace.
-ben
^ permalink raw reply
* Re: dmfe/tulip device id overlap
From: David Miller @ 2009-11-30 20:26 UTC (permalink / raw)
To: grundler; +Cc: brandon, tobias, kyle, netdev, grundler
In-Reply-To: <da824cf30911300914p2d08b87cr4625e9bc30ec7e5b@mail.gmail.com>
From: Grant Grundler <grundler@google.com>
Date: Mon, 30 Nov 2009 09:14:01 -0800
> Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
> V100" motherboards?
>
> I'm asking because I'm hoping it's possible to disambiguate the add-on
> cards from
> LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
I think more likely OF properties will help here.
Have a look at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/prtconfs.git
In particular 'v100' which has a network device OF node with properties:
Node 0xf007fae8
.node: f007fae8
local-mac-address: 0003ba11.b371
assigned-addresses: 81006010.00000000.00010000.00000000.00000100.82006014.00000000.00000000.00000000.00002000.82006030.00000000.00040000.00000000.00040000
version: '1.0'
compatible: 70636934.3535342c.34333465.00706369.31323868.2c393130.32007063.69313238.322c3931.30320070.6369636c.6173732c.30323030.303000
device_type: 'network'
subsystem-id: 0000434e
subsystem-vendor-id: 00004554
reg: 00006000.00000000.00000000.00000000.00000000.01006010.00000000.00000000.00000000.00000100.02006014.00000000.00000000.00000000.00000100
name: 'ethernet'
devsel-speed: 00000001
class-code: 00020000
interrupts: 00000001
max-latency: 00000028
min-grant: 00000014
revision-id: 00000031
device-id: 00009102
vendor-id: 00001282
Hmmm, what vendor is '0x4554'? :-)
^ 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