* Re: [PATCH v3] net-tcp: TCP/IP stack bypass for loopback connections
From: Eric Dumazet @ 2012-09-20 11:51 UTC (permalink / raw)
To: sclark46; +Cc: Bruce Curtis, David Miller, edumazet, netdev
In-Reply-To: <505AFDE9.4080602@earthlink.net>
On Thu, 2012-09-20 at 07:28 -0400, Stephen Clark wrote:
>
> Does this mean traffic on the loopback interface will not traverse
> netfilter?
>
Yes this was already mentioned.
Only the SYN / SYNACK messages will
All data will bypass IP stack, qdisc (if any), loopback driver, and
netfilter.
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Johannes Berg @ 2012-09-20 12:35 UTC (permalink / raw)
To: artem.bityutskiy; +Cc: Eric Dumazet, linux-wireless, netdev
In-Reply-To: <1348142775.2388.10.camel@sauron.fi.intel.com>
Hi,
> > 56138f5 iwlwifi: dont pull too much payload in skb head
> > 3edaf3e mac80211: manage AP netdev carrier state
>
> The second patch (AP carrier state) actually exposed a connman issue
> which I fixed and submitted a connman patch:
> http://lists.connman.net/pipermail/connman/2012-September/011232.html
>
> However, Eric's patch still causes tethering problems to me.
Let me recap a bit. Artem is using connman, which sets up the wifi
interface as part of a bridge. It runs wpa_supplicant to create an AP
(only AP and mesh mode interfaces can be bridged anyway).
Eric, you said:
> I would say some part of the stack assumes a header (I dont know wich
> one ?) is pulled in skb->head/data, and thats a bug.
>
> Always use pskb_may_pull(skb, XXX) to make sure you can access XXX
> bytes in skb->data
I thought we'd figure out which part of the stack assumes a header, so I
asked Artem to test a one-line patch which adds "skb_linearize()" before
"netif_receive_skb()" in mac80211. This makes it work, but I'm not sure
where after that the bad assumption might be.
johannes
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 12:40 UTC (permalink / raw)
To: Johannes Berg
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1348144524.4161.26.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
OK, but which netif_receive_skb(), as I count 5 occurrences in
net/mac80211/rx.c ?
Instead of skb_linearize() calls
you could try several values of XXX in
pskb_may_pull(skb, XXX)
So that you make sure XXX bytes are available in skb->head, and not
the whole frame.
One you know the limit for XXX, it might give a clue where a
pskb_may_pull(skb, XXX) is missing.
On Thu, Sep 20, 2012 at 2:35 PM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> Hi,
>
>> > 56138f5 iwlwifi: dont pull too much payload in skb head
>> > 3edaf3e mac80211: manage AP netdev carrier state
>>
>> The second patch (AP carrier state) actually exposed a connman issue
>> which I fixed and submitted a connman patch:
>> http://lists.connman.net/pipermail/connman/2012-September/011232.html
>>
>> However, Eric's patch still causes tethering problems to me.
>
>
> Let me recap a bit. Artem is using connman, which sets up the wifi
> interface as part of a bridge. It runs wpa_supplicant to create an AP
> (only AP and mesh mode interfaces can be bridged anyway).
>
>
> Eric, you said:
>
>> I would say some part of the stack assumes a header (I dont know wich
>> one ?) is pulled in skb->head/data, and thats a bug.
>>
>> Always use pskb_may_pull(skb, XXX) to make sure you can access XXX
>> bytes in skb->data
>
> I thought we'd figure out which part of the stack assumes a header, so I
> asked Artem to test a one-line patch which adds "skb_linearize()" before
> "netif_receive_skb()" in mac80211. This makes it work, but I'm not sure
> where after that the bad assumption might be.
>
> johannes
>
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 12:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: artem.bityutskiy, linux-wireless, netdev
In-Reply-To: <CANn89iJkXrZPB14KU8xA-Dn8_n=H3J4-R60BTZFV+STF9_ASdA@mail.gmail.com>
I guess you only need to make sure 14 bytes of ethernet header are
available before eth_type_trans(skb, dev);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 61c621e..ffe5f84 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1795,9 +1795,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
if (skb) {
/* deliver to local stack */
- skb->protocol = eth_type_trans(skb, dev);
- memset(skb->cb, 0, sizeof(skb->cb));
- netif_receive_skb(skb);
+ if (pskb_may_pull(skb, sizeof(struct ethhdr))) {
+ skb->protocol = eth_type_trans(skb, dev);
+ memset(skb->cb, 0, sizeof(skb->cb));
+ netif_receive_skb(skb);
+ } else {
+ kfree_skb(skb);
+ }
}
}
On Thu, Sep 20, 2012 at 2:40 PM, Eric Dumazet <edumazet@google.com> wrote:
> OK, but which netif_receive_skb(), as I count 5 occurrences in
> net/mac80211/rx.c ?
>
> Instead of skb_linearize() calls
>
> you could try several values of XXX in
>
> pskb_may_pull(skb, XXX)
>
> So that you make sure XXX bytes are available in skb->head, and not
> the whole frame.
>
> One you know the limit for XXX, it might give a clue where a
> pskb_may_pull(skb, XXX) is missing.
>
> On Thu, Sep 20, 2012 at 2:35 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> Hi,
>>
>>> > 56138f5 iwlwifi: dont pull too much payload in skb head
>>> > 3edaf3e mac80211: manage AP netdev carrier state
>>>
>>> The second patch (AP carrier state) actually exposed a connman issue
>>> which I fixed and submitted a connman patch:
>>> http://lists.connman.net/pipermail/connman/2012-September/011232.html
>>>
>>> However, Eric's patch still causes tethering problems to me.
>>
>>
>> Let me recap a bit. Artem is using connman, which sets up the wifi
>> interface as part of a bridge. It runs wpa_supplicant to create an AP
>> (only AP and mesh mode interfaces can be bridged anyway).
>>
>>
>> Eric, you said:
>>
>>> I would say some part of the stack assumes a header (I dont know wich
>>> one ?) is pulled in skb->head/data, and thats a bug.
>>>
>>> Always use pskb_may_pull(skb, XXX) to make sure you can access XXX
>>> bytes in skb->data
>>
>> I thought we'd figure out which part of the stack assumes a header, so I
>> asked Artem to test a one-line patch which adds "skb_linearize()" before
>> "netif_receive_skb()" in mac80211. This makes it work, but I'm not sure
>> where after that the bad assumption might be.
>>
>> johannes
>>
^ permalink raw reply related
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 12:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: artem.bityutskiy, linux-wireless, netdev
In-Reply-To: <CANn89iKStHAwVZtpgQMzEpByGYG2FKpjSQsJFT-9qQmjw+KJ8g@mail.gmail.com>
Or its the lines with CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS ?
What arch is it ?
On Thu, Sep 20, 2012 at 2:45 PM, Eric Dumazet <edumazet@google.com> wrote:
> I guess you only need to make sure 14 bytes of ethernet header are
> available before eth_type_trans(skb, dev);
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 61c621e..ffe5f84 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1795,9 +1795,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
>
> if (skb) {
> /* deliver to local stack */
> - skb->protocol = eth_type_trans(skb, dev);
> - memset(skb->cb, 0, sizeof(skb->cb));
> - netif_receive_skb(skb);
> + if (pskb_may_pull(skb, sizeof(struct ethhdr))) {
> + skb->protocol = eth_type_trans(skb, dev);
> + memset(skb->cb, 0, sizeof(skb->cb));
> + netif_receive_skb(skb);
> + } else {
> + kfree_skb(skb);
> + }
> }
> }
>
>
> On Thu, Sep 20, 2012 at 2:40 PM, Eric Dumazet <edumazet@google.com> wrote:
>> OK, but which netif_receive_skb(), as I count 5 occurrences in
>> net/mac80211/rx.c ?
>>
>> Instead of skb_linearize() calls
>>
>> you could try several values of XXX in
>>
>> pskb_may_pull(skb, XXX)
>>
>> So that you make sure XXX bytes are available in skb->head, and not
>> the whole frame.
>>
>> One you know the limit for XXX, it might give a clue where a
>> pskb_may_pull(skb, XXX) is missing.
>>
>> On Thu, Sep 20, 2012 at 2:35 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>> Hi,
>>>
>>>> > 56138f5 iwlwifi: dont pull too much payload in skb head
>>>> > 3edaf3e mac80211: manage AP netdev carrier state
>>>>
>>>> The second patch (AP carrier state) actually exposed a connman issue
>>>> which I fixed and submitted a connman patch:
>>>> http://lists.connman.net/pipermail/connman/2012-September/011232.html
>>>>
>>>> However, Eric's patch still causes tethering problems to me.
>>>
>>>
>>> Let me recap a bit. Artem is using connman, which sets up the wifi
>>> interface as part of a bridge. It runs wpa_supplicant to create an AP
>>> (only AP and mesh mode interfaces can be bridged anyway).
>>>
>>>
>>> Eric, you said:
>>>
>>>> I would say some part of the stack assumes a header (I dont know wich
>>>> one ?) is pulled in skb->head/data, and thats a bug.
>>>>
>>>> Always use pskb_may_pull(skb, XXX) to make sure you can access XXX
>>>> bytes in skb->data
>>>
>>> I thought we'd figure out which part of the stack assumes a header, so I
>>> asked Artem to test a one-line patch which adds "skb_linearize()" before
>>> "netif_receive_skb()" in mac80211. This makes it work, but I'm not sure
>>> where after that the bad assumption might be.
>>>
>>> johannes
>>>
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Johannes Berg @ 2012-09-20 12:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <CANn89iJkXrZPB14KU8xA-Dn8_n=H3J4-R60BTZFV+STF9_ASdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2012-09-20 at 14:40 +0200, Eric Dumazet wrote:
> OK, but which netif_receive_skb(), as I count 5 occurrences in
> net/mac80211/rx.c ?
The one you modified in the other email :-)
> Instead of skb_linearize() calls
>
> you could try several values of XXX in
>
> pskb_may_pull(skb, XXX)
>
> So that you make sure XXX bytes are available in skb->head, and not
> the whole frame.
>
> One you know the limit for XXX, it might give a clue where a
> pskb_may_pull(skb, XXX) is missing.
Good idea.
johannes
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Johannes Berg @ 2012-09-20 12:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: artem.bityutskiy, linux-wireless, netdev
In-Reply-To: <CANn89iKStHAwVZtpgQMzEpByGYG2FKpjSQsJFT-9qQmjw+KJ8g@mail.gmail.com>
On Thu, 2012-09-20 at 14:45 +0200, Eric Dumazet wrote:
> I guess you only need to make sure 14 bytes of ethernet header are
> available before eth_type_trans(skb, dev);
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 61c621e..ffe5f84 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1795,9 +1795,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
>
> if (skb) {
> /* deliver to local stack */
> - skb->protocol = eth_type_trans(skb, dev);
> - memset(skb->cb, 0, sizeof(skb->cb));
> - netif_receive_skb(skb);
> + if (pskb_may_pull(skb, sizeof(struct ethhdr))) {
> + skb->protocol = eth_type_trans(skb, dev);
> + memset(skb->cb, 0, sizeof(skb->cb));
> + netif_receive_skb(skb);
> + } else {
> + kfree_skb(skb);
> + }
> }
> }
Yeah I was looking at the same code just now. However, we had actually
inserted the skb_linearize() *after* eth_type_trans(), so I'm confused.
Maybe it still works, more or less by accident?
johannes
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 12:48 UTC (permalink / raw)
To: Johannes Berg
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1348145269.4161.28.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
Or its a buggy protocol ?
IP/UDP/TCP definitely works, but maybe another protocol assumes its
header is in skb->head
On Thu, Sep 20, 2012 at 2:47 PM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Thu, 2012-09-20 at 14:45 +0200, Eric Dumazet wrote:
>> I guess you only need to make sure 14 bytes of ethernet header are
>> available before eth_type_trans(skb, dev);
>>
>> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
>> index 61c621e..ffe5f84 100644
>> --- a/net/mac80211/rx.c
>> +++ b/net/mac80211/rx.c
>> @@ -1795,9 +1795,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
>>
>> if (skb) {
>> /* deliver to local stack */
>> - skb->protocol = eth_type_trans(skb, dev);
>> - memset(skb->cb, 0, sizeof(skb->cb));
>> - netif_receive_skb(skb);
>> + if (pskb_may_pull(skb, sizeof(struct ethhdr))) {
>> + skb->protocol = eth_type_trans(skb, dev);
>> + memset(skb->cb, 0, sizeof(skb->cb));
>> + netif_receive_skb(skb);
>> + } else {
>> + kfree_skb(skb);
>> + }
>> }
>> }
>
> Yeah I was looking at the same code just now. However, we had actually
> inserted the skb_linearize() *after* eth_type_trans(), so I'm confused.
> Maybe it still works, more or less by accident?
>
> johannes
>
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Johannes Berg @ 2012-09-20 12:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: artem.bityutskiy, linux-wireless, netdev
In-Reply-To: <CANn89iLksBMJ=Ep+VcPSAOPzqst70hk8hR5=mGte2vSx=49zUA@mail.gmail.com>
On Thu, 2012-09-20 at 14:48 +0200, Eric Dumazet wrote:
> Or its a buggy protocol ?
>
> IP/UDP/TCP definitely works, but maybe another protocol assumes its
> header is in skb->head
It could be, I think it failed either on EAPOL (which is just userspace
registering a protocol socket) or DHCP (same?)
johannes
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Johannes Berg @ 2012-09-20 12:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <CANn89iLnv2kWLd_hTpMXjMJ=r+hOvb2q2Oy6L-s5+6SzqxYvjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2012-09-20 at 14:46 +0200, Eric Dumazet wrote:
> Or its the lines with CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS ?
>
> What arch is it ?
x86
johannes
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Johannes Berg @ 2012-09-20 12:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: artem.bityutskiy, linux-wireless, netdev
In-Reply-To: <1348145269.4161.28.camel@jlt4.sipsolutions.net>
On Thu, 2012-09-20 at 14:47 +0200, Johannes Berg wrote:
> > if (skb) {
> > /* deliver to local stack */
> > - skb->protocol = eth_type_trans(skb, dev);
> > - memset(skb->cb, 0, sizeof(skb->cb));
> > - netif_receive_skb(skb);
> > + if (pskb_may_pull(skb, sizeof(struct ethhdr))) {
> > + skb->protocol = eth_type_trans(skb, dev);
> > + memset(skb->cb, 0, sizeof(skb->cb));
> > + netif_receive_skb(skb);
> > + } else {
> > + kfree_skb(skb);
> > + }
> > }
> > }
>
> Yeah I was looking at the same code just now. However, we had actually
> inserted the skb_linearize() *after* eth_type_trans(), so I'm confused.
Ok actually, by the time we get here the ethernet header must be in the
skb head because we construct it from the 802.11 and llc/snap header.
johannes
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 12:51 UTC (permalink / raw)
To: Johannes Berg
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1348145450.4161.31.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
So its using a RAW socket ?
On Thu, Sep 20, 2012 at 2:50 PM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Thu, 2012-09-20 at 14:48 +0200, Eric Dumazet wrote:
>> Or its a buggy protocol ?
>>
>> IP/UDP/TCP definitely works, but maybe another protocol assumes its
>> header is in skb->head
>
> It could be, I think it failed either on EAPOL (which is just userspace
> registering a protocol socket) or DHCP (same?)
>
> johannes
>
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Johannes Berg @ 2012-09-20 12:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <CANn89iLudX29yU8ziNyN+8gN3b2L55L9m5p6ob_wnfZ3fp_TDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2012-09-20 at 14:51 +0200, Eric Dumazet wrote:
> So its using a RAW socket ?
Yes:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_EAPOL))
johannes
> On Thu, Sep 20, 2012 at 2:50 PM, Johannes Berg
> <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> > On Thu, 2012-09-20 at 14:48 +0200, Eric Dumazet wrote:
> >> Or its a buggy protocol ?
> >>
> >> IP/UDP/TCP definitely works, but maybe another protocol assumes its
> >> header is in skb->head
> >
> > It could be, I think it failed either on EAPOL (which is just userspace
> > registering a protocol socket) or DHCP (same?)
> >
> > johannes
> >
>
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Artem Bityutskiy @ 2012-09-20 12:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <CANn89iKStHAwVZtpgQMzEpByGYG2FKpjSQsJFT-9qQmjw+KJ8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
On Thu, 2012-09-20 at 14:45 +0200, Eric Dumazet wrote:
> I guess you only need to make sure 14 bytes of ethernet header are
> available before eth_type_trans(skb, dev);
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 61c621e..ffe5f84 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1795,9 +1795,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
>
> if (skb) {
> /* deliver to local stack */
> - skb->protocol = eth_type_trans(skb, dev);
> - memset(skb->cb, 0, sizeof(skb->cb));
> - netif_receive_skb(skb);
> + if (pskb_may_pull(skb, sizeof(struct ethhdr))) {
> + skb->protocol = eth_type_trans(skb, dev);
> + memset(skb->cb, 0, sizeof(skb->cb));
> + netif_receive_skb(skb);
> + } else {
> + kfree_skb(skb);
> + }
> }
> }
Does not help, this one does:
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 61c621e..6888586 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1797,6 +1797,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
/* deliver to local stack */
skb->protocol = eth_type_trans(skb, dev);
memset(skb->cb, 0, sizeof(skb->cb));
+ skb_linearize(skb);
netif_receive_skb(skb);
}
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 0/9] net/macb: driver enhancement concerning GEM support, ring logic and cleanup
From: Nicolas Ferre @ 2012-09-20 13:03 UTC (permalink / raw)
To: David Miller
Cc: netdev, havard, bhutchings, linux-arm-kernel, plagnioj,
patrice.vilchez, linux-kernel
In-Reply-To: <20120919.135006.394934820049386022.davem@davemloft.net>
On 09/19/2012 07:50 PM, David Miller :
> From: Nicolas Ferre <nicolas.ferre@atmel.com>
> Date: Wed, 19 Sep 2012 13:55:13 +0200
>
>> This is an enhancement work that began several years ago. I try to catchup with
>> some performance improvement that has been implemented then by Havard.
>> The ring index logic and the TX error path modification are the biggest changes
>> but some cleanup/debugging have been added along the way.
>> The GEM revision will benefit from the Gigabit support.
>>
>> The series has been tested on several Atmel AT91 SoC with the two MACB/GEM
>> flavors.
>>
>> v2: - modify the tx error handling: now uses a workqueue
>> - information provided by ethtool -i were not accurate: removed
>
> Don't submit patches like this.
>
> When you put an RFC right in the middle of the series, it screws everything
> up.
>
> It means that I can't only apply the parts that are not RFC.
I will submit a v3 patch series when I am more confident about the patch
that I have tagged as RFC...
And as you noted last time that I have included a modified patch in a
series:
"Please, when you receive feedback on your patches, you need to
resubmit the whole patch series for review not just the patches where
changes were asked for."
==> I thought that it was a better idea to post the whole patch series
so that people could figure out the context. As the TX error path is
greatly modified, it could make senses.
Now, is it possible to review this series as it is or should I repost
patches? attached to the previous thread? RFC patch alone?
puzzled,
--
Nicolas Ferre
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 13:04 UTC (permalink / raw)
To: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA
Cc: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1348145936.2388.18.camel-Bxnoe/o8FG+Ef9UqXRslZEEOCMrvLtNR@public.gmane.org>
Try to pull 40 bytes : Thats OK for tcp performance, because 40 bytes
is the minimum size of IP+TCP headers
pskb_may_pull(skb, 40);
(instead of your skb_linearize(skb);)
On Thu, Sep 20, 2012 at 2:58 PM, Artem Bityutskiy
<artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> On Thu, 2012-09-20 at 14:45 +0200, Eric Dumazet wrote:
>> I guess you only need to make sure 14 bytes of ethernet header are
>> available before eth_type_trans(skb, dev);
>>
>> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
>> index 61c621e..ffe5f84 100644
>> --- a/net/mac80211/rx.c
>> +++ b/net/mac80211/rx.c
>> @@ -1795,9 +1795,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
>>
>> if (skb) {
>> /* deliver to local stack */
>> - skb->protocol = eth_type_trans(skb, dev);
>> - memset(skb->cb, 0, sizeof(skb->cb));
>> - netif_receive_skb(skb);
>> + if (pskb_may_pull(skb, sizeof(struct ethhdr))) {
>> + skb->protocol = eth_type_trans(skb, dev);
>> + memset(skb->cb, 0, sizeof(skb->cb));
>> + netif_receive_skb(skb);
>> + } else {
>> + kfree_skb(skb);
>> + }
>> }
>> }
>
> Does not help, this one does:
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 61c621e..6888586 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1797,6 +1797,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
> /* deliver to local stack */
> skb->protocol = eth_type_trans(skb, dev);
> memset(skb->cb, 0, sizeof(skb->cb));
> + skb_linearize(skb);
> netif_receive_skb(skb);
> }
>
> --
> Best Regards,
> Artem Bityutskiy
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 13:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA, Johannes Berg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <CANn89i+9Th=xVgDgoy7tHwKtLNpOC8rgJkA09nQ1Yf0zvqBw6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2012-09-20 at 15:04 +0200, Eric Dumazet wrote:
> Try to pull 40 bytes : Thats OK for tcp performance, because 40 bytes
> is the minimum size of IP+TCP headers
>
> pskb_may_pull(skb, 40);
>
> (instead of your skb_linearize(skb);)
Oh well, I just realize all these mails were on netdev.
Sorry for the noise.
--
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
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Artem Bityutskiy @ 2012-09-20 13:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Johannes Berg, linux-wireless, netdev
In-Reply-To: <CANn89i+9Th=xVgDgoy7tHwKtLNpOC8rgJkA09nQ1Yf0zvqBw6w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
On Thu, 2012-09-20 at 15:04 +0200, Eric Dumazet wrote:
> Try to pull 40 bytes : Thats OK for tcp performance, because 40 bytes
> is the minimum size of IP+TCP headers
>
> pskb_may_pull(skb, 40);
OK, I've tried almost this (see below) and it solves my issue:
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 965e6ec..7f079d0 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1798,9 +1798,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
if (skb) {
/* deliver to local stack */
- skb->protocol = eth_type_trans(skb, dev);
- memset(skb->cb, 0, sizeof(skb->cb));
- netif_receive_skb(skb);
+ if (pskb_may_pull(skb, 40)) {
+ skb->protocol = eth_type_trans(skb, dev);
+ memset(skb->cb, 0, sizeof(skb->cb));
+ netif_receive_skb(skb);
+ } else {
+ kfree_skb(skb);
+ }
}
}
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 13:22 UTC (permalink / raw)
To: artem.bityutskiy; +Cc: Eric Dumazet, Johannes Berg, linux-wireless, netdev
In-Reply-To: <1348147353.2388.19.camel@sauron.fi.intel.com>
On Thu, 2012-09-20 at 16:22 +0300, Artem Bityutskiy wrote:
>
> OK, I've tried almost this (see below) and it solves my issue:
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 965e6ec..7f079d0 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1798,9 +1798,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
>
> if (skb) {
> /* deliver to local stack */
> - skb->protocol = eth_type_trans(skb, dev);
> - memset(skb->cb, 0, sizeof(skb->cb));
> - netif_receive_skb(skb);
> + if (pskb_may_pull(skb, 40)) {
> + skb->protocol = eth_type_trans(skb, dev);
> + memset(skb->cb, 0, sizeof(skb->cb));
> + netif_receive_skb(skb);
> + } else {
> + kfree_skb(skb);
> + }
> }
> }
>
OK but you cant do that, or small frames will be dropped.
Anyway its a hack, we should find the buggy layer.
You could use dropwatch (drop_monitor) to check where frame is dropped.
modprobe drop_monitor
dropwatch -l kas
^ permalink raw reply
* Equal bandwidth for all users - Per Connection Queue (PCQ) on Linux ?
From: valent.turkovic @ 2012-09-20 13:22 UTC (permalink / raw)
To: netdev
Hi all,
is ther any way that would allow to dynamically distribute bandwidth
per conneted client?
For example if maximum bandiwdth available is 10/10 MBits/s and only
two clients are connected then they both get 1/2 (5/5 Mbits), and when
there are 10 clients connected and using the connection, each gets
1/10 (1/1 Mbit).
I haven't yet seen any qos technique on linux that allows this, but my
quess is that some linux networking guru has this figured out.
Mikrorik (linux based embedded OS specialized for networking) has qos
type called PCQ [1] that dynamically spreads bandwidth just as
explained.
[1] http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ_Examples
--
follow me - www.twitter.com/valentt & http://kernelreloaded.blog385.com
linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic@hotmail.com
^ permalink raw reply
* Re: mlx4: dropping multicast packets at promisc leave
From: Or Gerlitz @ 2012-09-20 13:21 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev, Yevgeny Petrilin, Amir Vadai
In-Reply-To: <505A66CC.8010701@redhat.com>
On 20/09/2012 03:43, Marcelo Ricardo Leitner wrote:
> I have a report that our mlx4 driver (RHEL 6.3) is dropping multicast
> packets when NIC leaves promisc mode. It seems this is being cause due
> to the new steering mode that took place near by commit
> 1679200f91da6a054b06954c9bd3eeed29b6731f. As it seems, the new
> steering mode needs more commands/time to leave the promisc mode,
> which may be leading to packet drops.
Marcelo,
The commit you point on below 6d19993 "net/mlx4_en: Re-design multicast
attachments flow" makes sure to avoid
doing extra firmware comments and not leave a window in time where
"correct" addresses are not attached. Its hard to say what's the case on
that RHEL 6.3 system, it would be very helpful through if you manage to
reproduce the problem on an upstream kernel -- BTW you didn't say on
which kernel you are trying to reproduce this, note that upstream has
also commit 60d31c1475f2 "net/mlx4_core: Looking for promiscuous entries
on the correct port" (reported by you...) , so if somehow this commit
makes the diff you could use it also on their system.
> It takes 300ms to perform the change there against my 600us. Hitting
> something like tcpdump -c 10 in a loop helps triggering it.
Do you have any insight for this huge difference?
Or.
^ permalink raw reply
* Re: mlx4_en: fix endianness with blue frame support
From: Or Gerlitz @ 2012-09-20 13:46 UTC (permalink / raw)
To: Dan Carpenter; +Cc: cascardo, netdev, Yevgeny Petrilin, Eli Cohen
In-Reply-To: <20120918073448.GA32445@elgon.mountain>
On Tue, Sep 18, 2012 at 10:34 AM, Dan Carpenter
<dan.carpenter@oracle.com> wrote:
> Hello Thadeu Lima de Souza Cascardo,
>
> The patch c5d6136e10d6: "mlx4_en: fix endianness with blue frame
> support" from Oct 10, 2011, leads to the following warning:
> drivers/net/ethernet/mellanox/mlx4/en_tx.c:720 mlx4_en_xmit()
> warn: potential memory corrupting cast. 4 vs 2 bytes
>
> That patch introduced a call to cpu_to_be32() and added some endian notation.
> *(__be32 *) (&tx_desc->ctrl.vlan_tag) |= cpu_to_be32(ring->doorbell_qpn);
> But it doesn't make sense because the data type is declared as u16 in
> the header and we would be corrupting the next elements in the struct
> which are ins_vlan and fence_size.
>
> struct mlx4_wqe_ctrl_seg {
> __be32 owner_opcode;
> __be16 vlan_tag;
> u8 ins_vlan;
> u8 fence_size;
>
> I guess the reason we get away with it is that the ->doorbell_qpn is
> normally less that 65k. But doorbell_qpn is a u32 type so I think there is a risk here.
Dan,
QP numbers are 24 bit in size, under blue-flame setting the QP number
is written
over the "vlan_tag" field and potentially also the "ins_vlan" field of
the control segment,
we can do a little cleanup here with introducing a modified version of
the mlx4_wqe_ctrl_seg
structure over which the cast is made under the blue-flame flow.
Or.
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: Eric Dumazet @ 2012-09-20 14:25 UTC (permalink / raw)
To: artem.bityutskiy; +Cc: Eric Dumazet, Johannes Berg, linux-wireless, netdev
In-Reply-To: <1348147353.2388.19.camel@sauron.fi.intel.com>
On Thu, 2012-09-20 at 16:22 +0300, Artem Bityutskiy wrote:
> On Thu, 2012-09-20 at 15:04 +0200, Eric Dumazet wrote:
> > Try to pull 40 bytes : Thats OK for tcp performance, because 40 bytes
> > is the minimum size of IP+TCP headers
> >
> > pskb_may_pull(skb, 40);
>
> OK, I've tried almost this (see below) and it solves my issue:
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 965e6ec..7f079d0 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1798,9 +1798,13 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
>
> if (skb) {
> /* deliver to local stack */
> - skb->protocol = eth_type_trans(skb, dev);
> - memset(skb->cb, 0, sizeof(skb->cb));
> - netif_receive_skb(skb);
> + if (pskb_may_pull(skb, 40)) {
> + skb->protocol = eth_type_trans(skb, dev);
> + memset(skb->cb, 0, sizeof(skb->cb));
> + netif_receive_skb(skb);
> + } else {
> + kfree_skb(skb);
> + }
> }
> }
>
Please remove this hack and try the following bugfix in raw handler
icmp_filter() should not modify skb, or else its caller should not
assume ip_hdr() is unchanged.
net/ipv4/raw.c | 29 +++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index f242578..3fa8c96 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -128,25 +128,30 @@ found:
}
/*
- * 0 - deliver
- * 1 - block
+ * false - deliver
+ * true - block
*/
-static __inline__ int icmp_filter(struct sock *sk, struct sk_buff *skb)
+static bool icmp_filter(struct sock *sk, const struct sk_buff *skb)
{
- int type;
-
- if (!pskb_may_pull(skb, sizeof(struct icmphdr)))
- return 1;
-
- type = icmp_hdr(skb)->type;
- if (type < 32) {
+ __u8 _type;
+ const __u8 *type;
+
+ type = skb_header_pointer(skb,
+ skb_transport_offset(skb) +
+ offsetof(struct icmphdr, type),
+ sizeof(_type),
+ &_type);
+ if (!type)
+ return true;
+
+ if (*type < 32) {
__u32 data = raw_sk(sk)->filter.data;
- return ((1 << type) & data) != 0;
+ return ((1U << *type) & data) != 0;
}
/* Do not block unknown ICMP types */
- return 0;
+ return false;
}
/* IP input processing comes here for RAW socket delivery.
^ permalink raw reply related
* Re: mlx4: dropping multicast packets at promisc leave
From: Marcelo Ricardo Leitner @ 2012-09-20 15:04 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev, Yevgeny Petrilin, Amir Vadai
In-Reply-To: <505B1874.3040904@mellanox.com>
On 09/20/2012 10:21 AM, Or Gerlitz wrote:
> On 20/09/2012 03:43, Marcelo Ricardo Leitner wrote:
>> I have a report that our mlx4 driver (RHEL 6.3) is dropping multicast
>> packets when NIC leaves promisc mode. It seems this is being cause due
>> to the new steering mode that took place near by commit
>> 1679200f91da6a054b06954c9bd3eeed29b6731f. As it seems, the new
>> steering mode needs more commands/time to leave the promisc mode,
>> which may be leading to packet drops.
>
> Marcelo,
>
> The commit you point on below 6d19993 "net/mlx4_en: Re-design multicast
> attachments flow" makes sure to avoid
> doing extra firmware comments and not leave a window in time where
> "correct" addresses are not attached. Its hard to say what's the case on
> that RHEL 6.3 system, it would be very helpful through if you manage to
> reproduce the problem on an upstream kernel -- BTW you didn't say on
Okay, I understand that the commit prevents a window. I may be missing
something, but isn't there another one in there? Between:
mlx4_SET_MCAST_FLTR MLX4_MCAST_DISABLE and
mlx4_SET_MCAST_FLTR MLX4_MCAST_ENABLE
because mlx4_multicast_promisc_remove() was called just before those.
Otherwise I don't how is the NIC would be receiving multicast packets in
there.
I understand the difficulty about the kernel version, I am sorry for
that. As I'm unable to reproduce the issue by myself, I couldn't run a
test in a plain upstream kernel so far or experiment much.
I was holding this email: I just access to a server that seems to
reproduce the issue. It has a MT27500 ConnectX-3 NIC. Only tried our
RHEL 6.3 stock so far. Keep you posted on further tests!
This was the result of ifconfig mlx4_2 -promisc:
[ 3] 34.0-35.0 sec 61.7 MBytes 517 Mbits/sec 0.024 ms 274/43502
(0.63%)
[ 3] 34.0-35.0 sec 756 datagrams received out-of-order
> which kernel you are trying to reproduce this, note that upstream has
> also commit 60d31c1475f2 "net/mlx4_core: Looking for promiscuous entries
> on the correct port" (reported by you...) , so if somehow this commit
> makes the diff you could use it also on their system.
Sorry, that would be 2.6.32-279.el6. It has additional commits up to
somewhere near commit
58a3de0 - mlx4_core: fix race on comm channel
but maybe not all before that one. Can't tell you for sure.
And then I tried 3 additional patches applied at once:
- 60d31c1475f2 "net/mlx4_core: Looking for promiscuous entries on the
correct port"
- f1f75f0 - mlx4: attach multicast with correct flag
- Yes, this one wasn't in 2.6.32-279.el6.
- 6d19993 - net/mlx4_en: Re-design multicast attachments flow
And they still reported drops.
>> It takes 300ms to perform the change there against my 600us. Hitting
>> something like tcpdump -c 10 in a loop helps triggering it.
>
> Do you have any insight for this huge difference?
No idea. Couldn't track it yet.
Thanks,
Marcelo.
^ permalink raw reply
* [PATCH net] bnx2x: remove false warning regarding interrupt number
From: Ariel Elior @ 2012-09-20 15:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eilon Greenstein, Ariel Elior
Since version 7.4 the FW configures in the pci config space the max
number of interrupts available to the physical function, instead of
the exact number to use.
This causes a false warning in driver when comparing the number of
configured interrupts to the number about to be used.
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 211753e..0875ecf 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9831,12 +9831,13 @@ static void __devinit bnx2x_get_igu_cam_info(struct bnx2x *bp)
}
#ifdef CONFIG_PCI_MSI
- /*
- * It's expected that number of CAM entries for this functions is equal
- * to the number evaluated based on the MSI-X table size. We want a
- * harsh warning if these values are different!
+ /* Due to new PF resource allocation by MFW T7.4 and above, it's
+ * optional that number of CAM entries will not be equal to the value
+ * advertised in PCI.
+ * Driver should use the minimal value of both as the actual status
+ * block count
*/
- WARN_ON(bp->igu_sb_cnt != igu_sb_cnt);
+ bp->igu_sb_cnt = min_t(int, bp->igu_sb_cnt, igu_sb_cnt);
#endif
if (igu_sb_cnt == 0)
--
1.7.9.GIT
^ permalink raw reply related
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