* [PATCH net 0/7] be2net: Bug fixes
From: Ajit Khaparde @ 2013-09-27 20:16 UTC (permalink / raw)
To: netdev
Series of 7 patches against net tree.
Please apply.
Thanks
-Ajit
[1/7] be2net: Fix to prevent Tx stall on SH-R when packet size < 32
[2/7] be2net: Fix the size of be_nic_res_desc structure
[3/7] be2net: Fix VLAN promiscuous mode programming
[4/7] be2net: Fix number of VLANs supported in UMC mode for BE3-R.
[5/7] be2net: Fix to allow VLAN configuration on VF interfaces.
[6/7] be2net: Fix to configure VLAN priority for a VF interface.
[7/7] be2net: Fix to display the VLAN priority for a VF
^ permalink raw reply
* Re: question about map_read_chunks()
From: J. Bruce Fields @ 2013-09-27 20:15 UTC (permalink / raw)
To: Tom Tucker
Cc: Dan Carpenter, Tom Tucker, J. Bruce Fields,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5245A2DE.9020307-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
On Fri, Sep 27, 2013 at 10:23:10AM -0500, Tom Tucker wrote:
> Hi Dan,
>
> On 9/27/13 7:21 AM, Dan Carpenter wrote:
> >I have looked at this again, and I still worry that it looks like a bug.
> >(remote security related blah blah blah).
> >
> >regards,
> >dan carpenter
> >
> >On Mon, Feb 20, 2012 at 12:50:19PM +0300, Dan Carpenter wrote:
> >>I had a couple questions about some map_read_chunks().
> >>
> >>net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> >>
> >> 150 ch_bytes = ntohl(ch->rc_target.rs_length);
> >> ^^^^^^^^
> >>It look like this is 32 bits from the network?
> >>
> >> 151 head->arg.head[0] = rqstp->rq_arg.head[0];
> >> 152 head->arg.tail[0] = rqstp->rq_arg.tail[0];
> >> 153 head->arg.pages = &head->pages[head->count];
> >> 154 head->hdr_count = head->count; /* save count of hdr pages */
> >> 155 head->arg.page_base = 0;
> >> 156 head->arg.page_len = ch_bytes;
> >> 157 head->arg.len = rqstp->rq_arg.len + ch_bytes;
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>Can overflow.
> >> 158 head->arg.buflen = rqstp->rq_arg.buflen + ch_bytes;
> agreed.
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>Same. I didn't follow it through to see if an overflow matters. Does
> >>it?
> >>
> >> 159 head->count++;
> >> 160 chl_map->ch[0].start = 0;
> >> 161 while (byte_count) {
> >> 162 rpl_map->sge[sge_no].iov_base =
> >> 163 page_address(rqstp->rq_arg.pages[page_no]) + page_off;
> >> 164 sge_bytes = min_t(int, PAGE_SIZE-page_off, ch_bytes);
> >> ^^^
> >>This is the wrong cast to use. A large ch_bytes would be counted as a
> >>negative value and get around the cap here.
> True, but if we validate the wire data like we should, that's
> probably not an issue.
Well, my last attempt to do rdma nfs io resulted in an instant server
reboot, so I can take a look at this but it may be the least of our
problems....
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-09-27 20:14 UTC (permalink / raw)
To: netdev; +Cc: edumazet
Hi,
PMTU discovery over IPv6 has been flaky for me for a while, but at some point
between 3.10 and 3.11, it broke for me completely. Just checked with
3.12.0-rc2 and the problem is still there.
First, a look at my routing table, which is slightly unusual due to tunnels
and BGP being involved:
pannekake:~> sudo ip -6 route
2001:500:72::/48 via 2001:67c:29f4::1 dev eth0 proto zebra metric 1024
2001:67c:a4::/48 via fe80::230:48ff:fe55:5743 dev eth0 proto zebra metric 100
2001:67c:29f4::/64 dev eth0 proto kernel metric 256
2001:67c:29f4:1::/64 via fe80::230:48ff:fe55:5743 dev eth0 proto zebra metric 100
2001:67c:29f4:1000::/64 via fe80::230:48ff:fe55:5743 dev eth0 proto zebra metric 100
2001:67c:29f4:1001::/64 via fe80::230:48ff:fe55:5743 dev eth0 proto zebra metric 100
2001:67c:29f4:1003::/64 via fe80::230:48ff:fe55:5743 dev eth0 proto zebra metric 100
2001:67c:29f4:1005::/64 via fe80::230:48ff:fe55:5743 dev eth0 proto zebra metric 100
2001:67c:29f4:1007::/64 via fe80::230:48ff:fe55:5743 dev eth0 proto zebra metric 100
2001:67c:29f4::/48 via 2001:67c:29f4::1 dev eth0 proto zebra metric 1024
2001:700::/32 via 2001:67c:29f4::1 dev eth0 proto zebra metric 1024
2a02:2368::/32 via 2001:67c:29f4::1 dev eth0 proto zebra metric 1024
fe80::c30b:9a61 dev k_sessesveits proto kernel metric 256
fe80::c30b:9a61 dev k_wikene proto kernel metric 256
fe80::c30b:9a61 dev k_trygve proto kernel metric 256
fe80::c30b:9a61 dev k_magne proto kernel metric 256
fe80::c30b:9a61 dev k_berge proto kernel metric 256
fe80::c30b:9a61 dev k_molven proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev k_sessesveits proto kernel metric 256
fe80::/64 dev k_wikene proto kernel metric 256
fe80::/64 dev k_trygve proto kernel metric 256
fe80::/64 dev k_magne proto kernel metric 256
fe80::/64 dev k_berge proto kernel metric 256
fe80::/64 dev k_molven proto kernel metric 256
default via 2001:67c:29f4::1 dev eth0 metric 1024
Note in particular that 2001:67c:a4::/48 goes to a link-local address. The
tcpdump is classic; when I try to do something big over my SSH session,
like an ls, it starts failing:
22:02:13.597303 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [P.], seq 5281:5521, ack 2802, win 149, options [nop,nop,TS val 1526325 ecr 45546957], length 240
22:02:13.597331 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [P.], seq 5521:5713, ack 2802, win 149, options [nop,nop,TS val 1526325 ecr 45546957], length 192
22:02:13.597353 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [P.], seq 5713:5921, ack 2802, win 149, options [nop,nop,TS val 1526325 ecr 45546957], length 208
22:02:13.597372 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [P.], seq 5921:6049, ack 2802, win 149, options [nop,nop,TS val 1526325 ecr 45546957], length 128
22:02:13.638445 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 3313, win 173, options [nop,nop,TS val 45546972 ecr 1526306], length 0
22:02:13.638468 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 6049:7477, ack 2802, win 149, options [nop,nop,TS val 1526366 ecr 45546972], length 1428
22:02:13.638475 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 7477:8905, ack 2802, win 149, options [nop,nop,TS val 1526366 ecr 45546972], length 1428
22:02:13.654519 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 3585, win 188, options [nop,nop,TS val 45546977 ecr 1526325], length 0
22:02:13.654538 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 8905:10333, ack 2802, win 149, options [nop,nop,TS val 1526382 ecr 45546977], length 1428
22:02:13.654545 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 10333:11761, ack 2802, win 149, options [nop,nop,TS val 1526382 ecr 45546977], length 1428
22:02:13.661389 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 4097, win 203, options [nop,nop,TS val 45546977 ecr 1526325], length 0
22:02:13.661408 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 11761:13189, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546977], length 1428
22:02:13.661415 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 13189:14617, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546977], length 1428
22:02:13.661420 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 4705, win 218, options [nop,nop,TS val 45546977 ecr 1526325], length 0
22:02:13.661431 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 14617:16045, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546977], length 1428
22:02:13.661436 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 16045:17473, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546977], length 1428
22:02:13.661441 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 5009, win 233, options [nop,nop,TS val 45546978 ecr 1526325], length 0
22:02:13.661449 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 17473:18901, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661454 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 18901:20329, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661458 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 5281, win 248, options [nop,nop,TS val 45546978 ecr 1526325], length 0
22:02:13.661464 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 20329:21757, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661468 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 21757:23185, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661472 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 5521, win 263, options [nop,nop,TS val 45546978 ecr 1526325], length 0
22:02:13.661478 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 23185:24613, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661483 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 24613:26041, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661486 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 5713, win 278, options [nop,nop,TS val 45546978 ecr 1526325], length 0
22:02:13.661493 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 26041:27469, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661496 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 27469:28897, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546978], length 1428
22:02:13.661500 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 5921, win 293, options [nop,nop,TS val 45546979 ecr 1526325], length 0
22:02:13.661506 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 28897:30325, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546979], length 1428
22:02:13.661510 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 30325:31753, ack 2802, win 149, options [nop,nop,TS val 1526389 ecr 45546979], length 1428
22:02:13.662006 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
22:02:13.667419 IP6 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943 > 2001:67c:29f4::50.22: Flags [.], ack 6049, win 307, options [nop,nop,TS val 45546979 ecr 1526325], length 0
22:02:13.667437 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 31753:33181, ack 2802, win 149, options [nop,nop,TS val 1526395 ecr 45546979], length 1428
22:02:13.667444 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 33181:34609, ack 2802, win 149, options [nop,nop,TS val 1526395 ecr 45546979], length 1428
22:02:13.667724 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
22:02:13.667743 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
22:02:13.794924 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 34609:36037, ack 2802, win 149, options [nop,nop,TS val 1526523 ecr 45546979], length 1428
22:02:13.795182 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
22:02:14.059981 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 6049:7477, ack 2802, win 149, options [nop,nop,TS val 1526788 ecr 45546979], length 1428
22:02:14.060308 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
22:02:14.589978 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 6049:7477, ack 2802, win 149, options [nop,nop,TS val 1527318 ecr 45546979], length 1428
22:02:14.590185 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
22:02:15.647967 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 6049:7477, ack 2802, win 149, options [nop,nop,TS val 1528376 ecr 45546979], length 1428
22:02:15.648223 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
22:02:17.768006 IP6 2001:67c:29f4::50.22 > 2001:67c:a4:1:5c5f:5194:3a7e:4878.48943: Flags [.], seq 6049:7477, ack 2802, win 149, options [nop,nop,TS val 1530496 ecr 45546979], length 1428
22:02:17.768307 IP6 2001:67c:29f4::31 > 2001:67c:29f4::50: ICMP6, packet too big, mtu 1468, length 1240
So the “packet too big” packets really look like they're being ignored.
However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
seems to increase.
Could this be related somehow to the packets coming from 2001:67c:29f4::31,
while the default route is to a link-local address? (An RPF issue?) This used
to work (although it was often flaky for me) in 3.10 and before. I can't
easily bisect, though, as I don't boot this machine too often.
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: [PATCH v2.40 6/7] datapath: Break out deacceleration portion of vlan_push
From: Ben Pfaff @ 2013-09-27 19:48 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1380241116-7661-7-git-send-email-horms@verge.net.au>
On Fri, Sep 27, 2013 at 09:18:35AM +0900, Simon Horman wrote:
> Break out deacceleration portion of vlan_push into vlan_put
> so that it may be re-used by mpls_push.
>
> For both vlan_push and mpls_push if there is an accelerated VLAN tag
> present then it should be deaccelerated, adding it to the data of
> the skb, before the new tag is added.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
I think Jesse already reviewed and approved patches 6 and 7, but I don't
see any Acked-by attached to them.
^ permalink raw reply
* Re: [PATCH v2.40 5/7] lib: Push MPLS tags in the OpenFlow 1.3 ordering
From: Ben Pfaff @ 2013-09-27 19:47 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1380241116-7661-6-git-send-email-horms@verge.net.au>
On Fri, Sep 27, 2013 at 09:18:34AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> This patch modifies the push_mpls behaviour to follow the OpenFlow 1.3
> specification in the presence of VLAN tagged packets. From the spec:
>
> "Newly pushed tags should always be inserted as the outermost tag in the
> outermost valid location for that tag. When a new VLAN tag is pushed, it
> should be the outermost tag inserted, immediately after the Ethernet
> header and before other tags. Likewise, when a new MPLS tag is pushed,
> it should be the outermost tag inserted, immediately after the Ethernet
> header and before other tags."
>
> When the push_mpls action was inserted using OpenFlow 1.2, we implement
> the previous behaviour by inserting VLAN actions around the MPLS action
> in the odp translation; Pop VLAN tags before committing MPLS actions,
> and push the expected VLAN tag afterwards. The trigger condition for
> this is based on the ofpact->compat field.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Referring to the OF1.2 behavior as "compat behavior" makes the
difference between the two possibilities less clear than otherwise. I
would prefer to use terminology that makes the distinction obvious.
Perhaps "push mpls before vlan" or "push mpls after vlan" or something
along those lines?
Thanks,
Ben.
^ permalink raw reply
* Re: [PATCH v2.40 4/7] ofp-actions: Add separate OpenFlow 1.3 action parser
From: Ben Pfaff @ 2013-09-27 19:41 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1380241116-7661-5-git-send-email-horms@verge.net.au>
On Fri, Sep 27, 2013 at 09:18:33AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> This patch adds new ofpact_from_openflow13() and
> ofpacts_from_openflow13() functions parallel to the existing ofpact
> handling code. In the OpenFlow 1.3 version, push_mpls is handled
> differently, but all other actions are handled by the existing code.
>
> For push_mpls, ofpact_push_mpls.ofpact.compat is set to
> OFPUTIL_OFPAT13_PUSH_MPLS, which allows correct VLAN+MPLS datapath
> behaviour to be determined at odp translation time.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Signed-off-by: Simon Horman <horms@verge.net.au>
I am nervous about this idea of having ofpacts_pull_openflow11_actions()
and ofpacts_pull_openflow11_instructions() try to figure out what
version of OpenFlow is involved. It is a new and somewhat surprising
requirements that the callers provide not just actions or instructions
but a complete OpenFlow message. I see that the callers in ovs-ofctl.c
don't satisfy this requirement.
I think that it would be better to make these functions' callers say
what version of OpenFlow they are working with. One could provide a
helper function like get_version_from_ofpbuf(), which should probably go
in ofp-util.c, but I would want it to fail (assert-fail or segfault or
whatever) if there is no L2 header pointer, instead of returning a
default value (that, in this case anyway, we know must be wrong because
OF1.0 never contains OF1.1+ actions or instructions).
Thanks,
Ben.
^ permalink raw reply
* Re: [PATCH v2.40 3/7] ofp-actions: Add OFPUTIL_OFPAT13_PUSH_MPLS
From: Ben Pfaff @ 2013-09-27 19:30 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1380241116-7661-4-git-send-email-horms@verge.net.au>
On Fri, Sep 27, 2013 at 09:18:32AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> This patch adds a new compatibility enum for use with MPLS, so that the
> differing behaviour between OpenFlow 1.2 and 1.3 can be implemented in
> ofproto-dpif-xlate.
It seems a little awkward to me to do this via a new OFPACT_, mostly
because there isn't currently any distinction between OF1.1 and OF1.3 in
terms of OFPACT_ definitions. Did you consider adding a new field to
struct ofpact_push_mpls that would say whether the label should be added
before or after a VLAN tag?
^ permalink raw reply
* Re: [PATCH] Allow userspace code to use flag IFA_F_SECONDARY to specify an ip address to be primary or secondary ip on an interface
From: Julian Anastasov @ 2013-09-27 19:26 UTC (permalink / raw)
To: Vincent Li; +Cc: netdev@vger.kernel.org, linux-kernel, davem
In-Reply-To: <CAK3+h2wYw92KR-Bzxesb5hNW2ua4GmVLeywJ__uPyqMW-+p8pA@mail.gmail.com>
Hello,
On Wed, 25 Sep 2013, Vincent Li wrote:
> I think it is good idea to add these preferences flags and sorted
> them, but my code knowledge is limited to implement it as I am still
> learning, I can help testing :)
I can try it, if such idea looks good enough to
others.
> On Wed, Sep 25, 2013 at 12:08 AM, Julian Anastasov <ja@ssi.bg> wrote:
>
> > My first idea was to use NLM_F_APPEND to implement
> > 'ip addr prepend' and 'ip addr append' but the default
> > operation is 'append' without providing NLM_F_APPEND, so it
> > does not work.
> >
> > Another idea is to add new attribute IFA_PREFERENCE in
> > include/uapi/linux/if_addr.h just before __IFA_MAX, integer,
> > 3 of the values are known. A preference for the used scope.
> >
> > /* Add as last, default */
> > IFA_PREFERENCE_APPEND = 0,
> >
> > /* Add as last primary, before any present primary in subnet */
> > IFA_PREFERENCE_PRIMARY = 128,
> >
> > /* First for scope */
> > IFA_PREFERENCE_FIRST = 255,
> >
> > We should keep it in ifa as priority, for
> > sorting purposes. It can be 4-byte value, if user wants
> > to copy user-defined order into preference.
> >
> > Sorting order should be:
> >
> > - all primaries sorted by decreasing scope, decreasing
> > priority and adding order
> >
> > - then all secondaries (IFA_F_SECONDARY) sorted by decreasing
> > priority and adding order
> >
> > Usage:
> >
> > ip addr add ... pref[erence] type_or_priority
> >
> > # Add floating IP (append at priority 128)
> > # The primary mode is not guaranteed if another address from
> > # the same subnet is already using the same or higher priority.
> > ip addr add ... pref primary
> > # More preferred primary
> > ip addr add ... pref 129
> >
> > # Add first IP for scope
> > ip addr add ... pref first
> >
> > The scope has similar 'sorting' property but not
> > for IPs in same subnet and it would be difficult to use
> > it for global routes.
> >
> > Thoughts?
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v2.40 2/7] odp: Allow VLAN actions after MPLS actions
From: Ben Pfaff @ 2013-09-27 19:21 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1380241116-7661-3-git-send-email-horms@verge.net.au>
On Fri, Sep 27, 2013 at 09:18:31AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> OpenFlow 1.2 and 1.3 differ on their handling of MPLS actions in the
> presence of VLAN tags. To allow correct behaviour to be committed in
> each situation, this patch adds a second round of VLAN tag action
> handling to commit_odp_actions(), which occurs after MPLS actions. This
> is implemented with a new field in 'struct xlate_in' called 'vlan_tci'.
>
> When an push_mpls action is composed, the flow's current VLAN state is
> stored into xin->vlan_tci, and flow->vlan_tci is set to 0 (pop_vlan). If
> a VLAN tag is present, it is stripped; if not, then there is no change.
> Any later modifications to the VLAN state is written to xin->vlan_tci.
> When committing the actions, flow->vlan_tci is used before MPLS actions,
> and xin->vlan_tci is used afterwards. This retains the current datapath
> behaviour, but allows VLAN actions to be applied in a more flexible
> manner.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Signed-off-by: Simon Horman <horms@verge.net.au>
The commit message talks about handling OpenFlow 1.2 and 1.3 both
properly, but I don't see how the code distinguishes between the cases.
Can you explain? Maybe this is something added in a later patch, in
which case it would be nice to mention that in the commit message.
There seems to be a typo in the comment in vlan_tci_restore() here:
> + /* If MPLS actions were executed after MPLS, copy the final vlan_tci out
> + * and restore the intermediate VLAN state. */
I was a little confused by the new local variable 'vlan_tci' in
do_xlate_actions(). Partly this was because the fact that I didn't find
it obvious that sometimes it points to different VLAN tags. I think
this would be easier to see if it were initially assigned just under the
big comment rather than in an initializer, so that one would know to
look at the comment.
Thanks,
Ben.
^ permalink raw reply
* Re: [PATCHv2] ipvs: improved SH fallback strategy
From: Julian Anastasov @ 2013-09-27 19:20 UTC (permalink / raw)
To: Alexander Frolkin
Cc: Simon Horman, Sergei Shtylyov, lvs-devel, Wensong Zhang, netdev,
linux-kernel
In-Reply-To: <20130927100622.GC28974@eldamar.org.uk>
Hello,
On Fri, 27 Sep 2013, Alexander Frolkin wrote:
> Improve the SH fallback realserver selection strategy.
>
> With sh and sh-fallback, if a realserver is down, this attempts to
> distribute the traffic that would have gone to that server evenly
> among the remaining servers.
>
> Signed-off-by: Alexander Frolkin <avf@eldamar.org.uk>
Thanks! Looks good to me.
Acked-by: Julian Anastasov <ja@ssi.bg>
> --
> diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
> index 3588fae..cc65b2f 100644
> --- a/net/netfilter/ipvs/ip_vs_sh.c
> +++ b/net/netfilter/ipvs/ip_vs_sh.c
> @@ -115,27 +115,46 @@ ip_vs_sh_get(struct ip_vs_service *svc, struct ip_vs_sh_state *s,
> }
>
>
> -/* As ip_vs_sh_get, but with fallback if selected server is unavailable */
> +/* As ip_vs_sh_get, but with fallback if selected server is unavailable
> + *
> + * The fallback strategy loops around the table starting from a "random"
> + * point (in fact, it is chosen to be the original hash value to make the
> + * algorithm deterministic) to find a new server.
> + */
> static inline struct ip_vs_dest *
> ip_vs_sh_get_fallback(struct ip_vs_service *svc, struct ip_vs_sh_state *s,
> const union nf_inet_addr *addr, __be16 port)
> {
> - unsigned int offset;
> - unsigned int hash;
> + unsigned int offset, roffset;
> + unsigned int hash, ihash;
> struct ip_vs_dest *dest;
>
> + /* first try the dest it's supposed to go to */
> + ihash = ip_vs_sh_hashkey(svc->af, addr, port, 0);
> + dest = rcu_dereference(s->buckets[ihash].dest);
> + if (!dest)
> + return NULL;
> + if (!is_unavailable(dest))
> + return dest;
> +
> + IP_VS_DBG_BUF(6, "SH: selected unavailable server %s:%d, reselecting",
> + IP_VS_DBG_ADDR(svc->af, &dest->addr), ntohs(dest->port));
> +
> + /* if the original dest is unavailable, loop around the table
> + * starting from ihash to find a new dest
> + */
> for (offset = 0; offset < IP_VS_SH_TAB_SIZE; offset++) {
> - hash = ip_vs_sh_hashkey(svc->af, addr, port, offset);
> + roffset = (offset + ihash) % IP_VS_SH_TAB_SIZE;
> + hash = ip_vs_sh_hashkey(svc->af, addr, port, roffset);
> dest = rcu_dereference(s->buckets[hash].dest);
> if (!dest)
> break;
> - if (is_unavailable(dest))
> - IP_VS_DBG_BUF(6, "SH: selected unavailable server "
> - "%s:%d (offset %d)",
> - IP_VS_DBG_ADDR(svc->af, &dest->addr),
> - ntohs(dest->port), offset);
> - else
> + if (!is_unavailable(dest))
> return dest;
> + IP_VS_DBG_BUF(6, "SH: selected unavailable "
> + "server %s:%d (offset %d), reselecting",
> + IP_VS_DBG_ADDR(svc->af, &dest->addr),
> + ntohs(dest->port), roffset);
> }
>
> return NULL;
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: at803x: add suspend/resume callbacks
From: Daniel Mack @ 2013-09-27 18:49 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem, ujhelyi.m, sergei.shtylyov
In-Reply-To: <523E877F.4050906@ti.com>
On 22.09.2013 08:00, Mugunthan V N wrote:
> On Saturday 21 September 2013 08:23 PM, Daniel Mack wrote:
>> When WOL is enabled, the chip can't be put into power-down (BMCR_PDOWN)
>> mode, as that will also switch off the MAC, which consequently leads to
>> a link loss.
>>
>> Use BMCR_ISOLATE in that case, which will at least save us some
>> milliamperes in comparison to normal operation mode.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
> Looks good to me
>
> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Thanks :)
David, can you take these two patches with Mugunthan's Acked-by: or do
you want me to resend them?
Best regards,
Daniel
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Vlad Yasevich @ 2013-09-27 18:10 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <1380301914.1734.63.camel@localhost.localdomain>
On 09/27/2013 01:11 PM, Toshiaki Makita wrote:
> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich wrote:
>>>>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
>>>>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich wrote:
>>>>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
>>>>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
>>>>>>>>>>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>>>>>> Date: Tue, 10 Sep 2013 19:27:54 +0900
>>>>>>>>>>>>
>>>>>>>>>>>>> There seem to be some undesirable behaviors related with PVID.
>>>>>>>>>>>>> 1. It has no effect assigning PVID to a port. PVID cannot be applied
>>>>>>>>>>>>> to any frame regardless of whether we set it or not.
>>>>>>>>>>>>> 2. FDB entries learned via frames applied PVID are registered with
>>>>>>>>>>>>> VID 0 rather than VID value of PVID.
>>>>>>>>>>>>> 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
>>>>>>>>>>>>> This leads interoperational problems such as sending frames with VID
>>>>>>>>>>>>> 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
>>>>>>>>>>>>> 0 as they belong to VLAN 0, which is expected to be handled as they have
>>>>>>>>>>>>> no VID according to IEEE 802.1Q.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
>>>>>>>>>>>>> is fixed, because we cannot activate PVID due to it.
>>>>>>>>>>>>
>>>>>>>>>>>> Please work out the issues in patch #2 with Vlad and resubmit this
>>>>>>>>>>>> series.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>
>>>>>>>>>>> I'm hovering between whether we should fix the issue by changing vlan 0
>>>>>>>>>>> interface behavior in 8021q module or enabling a bridge port to sending
>>>>>>>>>>> priority-tagged frames, or another better way.
>>>>>>>>>>>
>>>>>>>>>>> If you could comment it, I'd appreciate it :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> BTW, I think what is discussed in patch #2 is another problem about
>>>>>>>>>>> handling priority-tags, and it exists without this patch set applied.
>>>>>>>>>>> It looks like that we should prepare another patch set than this to fix
>>>>>>>>>>> that problem.
>>>>>>>>>>>
>>>>>>>>>>> Should I include patches that fix the priority-tags problem in this
>>>>>>>>>>> patch set and resubmit them all together?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am thinking that we might need to do it in bridge and it looks like
>>>>>>>>>> the simplest way to do it is to have default priority regeneration table
>>>>>>>>>> (table 6-5 from 802.1Q doc).
>>>>>>>>>>
>>>>>>>>>> That way I think we would conform to the spec.
>>>>>>>>>>
>>>>>>>>>> -vlad
>>>>>>>>>
>>>>>>>>> Unfortunately I don't think the default priority regeneration table
>>>>>>>>> resolves the problem because IEEE 802.1Q says that a VLAN-aware bridge
>>>>>>>>> can transmit untagged or VLAN-tagged frames only (the end of section 7.5
>>>>>>>>> and 8.1.7).
>>>>>>>>>
>>>>>>>>> No mechanism to send priority-tagged frames is found as far as I can see
>>>>>>>>> the standard. I think the regenerated priority is used for outgoing PCP
>>>>>>>>> field only if egress policy is not untagged (i.e. transmitting as
>>>>>>>>> VLAN-tagged), and unused if untagged (Section 6.9.2 3rd/4th Paragraph).
>>>>>>>>>
>>>>>>>>> If we want to transmit priority-tagged frames from a bridge port, I
>>>>>>>>> think we need to implement a new (optional) feature that is above the
>>>>>>>>> standard, as I stated previously.
>>>>>>>>>
>>>>>>>>> How do you feel about adding a per-port policy that enables a bridge to
>>>>>>>>> send priority-tagged frames instead of untagged frames when egress
>>>>>>>>> policy for the port is untagged?
>>>>>>>>> With this change, we can transmit frames for a given vlan as either all
>>>>>>>>> untagged, all priority-tagged or all VLAN-tagged.
>>>>>>>>
>>>>>>>> That would work. What I am thinking is that we do it by special casing
>>>>>>>> the vid 0 egress policy specification. Let it be untagged by default
>>>>>>>> and if it is tagged, then we preserve the priority field and forward
>>>>>>>> it on.
>>>>>>>>
>>>>>>>> This keeps the API stable and doesn't require user/admin from knowing
>>>>>>>> exactly what happens. Default operation conforms to the spec and allows
>>>>>>>> simple change to make it backward-compatible.
>>>>>>>>
>>>>>>>> What do you think. I've done a simple prototype of this an it seems to
>>>>>>>> work with the VMs I am testing with.
>>>>>>>
>>>>>>> Are you saying that
>>>>>>> - by default, set the 0th bit of untagged_bitmap; and
>>>>>>> - if we unset the 0th bit and set the "vid"th bit, we transmit frames
>>>>>>> classified as belonging to VLAN "vid" as priority-tagged?
>>>>>>>
>>>>>>> If so, though it's attractive to keep current API, I'm worried about if
>>>>>>> it could be a bit confusing and not intuitive for kernel/iproute2
>>>>>>> developers that VID 0 has a special meaning only in the egress policy.
>>>>>>> Wouldn't it be better to adding a new member to struct net_port_vlans
>>>>>>> instead of using VID 0 of untagged_bitmap?
>>>>>>>
>>>>>>> Or are you saying that we use a new flag in struct net_port_vlans but
>>>>>>> use the BRIDGE_VLAN_INFO_UNTAGGED bit with VID 0 in netlink to set the
>>>>>>> flag?
>>>>>>>
>>>>>>> Even in that case, I'm afraid that it might be confusing for developers
>>>>>>> for the same reason. We are going to prohibit to specify VID with 0 (and
>>>>>>> 4095) in adding/deleting a FDB entry or a vlan filtering entry, but it
>>>>>>> would allow us to use VID 0 only when a vlan filtering entry is
>>>>>>> configured.
>>>>>>> I am thinking a new nlattr is a straightforward approach to configure
>>>>>>> it.
>>>>>>
>>>>>> By making this an explicit attribute it makes vid 0 a special case for
>>>>>> any automatic tool that would provision such filtering. Seeing vid 0
>>>>>> would mean that these tools would have to know that this would have to
>>>>>> be translated to a different attribute instead of setting the policy
>>>>>> values.
>>>>>
>>>>> Yes, I agree with you that we can do it by the way you explained.
>>>>> What I don't understand is the advantage of using vid 0 over another way
>>>>> such as adding a new nlattr.
>>>>> I think we can indicate transmitting priority-tags explicitly by such a
>>>>> nlattr. Using vid 0 seems to be easier to implement than a new nlattr,
>>>>> but, for me, it looks less intuitive and more difficult to maintain
>>>>> because we have to care about vid 0 instead of simply ignoring it.
>>>>>
>>>>
>>>> The point I am trying to make is that regardless of the approach someone
>>>> has to know what to do when enabling priority tagged frames. You
>>>> proposal would require the administrator or config tool to have that
>>>> knowledge. Example is:
>>>> Admin does: bridge vlan set priority on dev eth0
>>>> Automated app:
>>>> if (vid == 0)
>>>> /* Turn on priority tagged frame support */
>>>>
>>>> My proposal would require the bridge filtering implementation to have it.
>>>> user tool: bridge vlan add vid 0 tagged
>>>> Automated app: No special case.
>>>>
>>>> IMO its better to have 1 piece code handling the special case then
>>>> putting it multiple places.
>>>
>>> Thank you for the detailed explanation.
>>> Now I understand your intention.
>>>
>>> I have one question about your proposal.
>>> I guess the way to enable priority-tagged is something like
>>> bridge vlan add vid 10 dev eth0
>>> bridge vlan add vid 10 dev vnet0 pvid untagged
>>> bridge vlan add vid 0 dev vnet0 tagged
>>> where vnet0 has sub interface vnet0.0.
>>>
>>> Here the admin have to know the egress policy is applied to a frame
>>> twice in a certain order when it is transmitted from the port vnet0
>>> attached, that is, first, a frame with vid 10 get untagged, and then, an
>>> untagged frame get priority-tagged.
>>>
>>> This behavior looks difficult to know without previous knowledge.
>>> Any good idea to avoid such a need for the admin's additional knowledge?
>>
>> To me, the fact that there is vnet0.0 (or typically, there is eth0.0 in
>> the guest or on the remote host) already tells the admin vlan 0 has to
>> be tagged. The fact that we codify this in the policy makes it explicit.
>
> My worry is that the admin might not be able to guess how to use bridge
> commands to enable priority-tag without any additional hint in "man
> bridge", "bridge vlan help", etc.
> I actually couldn't hit upon such a usage before seeing example commands
> you gave, because I had never think the egress policy could be applied
> twice.
>
>>
>> However, I can see strong argument to be made for an addition egress
>> policy attribute that could be for instance:
>>
>> bridge vlan add vid 10 dev eth0 pvid
>> bridge vlan add vid 10 dev vnet0 pvid untagged prio_tag
>>
>> But this has the same connotations as wrt to egress policy. The 2
>> policies are applied:
>> (1) untag the frame.
>> (2) add priority_tag.
>>
>> (2) only happens if initial fame received on eth0 was priority tagged.
>
> If we do so, we will not be able to communicate using vlan 0 interface
> under a certain circumstance.
> Eth0 can be receive mixed untagged and priority-tagged frames according
> to the network element it is connected to: for example, Open vSwitch can
> send such two kinds of frames from the same port even if original
> incoming frames belong to the same vlan.
Which priority would you assign to the frame that was received untagged?
> In this situation, we can only receive frames that is priority-tagged
> when received on eth0.
Not sure I understand. Let's look at this config:
bridge vlan add vid 10 dev eth0 pvid
bridge vlan add vid 10 dev vnet0 pvid untagged prio_tag
Here, eth0 is allowed to receive vid 10 tagged, untagged, and
prio_tagged (if we look at the patch 2 from this set).
Now, frame is forwarded to vnet0.
1) if the frame had vid 10 in the tag or was untagged,
it should probably be sent untagged.
2) if the frame had a priority tag, it should probably
be sent as such.
Now, I think a case could be made that if the frame had any priority
markings in the vlan header, we should try to preserve those markings
if prio_tag is turned on. We can assume value of 0 means not set.
> IMO, if prio_tag is configured, the bridge should send any untagged
> frame as priority-tagged regardless of whatever it is on eth0.
Which priority would you use, 0? You are not guaranteed to properly
deliver the traffic then for a configuration such as:
VM: eth0: 10.0.0.1/24
eth0.0: 10.0.1.1/24
-vlad
>
>>
>> I think I am ok with either approach. Explicit vid 0 policy is easier
>> for automatic provisioning. The flag based one is easier for admin/
>> manual provisioning.
>
> Supposing we have to add something to help or man in any case, I think
> flag based is better.
> The format below seems to suitable for a per-port policy.
> bridge vlan set prio_tag on dev vnet0
>
> Thanks,
>
> Toshiaki Makita
>
>>
>> -vlad.
>>
>> -vlad
>>
>>
>>
>>
>>>
>>>>
>>>> Thanks
>>>> -vlad
>>>>
>>>>> Thanks,
>>>>>
>>>>> Toshiaki Makita
>>>>>
>>>>>>
>>>>>> How it is implemented internally in the kernel isn't as big of an issue.
>>>>>> We can do it as a separate flag or as part of existing policy.
>>>>>>
>>>>>> -vlad
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Toshiaki Makita
>>>>>>>
>>>>>>>>
>>>>>>>> -vlad
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Toshiaki Makita
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* pull request: wireless 2013-09-27
From: John W. Linville @ 2013-09-27 18:05 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 34284 bytes --]
Dave,
Please pull this batch of fixes intended for the 3.12 stream!
Regarding the Bluetooth bits, Gustavo says:
"First Bluetooth fixes to 3.12, it includes:
* 3 patches to add device id for 3 new hardwares.
* 2 patches from Johan to fix the rfkill behaviour during setup stage
* a small clean up in the rfcomm TTY code that fixes a potential racy
condition (by Gianluca Anzolin)
* 2 fixes to proper set encryption key size and security level in the
peripheral role of Bluetooth LE devices. (by Andre Guedes)
* a fix for dealing devices where pairing is not necessary, we were keeping
the Bluetooth ACL connection alive for too much time. (by Syam Sidhardhan)"
Also, I fixed-up an curly-brace indentation problem in the Bluetooth
code while merging. On top of that...
Alexey Khoroshilov brings a p54usb fix to avoid a resource leak when
request_firmware_nowait fails.
Amitkumar Karwar fixes a firmware hang caused by too much header data
being appended for USB devices using the mwifiex driver.
Arend van Spriel provides three fixes: a brcmfmac fix to relocate some
driver code outside of an .init section; a scheduling while atomic
fix for bcma; and, another scheduling while atomic fix for brcmsmac.
Bing Zhao offers a pair of mwifiex fixes: a code change to avoid
firmware timeouts on USB; and a fix for a NULL pointer dereference.
Christian Lamparter adds a device ID to p54usb.
Felix Fietkau implements a quartet of small ath9k fixes, including
a locking fix, a list management fix, a fix to properly mark a stale
buffer, and an aggregate buffering fix.
Larry Finger champions a data alignment fix to make rtlwifi work
better with ARM builds.
Solomon Peachy reverts an earlier interrupt handling fix for cw1200
and replaces it with a new threaded oneshot irq handler implementation.
Sujith Manoharan fixes an ath9k regression by reverting an earlier
patch.
Please let me know if there are problems!
John
---
The following changes since commit f875691640cd3fa67f7ad1d3130ff9fa7fdca042:
Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can (2013-09-27 02:08:03 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 0a878747e18d4d14c5b772dcddddd86bb4c26f8f:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-09-27 13:11:17 -0400)
----------------------------------------------------------------
Alexey Khoroshilov (1):
p54usb: fix leak at failure path in p54u_load_firmware()
Amitkumar Karwar (1):
mwifiex: fix hang issue for USB chipsets
Andre Guedes (2):
Bluetooth: Fix security level for peripheral role
Bluetooth: Fix encryption key size for peripheral role
Arend van Spriel (3):
brcmfmac: obtain platform data upon module initialization
bcma: make bcma_core_pci_{up,down}() callable from atomic context
brcmsmac: call bcma_core_pci_power_save() from non-atomic context
Bing Zhao (2):
mwifiex: fix PCIe hs_cfg cancel cmd timeout
mwifiex: fix NULL pointer dereference in usb suspend handler
Christian Lamparter (1):
p54usb: add USB ID for Corega WLUSB2GTST USB adapter
Felix Fietkau (4):
ath9k: fix stale flag handling on buffer clone
ath9k: do not link bf_next across multiple A-MPDUs
ath9k: don't use BAW tracking on PS responses for non-AMPDU packets
ath9k: add txq locking for ath_tx_aggr_start
Gianluca Anzolin (1):
Bluetooth: don't release the port in rfcomm_dev_state_change()
Johan Hedberg (2):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Ken O'Brien (1):
Bluetooth: btusb: Add support for Belkin F8065bf
Larry Finger (1):
rtlwifi: Align private space in rtl_priv struct
Peng Chen (1):
Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
Raphael Kubo da Costa (1):
Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
Solomon Peachy (2):
Revert "cw1200: Don't perform SPI transfers in interrupt context"
cw1200: Use a threaded oneshot irq handler for cw1200_spi
Sujith Manoharan (1):
ath9k: Fix regression in LNA diversity
Syam Sidhardhan (1):
Bluetooth: Fix ACL alive for long in case of non pariable devices
drivers/bcma/driver_pci.c | 49 ++++++++++++----------
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/btusb.c | 5 +++
drivers/net/wireless/ath/ath9k/recv.c | 7 ----
drivers/net/wireless/ath/ath9k/xmit.c | 17 ++++++--
.../net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 28 ++++++-------
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h | 3 +-
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 14 ++++---
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 2 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 ++
drivers/net/wireless/cw1200/cw1200_spi.c | 26 ++++--------
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 -
drivers/net/wireless/cw1200/hwio.c | 15 -------
drivers/net/wireless/mwifiex/11n_aggr.c | 3 +-
drivers/net/wireless/mwifiex/11n_aggr.h | 2 +-
drivers/net/wireless/mwifiex/cmdevt.c | 5 +--
drivers/net/wireless/mwifiex/usb.c | 7 ----
drivers/net/wireless/mwifiex/wmm.c | 3 +-
drivers/net/wireless/p54/p54usb.c | 2 +
drivers/net/wireless/rtlwifi/wifi.h | 2 +-
include/linux/bcma/bcma_driver_pci.h | 1 +
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 26 +++++++++---
net/bluetooth/hci_event.c | 6 ++-
net/bluetooth/l2cap_core.c | 7 ++++
net/bluetooth/rfcomm/tty.c | 35 +---------------
27 files changed, 128 insertions(+), 147 deletions(-)
diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
index c9fd694..50329d1 100644
--- a/drivers/bcma/driver_pci.c
+++ b/drivers/bcma/driver_pci.c
@@ -210,25 +210,6 @@ static void bcma_core_pci_config_fixup(struct bcma_drv_pci *pc)
}
}
-static void bcma_core_pci_power_save(struct bcma_drv_pci *pc, bool up)
-{
- u16 data;
-
- if (pc->core->id.rev >= 15 && pc->core->id.rev <= 20) {
- data = up ? 0x74 : 0x7C;
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7F64);
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
- } else if (pc->core->id.rev >= 21 && pc->core->id.rev <= 22) {
- data = up ? 0x75 : 0x7D;
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7E65);
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
- }
-}
-
/**************************************************
* Init.
**************************************************/
@@ -255,6 +236,32 @@ void bcma_core_pci_init(struct bcma_drv_pci *pc)
bcma_core_pci_clientmode_init(pc);
}
+void bcma_core_pci_power_save(struct bcma_bus *bus, bool up)
+{
+ struct bcma_drv_pci *pc;
+ u16 data;
+
+ if (bus->hosttype != BCMA_HOSTTYPE_PCI)
+ return;
+
+ pc = &bus->drv_pci[0];
+
+ if (pc->core->id.rev >= 15 && pc->core->id.rev <= 20) {
+ data = up ? 0x74 : 0x7C;
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7F64);
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
+ } else if (pc->core->id.rev >= 21 && pc->core->id.rev <= 22) {
+ data = up ? 0x75 : 0x7D;
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7E65);
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
+ }
+}
+EXPORT_SYMBOL_GPL(bcma_core_pci_power_save);
+
int bcma_core_pci_irq_ctl(struct bcma_drv_pci *pc, struct bcma_device *core,
bool enable)
{
@@ -310,8 +317,6 @@ void bcma_core_pci_up(struct bcma_bus *bus)
pc = &bus->drv_pci[0];
- bcma_core_pci_power_save(pc, true);
-
bcma_core_pci_extend_L1timer(pc, true);
}
EXPORT_SYMBOL_GPL(bcma_core_pci_up);
@@ -326,7 +331,5 @@ void bcma_core_pci_down(struct bcma_bus *bus)
pc = &bus->drv_pci[0];
bcma_core_pci_extend_L1timer(pc, false);
-
- bcma_core_pci_power_save(pc, false);
}
EXPORT_SYMBOL_GPL(bcma_core_pci_down);
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index a12b923..0a327f4 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -85,6 +85,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
+ { USB_DEVICE(0x0CF3, 0xE005) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0489, 0xe057) },
{ USB_DEVICE(0x13d3, 0x3393) },
@@ -126,6 +127,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8e16f0a..f3dfc0a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -102,6 +102,7 @@ static struct usb_device_id btusb_table[] = {
/* Broadcom BCM20702A0 */
{ USB_DEVICE(0x0b05, 0x17b5) },
+ { USB_DEVICE(0x0b05, 0x17cb) },
{ USB_DEVICE(0x04ca, 0x2003) },
{ USB_DEVICE(0x0489, 0xe042) },
{ USB_DEVICE(0x413c, 0x8197) },
@@ -112,6 +113,9 @@ static struct usb_device_id btusb_table[] = {
/*Broadcom devices with vendor specific id */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) },
+ /* Belkin F8065bf - Broadcom based */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
+
{ } /* Terminating entry */
};
@@ -148,6 +152,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 4ee472a..ab9e3a8 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1270,13 +1270,6 @@ static void ath9k_antenna_check(struct ath_softc *sc,
return;
/*
- * All MPDUs in an aggregate will use the same LNA
- * as the first MPDU.
- */
- if (rs->rs_isaggr && !rs->rs_firstaggr)
- return;
-
- /*
* Change the default rx antenna if rx diversity
* chooses the other antenna 3 times in a row.
*/
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 35b515f..5ac713d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -399,6 +399,7 @@ static struct ath_buf* ath_clone_txbuf(struct ath_softc *sc, struct ath_buf *bf)
tbf->bf_buf_addr = bf->bf_buf_addr;
memcpy(tbf->bf_desc, bf->bf_desc, sc->sc_ah->caps.tx_desc_len);
tbf->bf_state = bf->bf_state;
+ tbf->bf_state.stale = false;
return tbf;
}
@@ -1389,11 +1390,15 @@ int ath_tx_aggr_start(struct ath_softc *sc, struct ieee80211_sta *sta,
u16 tid, u16 *ssn)
{
struct ath_atx_tid *txtid;
+ struct ath_txq *txq;
struct ath_node *an;
u8 density;
an = (struct ath_node *)sta->drv_priv;
txtid = ATH_AN_2_TID(an, tid);
+ txq = txtid->ac->txq;
+
+ ath_txq_lock(sc, txq);
/* update ampdu factor/density, they may have changed. This may happen
* in HT IBSS when a beacon with HT-info is received after the station
@@ -1417,6 +1422,8 @@ int ath_tx_aggr_start(struct ath_softc *sc, struct ieee80211_sta *sta,
memset(txtid->tx_buf, 0, sizeof(txtid->tx_buf));
txtid->baw_head = txtid->baw_tail = 0;
+ ath_txq_unlock_complete(sc, txq);
+
return 0;
}
@@ -1555,8 +1562,10 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
__skb_unlink(bf->bf_mpdu, tid_q);
list_add_tail(&bf->list, &bf_q);
ath_set_rates(tid->an->vif, tid->an->sta, bf);
- ath_tx_addto_baw(sc, tid, bf);
- bf->bf_state.bf_type &= ~BUF_AGGR;
+ if (bf_isampdu(bf)) {
+ ath_tx_addto_baw(sc, tid, bf);
+ bf->bf_state.bf_type &= ~BUF_AGGR;
+ }
if (bf_tail)
bf_tail->bf_next = bf;
@@ -1950,7 +1959,9 @@ static void ath_tx_txqaddbuf(struct ath_softc *sc, struct ath_txq *txq,
if (bf_is_ampdu_not_probing(bf))
txq->axq_ampdu_depth++;
- bf = bf->bf_lastbf->bf_next;
+ bf_last = bf->bf_lastbf;
+ bf = bf_last->bf_next;
+ bf_last->bf_next = NULL;
}
}
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
index 64f4a2b..c3462b7 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
@@ -464,8 +464,6 @@ static struct sdio_driver brcmf_sdmmc_driver = {
static int brcmf_sdio_pd_probe(struct platform_device *pdev)
{
- int ret;
-
brcmf_dbg(SDIO, "Enter\n");
brcmfmac_sdio_pdata = pdev->dev.platform_data;
@@ -473,11 +471,7 @@ static int brcmf_sdio_pd_probe(struct platform_device *pdev)
if (brcmfmac_sdio_pdata->power_on)
brcmfmac_sdio_pdata->power_on();
- ret = sdio_register_driver(&brcmf_sdmmc_driver);
- if (ret)
- brcmf_err("sdio_register_driver failed: %d\n", ret);
-
- return ret;
+ return 0;
}
static int brcmf_sdio_pd_remove(struct platform_device *pdev)
@@ -500,6 +494,15 @@ static struct platform_driver brcmf_sdio_pd = {
}
};
+void brcmf_sdio_register(void)
+{
+ int ret;
+
+ ret = sdio_register_driver(&brcmf_sdmmc_driver);
+ if (ret)
+ brcmf_err("sdio_register_driver failed: %d\n", ret);
+}
+
void brcmf_sdio_exit(void)
{
brcmf_dbg(SDIO, "Enter\n");
@@ -510,18 +513,13 @@ void brcmf_sdio_exit(void)
sdio_unregister_driver(&brcmf_sdmmc_driver);
}
-void brcmf_sdio_init(void)
+void __init brcmf_sdio_init(void)
{
int ret;
brcmf_dbg(SDIO, "Enter\n");
ret = platform_driver_probe(&brcmf_sdio_pd, brcmf_sdio_pd_probe);
- if (ret == -ENODEV) {
- brcmf_dbg(SDIO, "No platform data available, registering without.\n");
- ret = sdio_register_driver(&brcmf_sdmmc_driver);
- }
-
- if (ret)
- brcmf_err("driver registration failed: %d\n", ret);
+ if (ret == -ENODEV)
+ brcmf_dbg(SDIO, "No platform data available.\n");
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h b/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
index f7c1985..74156f8 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
@@ -156,10 +156,11 @@ extern int brcmf_bus_start(struct device *dev);
#ifdef CONFIG_BRCMFMAC_SDIO
extern void brcmf_sdio_exit(void);
extern void brcmf_sdio_init(void);
+extern void brcmf_sdio_register(void);
#endif
#ifdef CONFIG_BRCMFMAC_USB
extern void brcmf_usb_exit(void);
-extern void brcmf_usb_init(void);
+extern void brcmf_usb_register(void);
#endif
#endif /* _BRCMF_BUS_H_ */
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
index e067aec..40e7f85 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
@@ -1231,21 +1231,23 @@ u32 brcmf_get_chip_info(struct brcmf_if *ifp)
return bus->chip << 4 | bus->chiprev;
}
-static void brcmf_driver_init(struct work_struct *work)
+static void brcmf_driver_register(struct work_struct *work)
{
- brcmf_debugfs_init();
-
#ifdef CONFIG_BRCMFMAC_SDIO
- brcmf_sdio_init();
+ brcmf_sdio_register();
#endif
#ifdef CONFIG_BRCMFMAC_USB
- brcmf_usb_init();
+ brcmf_usb_register();
#endif
}
-static DECLARE_WORK(brcmf_driver_work, brcmf_driver_init);
+static DECLARE_WORK(brcmf_driver_work, brcmf_driver_register);
static int __init brcmfmac_module_init(void)
{
+ brcmf_debugfs_init();
+#ifdef CONFIG_BRCMFMAC_SDIO
+ brcmf_sdio_init();
+#endif
if (!schedule_work(&brcmf_driver_work))
return -EBUSY;
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index 39e01a7..f4aea47 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -1539,7 +1539,7 @@ void brcmf_usb_exit(void)
brcmf_release_fw(&fw_image_list);
}
-void brcmf_usb_init(void)
+void brcmf_usb_register(void)
{
brcmf_dbg(USB, "Enter\n");
INIT_LIST_HEAD(&fw_image_list);
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
index 3a65447..edc5d10 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
@@ -457,6 +457,8 @@ static int brcms_ops_start(struct ieee80211_hw *hw)
if (err != 0)
brcms_err(wl->wlc->hw->d11core, "%s: brcms_up() returned %d\n",
__func__, err);
+
+ bcma_core_pci_power_save(wl->wlc->hw->d11core->bus, true);
return err;
}
@@ -479,6 +481,8 @@ static void brcms_ops_stop(struct ieee80211_hw *hw)
return;
}
+ bcma_core_pci_power_save(wl->wlc->hw->d11core->bus, false);
+
/* put driver in down state */
spin_lock_bh(&wl->lock);
brcms_down(wl);
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index f5e6b48..899cad3 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -42,7 +42,6 @@ struct hwbus_priv {
spinlock_t lock; /* Serialize all bus operations */
wait_queue_head_t wq;
int claimed;
- int irq_disabled;
};
#define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -238,8 +237,6 @@ static irqreturn_t cw1200_spi_irq_handler(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
- disable_irq_nosync(self->func->irq);
- self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -253,9 +250,10 @@ static int cw1200_spi_irq_subscribe(struct hwbus_priv *self)
pr_debug("SW IRQ subscribe\n");
- ret = request_any_context_irq(self->func->irq, cw1200_spi_irq_handler,
- IRQF_TRIGGER_HIGH,
- "cw1200_wlan_irq", self);
+ ret = request_threaded_irq(self->func->irq, NULL,
+ cw1200_spi_irq_handler,
+ IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+ "cw1200_wlan_irq", self);
if (WARN_ON(ret < 0))
goto exit;
@@ -273,22 +271,13 @@ exit:
static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
{
+ int ret = 0;
+
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
- return 0;
-}
-
-static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
-{
- /* Disables are handled by the interrupt handler */
- if (enable && self->irq_disabled) {
- enable_irq(self->func->irq);
- self->irq_disabled = 0;
- }
-
- return 0;
+ return ret;
}
static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -368,7 +357,6 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
- .irq_enable = cw1200_spi_irq_enable,
};
/* Probe Function to be called by SPI stack when device is discovered */
diff --git a/drivers/net/wireless/cw1200/fwio.c b/drivers/net/wireless/cw1200/fwio.c
index 0b2061b..acdff0f 100644
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_common *priv)
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
- ret = __cw1200_irq_enable(priv, 2);
+ ret = __cw1200_irq_enable(priv, 1);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
diff --git a/drivers/net/wireless/cw1200/hwbus.h b/drivers/net/wireless/cw1200/hwbus.h
index 51dfb3a..8b2fc83 100644
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,7 +28,6 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
- int (*irq_enable)(struct hwbus_priv *self, int enable);
};
#endif /* CW1200_HWBUS_H */
diff --git a/drivers/net/wireless/cw1200/hwio.c b/drivers/net/wireless/cw1200/hwio.c
index 41bd761..ff230b7 100644
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,21 +273,6 @@ int __cw1200_irq_enable(struct cw1200_common *priv, int enable)
u16 val16;
int ret;
- /* We need to do this hack because the SPI layer can sleep on I/O
- and the general path involves I/O to the device in interrupt
- context.
-
- However, the initial enable call needs to go to the hardware.
-
- We don't worry about shutdown because we do a full reset which
- clears the interrupt enabled bits.
- */
- if (priv->hwbus_ops->irq_enable) {
- ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
- if (ret || enable < 2)
- return ret;
- }
-
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, &val32);
if (ret < 0) {
diff --git a/drivers/net/wireless/mwifiex/11n_aggr.c b/drivers/net/wireless/mwifiex/11n_aggr.c
index 21c6882..1214c58 100644
--- a/drivers/net/wireless/mwifiex/11n_aggr.c
+++ b/drivers/net/wireless/mwifiex/11n_aggr.c
@@ -150,7 +150,7 @@ mwifiex_11n_form_amsdu_txpd(struct mwifiex_private *priv,
*/
int
mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
- struct mwifiex_ra_list_tbl *pra_list, int headroom,
+ struct mwifiex_ra_list_tbl *pra_list,
int ptrindex, unsigned long ra_list_flags)
__releases(&priv->wmm.ra_list_spinlock)
{
@@ -160,6 +160,7 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
int pad = 0, ret;
struct mwifiex_tx_param tx_param;
struct txpd *ptx_pd = NULL;
+ int headroom = adapter->iface_type == MWIFIEX_USB ? 0 : INTF_HEADER_LEN;
skb_src = skb_peek(&pra_list->skb_head);
if (!skb_src) {
diff --git a/drivers/net/wireless/mwifiex/11n_aggr.h b/drivers/net/wireless/mwifiex/11n_aggr.h
index 900e1c6..892098d 100644
--- a/drivers/net/wireless/mwifiex/11n_aggr.h
+++ b/drivers/net/wireless/mwifiex/11n_aggr.h
@@ -26,7 +26,7 @@
int mwifiex_11n_deaggregate_pkt(struct mwifiex_private *priv,
struct sk_buff *skb);
int mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
- struct mwifiex_ra_list_tbl *ptr, int headroom,
+ struct mwifiex_ra_list_tbl *ptr,
int ptr_index, unsigned long flags)
__releases(&priv->wmm.ra_list_spinlock);
diff --git a/drivers/net/wireless/mwifiex/cmdevt.c b/drivers/net/wireless/mwifiex/cmdevt.c
index 2d76147..a6c46f3 100644
--- a/drivers/net/wireless/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/mwifiex/cmdevt.c
@@ -1155,7 +1155,7 @@ int mwifiex_ret_802_11_hs_cfg(struct mwifiex_private *priv,
uint32_t conditions = le32_to_cpu(phs_cfg->params.hs_config.conditions);
if (phs_cfg->action == cpu_to_le16(HS_ACTIVATE) &&
- adapter->iface_type == MWIFIEX_SDIO) {
+ adapter->iface_type != MWIFIEX_USB) {
mwifiex_hs_activated_event(priv, true);
return 0;
} else {
@@ -1167,8 +1167,7 @@ int mwifiex_ret_802_11_hs_cfg(struct mwifiex_private *priv,
}
if (conditions != HS_CFG_CANCEL) {
adapter->is_hs_configured = true;
- if (adapter->iface_type == MWIFIEX_USB ||
- adapter->iface_type == MWIFIEX_PCIE)
+ if (adapter->iface_type == MWIFIEX_USB)
mwifiex_hs_activated_event(priv, true);
} else {
adapter->is_hs_configured = false;
diff --git a/drivers/net/wireless/mwifiex/usb.c b/drivers/net/wireless/mwifiex/usb.c
index 2472d4b..1c70b8d 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -447,9 +447,6 @@ static int mwifiex_usb_suspend(struct usb_interface *intf, pm_message_t message)
*/
adapter->is_suspended = true;
- for (i = 0; i < adapter->priv_num; i++)
- netif_carrier_off(adapter->priv[i]->netdev);
-
if (atomic_read(&card->rx_cmd_urb_pending) && card->rx_cmd.urb)
usb_kill_urb(card->rx_cmd.urb);
@@ -509,10 +506,6 @@ static int mwifiex_usb_resume(struct usb_interface *intf)
MWIFIEX_RX_CMD_BUF_SIZE);
}
- for (i = 0; i < adapter->priv_num; i++)
- if (adapter->priv[i]->media_connected)
- netif_carrier_on(adapter->priv[i]->netdev);
-
/* Disable Host Sleep */
if (adapter->hs_activated)
mwifiex_cancel_hs(mwifiex_get_priv(adapter,
diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c
index 2e8f9cd..95fa359 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -1239,8 +1239,7 @@ mwifiex_dequeue_tx_packet(struct mwifiex_adapter *adapter)
if (enable_tx_amsdu && mwifiex_is_amsdu_allowed(priv, tid) &&
mwifiex_is_11n_aggragation_possible(priv, ptr,
adapter->tx_buf_size))
- mwifiex_11n_aggregate_pkt(priv, ptr, INTF_HEADER_LEN,
- ptr_index, flags);
+ mwifiex_11n_aggregate_pkt(priv, ptr, ptr_index, flags);
/* ra_list_spinlock has been freed in
mwifiex_11n_aggregate_pkt() */
else
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index b9deef6..e328d30 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -83,6 +83,7 @@ static struct usb_device_id p54u_table[] = {
{USB_DEVICE(0x06a9, 0x000e)}, /* Westell 802.11g USB (A90-211WG-01) */
{USB_DEVICE(0x06b9, 0x0121)}, /* Thomson SpeedTouch 121g */
{USB_DEVICE(0x0707, 0xee13)}, /* SMC 2862W-G version 2 */
+ {USB_DEVICE(0x07aa, 0x0020)}, /* Corega WLUSB2GTST USB */
{USB_DEVICE(0x0803, 0x4310)}, /* Zoom 4410a */
{USB_DEVICE(0x083a, 0x4521)}, /* Siemens Gigaset USB Adapter 54 version 2 */
{USB_DEVICE(0x083a, 0x4531)}, /* T-Com Sinus 154 data II */
@@ -979,6 +980,7 @@ static int p54u_load_firmware(struct ieee80211_hw *dev,
if (err) {
dev_err(&priv->udev->dev, "(p54usb) cannot load firmware %s "
"(%d)!\n", p54u_fwlist[i].fw, err);
+ usb_put_dev(udev);
}
return err;
diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
index cc03e7c..7032587 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -2057,7 +2057,7 @@ struct rtl_priv {
that it points to the data allocated
beyond this structure like:
rtl_pci_priv or rtl_usb_priv */
- u8 priv[0];
+ u8 priv[0] __aligned(sizeof(void *));
};
#define rtl_priv(hw) (((struct rtl_priv *)(hw)->priv))
diff --git a/include/linux/bcma/bcma_driver_pci.h b/include/linux/bcma/bcma_driver_pci.h
index d66033f..0333e60 100644
--- a/include/linux/bcma/bcma_driver_pci.h
+++ b/include/linux/bcma/bcma_driver_pci.h
@@ -242,6 +242,7 @@ extern int bcma_core_pci_irq_ctl(struct bcma_drv_pci *pc,
struct bcma_device *core, bool enable);
extern void bcma_core_pci_up(struct bcma_bus *bus);
extern void bcma_core_pci_down(struct bcma_bus *bus);
+extern void bcma_core_pci_power_save(struct bcma_bus *bus, bool up);
extern int bcma_core_pci_pcibios_map_irq(const struct pci_dev *dev);
extern int bcma_core_pci_plat_dev_init(struct pci_dev *dev);
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index aaeaf09..15f1084 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -104,6 +104,7 @@ enum {
enum {
HCI_SETUP,
HCI_AUTO_OFF,
+ HCI_RFKILLED,
HCI_MGMT,
HCI_PAIRABLE,
HCI_SERVICE_CACHE,
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 634deba..fb7356f 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1146,7 +1146,11 @@ int hci_dev_open(__u16 dev)
goto done;
}
- if (hdev->rfkill && rfkill_blocked(hdev->rfkill)) {
+ /* Check for rfkill but allow the HCI setup stage to proceed
+ * (which in itself doesn't cause any RF activity).
+ */
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags) &&
+ !test_bit(HCI_SETUP, &hdev->dev_flags)) {
ret = -ERFKILL;
goto done;
}
@@ -1566,10 +1570,13 @@ static int hci_rfkill_set_block(void *data, bool blocked)
BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
- if (!blocked)
- return 0;
-
- hci_dev_do_close(hdev);
+ if (blocked) {
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+ if (!test_bit(HCI_SETUP, &hdev->dev_flags))
+ hci_dev_do_close(hdev);
+ } else {
+ clear_bit(HCI_RFKILLED, &hdev->dev_flags);
+ }
return 0;
}
@@ -1591,9 +1598,13 @@ static void hci_power_on(struct work_struct *work)
return;
}
- if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags))
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
+ clear_bit(HCI_AUTO_OFF, &hdev->dev_flags);
+ hci_dev_do_close(hdev);
+ } else if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags)) {
queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
HCI_AUTO_OFF_TIMEOUT);
+ }
if (test_and_clear_bit(HCI_SETUP, &hdev->dev_flags))
mgmt_index_added(hdev);
@@ -2209,6 +2220,9 @@ int hci_register_dev(struct hci_dev *hdev)
}
}
+ if (hdev->rfkill && rfkill_blocked(hdev->rfkill))
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+
set_bit(HCI_SETUP, &hdev->dev_flags);
if (hdev->dev_type != HCI_AMP)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 94aab73..8db3e89 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3557,7 +3557,11 @@ static void hci_le_ltk_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
cp.handle = cpu_to_le16(conn->handle);
if (ltk->authenticated)
- conn->sec_level = BT_SECURITY_HIGH;
+ conn->pending_sec_level = BT_SECURITY_HIGH;
+ else
+ conn->pending_sec_level = BT_SECURITY_MEDIUM;
+
+ conn->enc_key_size = ltk->enc_size;
hci_send_cmd(hdev, HCI_OP_LE_LTK_REPLY, sizeof(cp), &cp);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index b3bb7bc..63fa111 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3755,6 +3755,13 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
sk = chan->sk;
+ /* For certain devices (ex: HID mouse), support for authentication,
+ * pairing and bonding is optional. For such devices, inorder to avoid
+ * the ACL alive for too long after L2CAP disconnection, reset the ACL
+ * disc_timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
+ */
+ conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
+
bacpy(&bt_sk(sk)->src, conn->src);
bacpy(&bt_sk(sk)->dst, conn->dst);
chan->psm = psm;
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 6d126fa..84fcf9f 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -569,7 +569,6 @@ static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb)
static void rfcomm_dev_state_change(struct rfcomm_dlc *dlc, int err)
{
struct rfcomm_dev *dev = dlc->owner;
- struct tty_struct *tty;
if (!dev)
return;
@@ -581,38 +580,8 @@ static void rfcomm_dev_state_change(struct rfcomm_dlc *dlc, int err)
DPM_ORDER_DEV_AFTER_PARENT);
wake_up_interruptible(&dev->port.open_wait);
- } else if (dlc->state == BT_CLOSED) {
- tty = tty_port_tty_get(&dev->port);
- if (!tty) {
- if (test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags)) {
- /* Drop DLC lock here to avoid deadlock
- * 1. rfcomm_dev_get will take rfcomm_dev_lock
- * but in rfcomm_dev_add there's lock order:
- * rfcomm_dev_lock -> dlc lock
- * 2. tty_port_put will deadlock if it's
- * the last reference
- *
- * FIXME: when we release the lock anything
- * could happen to dev, even its destruction
- */
- rfcomm_dlc_unlock(dlc);
- if (rfcomm_dev_get(dev->id) == NULL) {
- rfcomm_dlc_lock(dlc);
- return;
- }
-
- if (!test_and_set_bit(RFCOMM_TTY_RELEASED,
- &dev->flags))
- tty_port_put(&dev->port);
-
- tty_port_put(&dev->port);
- rfcomm_dlc_lock(dlc);
- }
- } else {
- tty_hangup(tty);
- tty_kref_put(tty);
- }
- }
+ } else if (dlc->state == BT_CLOSED)
+ tty_port_tty_hangup(&dev->port, false);
}
static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH v3 net-next 2/2] qlge: Update version to 1.00.00.33
From: Jitendra Kalsaria @ 2013-09-27 17:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept-HSGLinuxNICDev, Jitendra Kalsaria
In-Reply-To: <1380302267-27843-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlge/qlge.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge.h b/drivers/net/ethernet/qlogic/qlge/qlge.h
index cc62272..f1af4d6 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge.h
+++ b/drivers/net/ethernet/qlogic/qlge/qlge.h
@@ -18,7 +18,7 @@
*/
#define DRV_NAME "qlge"
#define DRV_STRING "QLogic 10 Gigabit PCI-E Ethernet Driver "
-#define DRV_VERSION "v1.00.00.32"
+#define DRV_VERSION "1.00.00.33"
#define WQ_ADDR_ALIGN 0x3 /* 4 byte alignment */
--
1.7.6.rc1.1.g2c162b
^ permalink raw reply related
* [PATCH v3 net-next 1/2] qlge: Enhance nested VLAN (Q-in-Q) handling.
From: Jitendra Kalsaria @ 2013-09-27 17:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept-HSGLinuxNICDev, Jitendra Kalsaria
In-Reply-To: <1380302267-27843-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
o Adapter doesn’t handle packets with nested VLAN tags in
Rx path. User can turn off VLAN tag stripping in the hardware
and let the stack handle stripping of VLAN tags in the Rx path.
o Users can enable or disable hardware VLAN acceleration using ethtool
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 126 +++++++++++++++++++++-----
1 files changed, 101 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
index 2553cf4..64f9409 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
@@ -96,8 +96,10 @@ static DEFINE_PCI_DEVICE_TABLE(qlge_pci_tbl) = {
MODULE_DEVICE_TABLE(pci, qlge_pci_tbl);
-static int ql_wol(struct ql_adapter *qdev);
-static void qlge_set_multicast_list(struct net_device *ndev);
+static int ql_wol(struct ql_adapter *);
+static void qlge_set_multicast_list(struct net_device *);
+static int ql_adapter_down(struct ql_adapter *);
+static int ql_adapter_up(struct ql_adapter *);
/* This hardware semaphore causes exclusive access to
* resources shared between the NIC driver, MPI firmware,
@@ -1464,6 +1466,29 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err,
}
}
+/**
+ * ql_update_mac_hdr_len - helper routine to update the mac header length
+ * based on vlan tags if present
+ */
+static void ql_update_mac_hdr_len(struct ql_adapter *qdev,
+ struct ib_mac_iocb_rsp *ib_mac_rsp,
+ void *page, size_t *len)
+{
+ u16 *tags;
+
+ if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX)
+ return;
+ if (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) {
+ tags = (u16 *)page;
+ /* Look for stacked vlan tags in ethertype field */
+ if (tags[6] == ETH_P_8021Q &&
+ tags[8] == ETH_P_8021Q)
+ *len += 2 * VLAN_HLEN;
+ else
+ *len += VLAN_HLEN;
+ }
+}
+
/* Process an inbound completion from an rx ring. */
static void ql_process_mac_rx_gro_page(struct ql_adapter *qdev,
struct rx_ring *rx_ring,
@@ -1523,6 +1548,7 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
void *addr;
struct bq_desc *lbq_desc = ql_get_curr_lchunk(qdev, rx_ring);
struct napi_struct *napi = &rx_ring->napi;
+ size_t hlen = ETH_HLEN;
skb = netdev_alloc_skb(ndev, length);
if (!skb) {
@@ -1540,25 +1566,28 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
goto err_out;
}
+ /* Update the MAC header length*/
+ ql_update_mac_hdr_len(qdev, ib_mac_rsp, addr, &hlen);
+
/* The max framesize filter on this chip is set higher than
* MTU since FCoE uses 2k frames.
*/
- if (skb->len > ndev->mtu + ETH_HLEN) {
+ if (skb->len > ndev->mtu + hlen) {
netif_err(qdev, drv, qdev->ndev,
"Segment too small, dropping.\n");
rx_ring->rx_dropped++;
goto err_out;
}
- memcpy(skb_put(skb, ETH_HLEN), addr, ETH_HLEN);
+ memcpy(skb_put(skb, hlen), addr, hlen);
netif_printk(qdev, rx_status, KERN_DEBUG, qdev->ndev,
"%d bytes of headers and data in large. Chain page to new skb and pull tail.\n",
length);
skb_fill_page_desc(skb, 0, lbq_desc->p.pg_chunk.page,
- lbq_desc->p.pg_chunk.offset+ETH_HLEN,
- length-ETH_HLEN);
- skb->len += length-ETH_HLEN;
- skb->data_len += length-ETH_HLEN;
- skb->truesize += length-ETH_HLEN;
+ lbq_desc->p.pg_chunk.offset + hlen,
+ length - hlen);
+ skb->len += length - hlen;
+ skb->data_len += length - hlen;
+ skb->truesize += length - hlen;
rx_ring->rx_packets++;
rx_ring->rx_bytes += skb->len;
@@ -1576,7 +1605,7 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
(ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_V4)) {
/* Unfragmented ipv4 UDP frame. */
struct iphdr *iph =
- (struct iphdr *) ((u8 *)addr + ETH_HLEN);
+ (struct iphdr *)((u8 *)addr + hlen);
if (!(iph->frag_off &
htons(IP_MF|IP_OFFSET))) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -1726,7 +1755,8 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
struct bq_desc *sbq_desc;
struct sk_buff *skb = NULL;
u32 length = le32_to_cpu(ib_mac_rsp->data_len);
- u32 hdr_len = le32_to_cpu(ib_mac_rsp->hdr_len);
+ u32 hdr_len = le32_to_cpu(ib_mac_rsp->hdr_len);
+ size_t hlen = ETH_HLEN;
/*
* Handle the header buffer if present.
@@ -1853,9 +1883,10 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
skb->data_len += length;
skb->truesize += length;
length -= length;
- __pskb_pull_tail(skb,
- (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
- VLAN_ETH_HLEN : ETH_HLEN);
+ ql_update_mac_hdr_len(qdev, ib_mac_rsp,
+ lbq_desc->p.pg_chunk.va,
+ &hlen);
+ __pskb_pull_tail(skb, hlen);
}
} else {
/*
@@ -1910,8 +1941,9 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
length -= size;
i++;
}
- __pskb_pull_tail(skb, (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
- VLAN_ETH_HLEN : ETH_HLEN);
+ ql_update_mac_hdr_len(qdev, ib_mac_rsp, lbq_desc->p.pg_chunk.va,
+ &hlen);
+ __pskb_pull_tail(skb, hlen);
}
return skb;
}
@@ -2003,7 +2035,7 @@ static void ql_process_mac_split_rx_intr(struct ql_adapter *qdev,
rx_ring->rx_packets++;
rx_ring->rx_bytes += skb->len;
skb_record_rx_queue(skb, rx_ring->cq_id);
- if ((ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) && (vlan_id != 0))
+ if (vlan_id != 0xffff)
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_id);
if (skb->ip_summed == CHECKSUM_UNNECESSARY)
napi_gro_receive(&rx_ring->napi, skb);
@@ -2017,7 +2049,8 @@ static unsigned long ql_process_mac_rx_intr(struct ql_adapter *qdev,
struct ib_mac_iocb_rsp *ib_mac_rsp)
{
u32 length = le32_to_cpu(ib_mac_rsp->data_len);
- u16 vlan_id = (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
+ u16 vlan_id = ((ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) &&
+ (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX)) ?
((le16_to_cpu(ib_mac_rsp->vlan_id) &
IB_MAC_IOCB_RSP_VLAN_MASK)) : 0xffff;
@@ -2310,9 +2343,39 @@ static void qlge_vlan_mode(struct net_device *ndev, netdev_features_t features)
}
}
+/**
+ * qlge_update_hw_vlan_features - helper routine to reinitialize the adapter
+ * based on the features to enable/disable hardware vlan accel
+ */
+static int qlge_update_hw_vlan_features(struct net_device *ndev,
+ netdev_features_t features)
+{
+ struct ql_adapter *qdev = netdev_priv(ndev);
+ int status = 0;
+
+ status = ql_adapter_down(qdev);
+ if (status) {
+ netif_err(qdev, link, qdev->ndev,
+ "Failed to bring down the adapter\n");
+ return status;
+ }
+
+ /* update the features with resent change */
+ ndev->features = features;
+
+ status = ql_adapter_up(qdev);
+ if (status) {
+ netif_err(qdev, link, qdev->ndev,
+ "Failed to bring up the adapter\n");
+ return status;
+ }
+ return status;
+}
+
static netdev_features_t qlge_fix_features(struct net_device *ndev,
netdev_features_t features)
{
+ int err;
/*
* Since there is no support for separate rx/tx vlan accel
* enable/disable make sure tx flag is always in same state as rx.
@@ -2322,6 +2385,11 @@ static netdev_features_t qlge_fix_features(struct net_device *ndev,
else
features &= ~NETIF_F_HW_VLAN_CTAG_TX;
+ /* Update the behavior of vlan accel in the adapter */
+ err = qlge_update_hw_vlan_features(ndev, features);
+ if (err)
+ return err;
+
return features;
}
@@ -3704,8 +3772,12 @@ static int ql_adapter_initialize(struct ql_adapter *qdev)
ql_write32(qdev, SYS, mask | value);
/* Set the default queue, and VLAN behavior. */
- value = NIC_RCV_CFG_DFQ | NIC_RCV_CFG_RV;
- mask = NIC_RCV_CFG_DFQ_MASK | (NIC_RCV_CFG_RV << 16);
+ value = NIC_RCV_CFG_DFQ;
+ mask = NIC_RCV_CFG_DFQ_MASK;
+ if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX) {
+ value |= NIC_RCV_CFG_RV;
+ mask |= (NIC_RCV_CFG_RV << 16);
+ }
ql_write32(qdev, NIC_RCV_CFG, (mask | value));
/* Set the MPI interrupt to enabled. */
@@ -4692,11 +4764,15 @@ static int qlge_probe(struct pci_dev *pdev,
qdev = netdev_priv(ndev);
SET_NETDEV_DEV(ndev, &pdev->dev);
- ndev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
- NETIF_F_TSO | NETIF_F_TSO_ECN |
- NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_RXCSUM;
- ndev->features = ndev->hw_features |
- NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_FILTER;
+ ndev->hw_features = NETIF_F_SG |
+ NETIF_F_IP_CSUM |
+ NETIF_F_TSO |
+ NETIF_F_TSO_ECN |
+ NETIF_F_HW_VLAN_CTAG_TX |
+ NETIF_F_HW_VLAN_CTAG_RX |
+ NETIF_F_HW_VLAN_CTAG_FILTER |
+ NETIF_F_RXCSUM;
+ ndev->features = ndev->hw_features;
ndev->vlan_features = ndev->hw_features;
if (test_bit(QL_DMA64, &qdev->flags))
--
1.7.6.rc1.1.g2c162b
^ permalink raw reply related
* [PATCH v3 net-next 0/2] qlge: feature update
From: Jitendra Kalsaria @ 2013-09-27 17:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept-HSGLinuxNICDev, Jitendra Kalsaria
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
This patch series enhance the handling of nested vlan tags in Rx path.
V2 changes:
* removed module parameter.
V3 changes:
* Users can enable or disable hardware VLAN acceleration using ethtool
Please apply it to net-next.
Jitendra Kalsaria (2):
qlge: Enhance nested VLAN (Q-in-Q) handling.
qlge: Update version to 1.00.00.33
drivers/net/ethernet/qlogic/qlge/qlge.h | 2 +-
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 126 +++++++++++++++++++++-----
2 files changed, 102 insertions(+), 26 deletions(-)
--
1.7.6.rc1.1.g2c162b
^ permalink raw reply
* Re: [PATCH net-next 0/2] netxen_nic: Minor enhancement
From: David Miller @ 2013-09-27 17:31 UTC (permalink / raw)
To: shahed.shaikh; +Cc: netdev, Dept-HSGLinuxNICDev
In-Reply-To: <1380260547-25903-1-git-send-email-shahed.shaikh@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
Date: Fri, 27 Sep 2013 01:42:25 -0400
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> This patch series contains following changes
> * Log a message about ULA adapter type.
> * Update the driver version to 4.0.82.
All applied, thank you.
^ permalink raw reply
* Re: [net v2 0/6][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-09-27 17:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1380285358-15685-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 27 Sep 2013 05:35:52 -0700
> This series contains updates to igb and i40e.
>
> Todd provides a fix for 82580 devices in igb, where the ethtool
> loopback test was missing 82580 copper devices.
>
> Jesse provides five fixes/cleanups to i40e based on feedback from
> Joe Perches and the community.
>
> v2: fixed up patch 5 in the series based on feedback from Joe Perches
> and David Miller
>
> The following are changes since commit f875691640cd3fa67f7ad1d3130ff9fa7fdca042:
> Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Toshiaki Makita @ 2013-09-27 17:11 UTC (permalink / raw)
To: vyasevic
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <52444322.40408@redhat.com>
On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
> > On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
> >> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
> >>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
> >>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
> >>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich wrote:
> >>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
> >>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich wrote:
> >>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
> >>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
> >>>>>>>>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>>>>>>>>> Date: Tue, 10 Sep 2013 19:27:54 +0900
> >>>>>>>>>>
> >>>>>>>>>>> There seem to be some undesirable behaviors related with PVID.
> >>>>>>>>>>> 1. It has no effect assigning PVID to a port. PVID cannot be applied
> >>>>>>>>>>> to any frame regardless of whether we set it or not.
> >>>>>>>>>>> 2. FDB entries learned via frames applied PVID are registered with
> >>>>>>>>>>> VID 0 rather than VID value of PVID.
> >>>>>>>>>>> 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
> >>>>>>>>>>> This leads interoperational problems such as sending frames with VID
> >>>>>>>>>>> 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
> >>>>>>>>>>> 0 as they belong to VLAN 0, which is expected to be handled as they have
> >>>>>>>>>>> no VID according to IEEE 802.1Q.
> >>>>>>>>>>>
> >>>>>>>>>>> Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
> >>>>>>>>>>> is fixed, because we cannot activate PVID due to it.
> >>>>>>>>>>
> >>>>>>>>>> Please work out the issues in patch #2 with Vlad and resubmit this
> >>>>>>>>>> series.
> >>>>>>>>>>
> >>>>>>>>>> Thank you.
> >>>>>>>>>
> >>>>>>>>> I'm hovering between whether we should fix the issue by changing vlan 0
> >>>>>>>>> interface behavior in 8021q module or enabling a bridge port to sending
> >>>>>>>>> priority-tagged frames, or another better way.
> >>>>>>>>>
> >>>>>>>>> If you could comment it, I'd appreciate it :)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> BTW, I think what is discussed in patch #2 is another problem about
> >>>>>>>>> handling priority-tags, and it exists without this patch set applied.
> >>>>>>>>> It looks like that we should prepare another patch set than this to fix
> >>>>>>>>> that problem.
> >>>>>>>>>
> >>>>>>>>> Should I include patches that fix the priority-tags problem in this
> >>>>>>>>> patch set and resubmit them all together?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I am thinking that we might need to do it in bridge and it looks like
> >>>>>>>> the simplest way to do it is to have default priority regeneration table
> >>>>>>>> (table 6-5 from 802.1Q doc).
> >>>>>>>>
> >>>>>>>> That way I think we would conform to the spec.
> >>>>>>>>
> >>>>>>>> -vlad
> >>>>>>>
> >>>>>>> Unfortunately I don't think the default priority regeneration table
> >>>>>>> resolves the problem because IEEE 802.1Q says that a VLAN-aware bridge
> >>>>>>> can transmit untagged or VLAN-tagged frames only (the end of section 7.5
> >>>>>>> and 8.1.7).
> >>>>>>>
> >>>>>>> No mechanism to send priority-tagged frames is found as far as I can see
> >>>>>>> the standard. I think the regenerated priority is used for outgoing PCP
> >>>>>>> field only if egress policy is not untagged (i.e. transmitting as
> >>>>>>> VLAN-tagged), and unused if untagged (Section 6.9.2 3rd/4th Paragraph).
> >>>>>>>
> >>>>>>> If we want to transmit priority-tagged frames from a bridge port, I
> >>>>>>> think we need to implement a new (optional) feature that is above the
> >>>>>>> standard, as I stated previously.
> >>>>>>>
> >>>>>>> How do you feel about adding a per-port policy that enables a bridge to
> >>>>>>> send priority-tagged frames instead of untagged frames when egress
> >>>>>>> policy for the port is untagged?
> >>>>>>> With this change, we can transmit frames for a given vlan as either all
> >>>>>>> untagged, all priority-tagged or all VLAN-tagged.
> >>>>>>
> >>>>>> That would work. What I am thinking is that we do it by special casing
> >>>>>> the vid 0 egress policy specification. Let it be untagged by default
> >>>>>> and if it is tagged, then we preserve the priority field and forward
> >>>>>> it on.
> >>>>>>
> >>>>>> This keeps the API stable and doesn't require user/admin from knowing
> >>>>>> exactly what happens. Default operation conforms to the spec and allows
> >>>>>> simple change to make it backward-compatible.
> >>>>>>
> >>>>>> What do you think. I've done a simple prototype of this an it seems to
> >>>>>> work with the VMs I am testing with.
> >>>>>
> >>>>> Are you saying that
> >>>>> - by default, set the 0th bit of untagged_bitmap; and
> >>>>> - if we unset the 0th bit and set the "vid"th bit, we transmit frames
> >>>>> classified as belonging to VLAN "vid" as priority-tagged?
> >>>>>
> >>>>> If so, though it's attractive to keep current API, I'm worried about if
> >>>>> it could be a bit confusing and not intuitive for kernel/iproute2
> >>>>> developers that VID 0 has a special meaning only in the egress policy.
> >>>>> Wouldn't it be better to adding a new member to struct net_port_vlans
> >>>>> instead of using VID 0 of untagged_bitmap?
> >>>>>
> >>>>> Or are you saying that we use a new flag in struct net_port_vlans but
> >>>>> use the BRIDGE_VLAN_INFO_UNTAGGED bit with VID 0 in netlink to set the
> >>>>> flag?
> >>>>>
> >>>>> Even in that case, I'm afraid that it might be confusing for developers
> >>>>> for the same reason. We are going to prohibit to specify VID with 0 (and
> >>>>> 4095) in adding/deleting a FDB entry or a vlan filtering entry, but it
> >>>>> would allow us to use VID 0 only when a vlan filtering entry is
> >>>>> configured.
> >>>>> I am thinking a new nlattr is a straightforward approach to configure
> >>>>> it.
> >>>>
> >>>> By making this an explicit attribute it makes vid 0 a special case for
> >>>> any automatic tool that would provision such filtering. Seeing vid 0
> >>>> would mean that these tools would have to know that this would have to
> >>>> be translated to a different attribute instead of setting the policy
> >>>> values.
> >>>
> >>> Yes, I agree with you that we can do it by the way you explained.
> >>> What I don't understand is the advantage of using vid 0 over another way
> >>> such as adding a new nlattr.
> >>> I think we can indicate transmitting priority-tags explicitly by such a
> >>> nlattr. Using vid 0 seems to be easier to implement than a new nlattr,
> >>> but, for me, it looks less intuitive and more difficult to maintain
> >>> because we have to care about vid 0 instead of simply ignoring it.
> >>>
> >>
> >> The point I am trying to make is that regardless of the approach someone
> >> has to know what to do when enabling priority tagged frames. You
> >> proposal would require the administrator or config tool to have that
> >> knowledge. Example is:
> >> Admin does: bridge vlan set priority on dev eth0
> >> Automated app:
> >> if (vid == 0)
> >> /* Turn on priority tagged frame support */
> >>
> >> My proposal would require the bridge filtering implementation to have it.
> >> user tool: bridge vlan add vid 0 tagged
> >> Automated app: No special case.
> >>
> >> IMO its better to have 1 piece code handling the special case then
> >> putting it multiple places.
> >
> > Thank you for the detailed explanation.
> > Now I understand your intention.
> >
> > I have one question about your proposal.
> > I guess the way to enable priority-tagged is something like
> > bridge vlan add vid 10 dev eth0
> > bridge vlan add vid 10 dev vnet0 pvid untagged
> > bridge vlan add vid 0 dev vnet0 tagged
> > where vnet0 has sub interface vnet0.0.
> >
> > Here the admin have to know the egress policy is applied to a frame
> > twice in a certain order when it is transmitted from the port vnet0
> > attached, that is, first, a frame with vid 10 get untagged, and then, an
> > untagged frame get priority-tagged.
> >
> > This behavior looks difficult to know without previous knowledge.
> > Any good idea to avoid such a need for the admin's additional knowledge?
>
> To me, the fact that there is vnet0.0 (or typically, there is eth0.0 in
> the guest or on the remote host) already tells the admin vlan 0 has to
> be tagged. The fact that we codify this in the policy makes it explicit.
My worry is that the admin might not be able to guess how to use bridge
commands to enable priority-tag without any additional hint in "man
bridge", "bridge vlan help", etc.
I actually couldn't hit upon such a usage before seeing example commands
you gave, because I had never think the egress policy could be applied
twice.
>
> However, I can see strong argument to be made for an addition egress
> policy attribute that could be for instance:
>
> bridge vlan add vid 10 dev eth0 pvid
> bridge vlan add vid 10 dev vnet0 pvid untagged prio_tag
>
> But this has the same connotations as wrt to egress policy. The 2
> policies are applied:
> (1) untag the frame.
> (2) add priority_tag.
>
> (2) only happens if initial fame received on eth0 was priority tagged.
If we do so, we will not be able to communicate using vlan 0 interface
under a certain circumstance.
Eth0 can be receive mixed untagged and priority-tagged frames according
to the network element it is connected to: for example, Open vSwitch can
send such two kinds of frames from the same port even if original
incoming frames belong to the same vlan.
In this situation, we can only receive frames that is priority-tagged
when received on eth0.
IMO, if prio_tag is configured, the bridge should send any untagged
frame as priority-tagged regardless of whatever it is on eth0.
>
> I think I am ok with either approach. Explicit vid 0 policy is easier
> for automatic provisioning. The flag based one is easier for admin/
> manual provisioning.
Supposing we have to add something to help or man in any case, I think
flag based is better.
The format below seems to suitable for a per-port policy.
bridge vlan set prio_tag on dev vnet0
Thanks,
Toshiaki Makita
>
> -vlad.
>
> -vlad
>
>
>
>
> >
> >>
> >> Thanks
> >> -vlad
> >>
> >>> Thanks,
> >>>
> >>> Toshiaki Makita
> >>>
> >>>>
> >>>> How it is implemented internally in the kernel isn't as big of an issue.
> >>>> We can do it as a separate flag or as part of existing policy.
> >>>>
> >>>> -vlad
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Toshiaki Makita
> >>>>>
> >>>>>>
> >>>>>> -vlad
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Toshiaki Makita
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Toshiaki Makita
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>>>>>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
> >
>
^ permalink raw reply
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Hannes Frederic Sowa @ 2013-09-27 17:03 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CA+ev272+Gp6Kt7S8P-wXxPBh0D8Di9WVH9NDi41HpNakLKC4Dw@mail.gmail.com>
On Fri, Sep 27, 2013 at 05:36:45PM +0100, Oussama Ghorbel wrote:
> Please see my comments below
>
> Regards,
> Oussama
>
> On Fri, Sep 27, 2013 at 11:58 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Fri, Sep 27, 2013 at 11:45:48AM +0100, Oussama Ghorbel wrote:
> >> The ip6_tunnel.c module would be then dependent on ip_tunnel.c and may
> >> be it would not be good thing?
> >
> > It could just be a static inline in some shared header. So there would
> > be no compile-time dependency.
> >
>
> The higher limit of mtu in ip_tunnel_change_mtu() is a calculated value.
> This high limit is calculated using the netdev priv struct ip_tunnel
> (field hlen).
> This netdev priv struct is different in ipv6, it's a ip6_tnl struct.
> Therefore implementing a beautiful function like
> ip_tunnel_valid_mtu(struct net_device *dev, int mtu) won't be
> feasible, unless we implement it in macro or something like like
> ip_tunnel_valid_mtu(struct net_device *dev, int hlen, int mtu) which
> seems not very nice ...
> What do yo think?
Ok, let's go with one function per protocol type. Seems easier.
It seems to get more hairy, because it depends on the tunnel driver if the
prepended ip header is accounted in hard_header_len. :/
I don't know if it works out cleanly. Otherwise I would be ok if the checks
just get repeated in ip6_tunnel and leave the rest as-is.
>
> >> As I have check in v3.10 there is no call from ip6_tunnel to ip_tunnel...
> >>
> >> For information, there is no check for the maximum MTU for ipv4 in the
> >> patch as this is not done for ipv6.
> >
> > I understand, but it would be better to limit the MTU here. There is a
> > (non-jumo) IPV6_MAXPLEN constant.
> >
> > Looking through the source it seems grev6 does actually check this,
> > so it would not hurt adding them here, too.
>
> what if jumbograms is used, in that case, we can't use IPV6_MAXPLEN.
> the limit would be the the full unsigned int.
> However checking the higher limit for ipv4 would be useful.
Linux currently cannot create "jumbograms" (only the receiving side
is supported).
> Please also note in case the tunnel mode is any (ipv4 or ipv6 means
> ip6_tnl.parms.proto = 0), then we will be required to take the most
> restrict limit from both ipv4 and ipv6 which means the lower limit
> will be 1280 and the higher limit will be about 65535
> Do you agree on this?
Agreed, this would be needed for e.g. the sit driver, which now can
handle both protocols.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v2.40 1/7] odp: Only pass vlan_tci to commit_vlan_action()
From: Ben Pfaff @ 2013-09-27 16:56 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1380241116-7661-2-git-send-email-horms@verge.net.au>
On Fri, Sep 27, 2013 at 09:18:30AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> This allows for future patches to pass different tci values to
> commit_vlan_action() without passing an entire flow structure.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Oussama Ghorbel @ 2013-09-27 16:36 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20130927105856.GF28287@order.stressinduktion.org>
Please see my comments below
Regards,
Oussama
On Fri, Sep 27, 2013 at 11:58 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Fri, Sep 27, 2013 at 11:45:48AM +0100, Oussama Ghorbel wrote:
>> The ip6_tunnel.c module would be then dependent on ip_tunnel.c and may
>> be it would not be good thing?
>
> It could just be a static inline in some shared header. So there would
> be no compile-time dependency.
>
The higher limit of mtu in ip_tunnel_change_mtu() is a calculated value.
This high limit is calculated using the netdev priv struct ip_tunnel
(field hlen).
This netdev priv struct is different in ipv6, it's a ip6_tnl struct.
Therefore implementing a beautiful function like
ip_tunnel_valid_mtu(struct net_device *dev, int mtu) won't be
feasible, unless we implement it in macro or something like like
ip_tunnel_valid_mtu(struct net_device *dev, int hlen, int mtu) which
seems not very nice ...
What do yo think?
>> As I have check in v3.10 there is no call from ip6_tunnel to ip_tunnel...
>>
>> For information, there is no check for the maximum MTU for ipv4 in the
>> patch as this is not done for ipv6.
>
> I understand, but it would be better to limit the MTU here. There is a
> (non-jumo) IPV6_MAXPLEN constant.
>
> Looking through the source it seems grev6 does actually check this,
> so it would not hurt adding them here, too.
what if jumbograms is used, in that case, we can't use IPV6_MAXPLEN.
the limit would be the the full unsigned int.
However checking the higher limit for ipv4 would be useful.
Please also note in case the tunnel mode is any (ipv4 or ipv6 means
ip6_tnl.parms.proto = 0), then we will be required to take the most
restrict limit from both ipv4 and ipv6 which means the lower limit
will be 1280 and the higher limit will be about 65535
Do you agree on this?
>
> Otherwise, I think your patch is fine.
>
> Greetings,
>
> Hannes
>
^ permalink raw reply
* [PATCH] bonding: Fix broken promiscuity reference counting issue
From: Neil Horman @ 2013-09-27 16:22 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Jay Vosburgh, Andy Gospodarek, Mark Wu,
David S. Miller
Recently grabbed this report:
https://bugzilla.redhat.com/show_bug.cgi?id=1005567
Of an issue in which the bonding driver, with an attached vlan encountered the
following errors when bond0 was taken down and back up:
dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
device might be broken.
The error occurs because, during __bond_release_one, if we release our last
slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
notification. With an attached vlan, the vlan may see that the vlan and bond
mac address were in sync, but no longer are. This triggers a call to dev_uc_add
and dev_set_rx_mode, which enables IFF_PROMISC on the bond device. Then, when
we complete __bond_release_one, we use the current state of the bond flags to
determine if we should decrement the promiscuity of the releasing slave. But
since the bond changed promiscuity state during the release operation, we
incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
to begin with, causing the above error
Fix is pretty simple, just cache the bonding flags at the start of the function
and use those when determining the need to set promiscuity.
This is also needed for the ALLMULTI flag
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Mark Wu <wudxw@linux.vnet.ibm.com>
CC: "David S. Miller" <davem@davemloft.net>
Reported-by: Mark Wu <wudxw@linux.vnet.ibm.com>
---
drivers/net/bonding/bond_main.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d5c3153..5373a8d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1710,6 +1710,7 @@ static int __bond_release_one(struct net_device *bond_dev,
struct bonding *bond = netdev_priv(bond_dev);
struct slave *slave, *oldcurrent;
struct sockaddr addr;
+ int old_flags = bond_dev->flags;
netdev_features_t old_features = bond_dev->features;
/* slave is not a slave or master is not master of this slave */
@@ -1841,12 +1842,18 @@ static int __bond_release_one(struct net_device *bond_dev,
* bond_change_active_slave(..., NULL)
*/
if (!USES_PRIMARY(bond->params.mode)) {
- /* unset promiscuity level from slave */
- if (bond_dev->flags & IFF_PROMISC)
+ /* unset promiscuity level from slave
+ * NOTE: The NETDEV_CHANGEADDR call above may change the value
+ * of the IFF_PROMISC flag in the bond_dev, but we need the
+ * value of that flag before that change, as that was the value
+ * when this slave was attached, so we cache at the start of the
+ * function and use it here. Same goes for ALLMULTI below
+ */
+ if (old_flags & IFF_PROMISC)
dev_set_promiscuity(slave_dev, -1);
/* unset allmulti level from slave */
- if (bond_dev->flags & IFF_ALLMULTI)
+ if (old_flags & IFF_ALLMULTI)
dev_set_allmulti(slave_dev, -1);
bond_hw_addr_flush(bond_dev, slave_dev);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file
From: Kumar Gala @ 2013-09-27 15:28 UTC (permalink / raw)
To: Aida Mynzhasova
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
richardcochran-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1380289227-12029-1-git-send-email-aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw@public.gmane.org>
On Sep 27, 2013, at 8:40 AM, Aida Mynzhasova wrote:
> Currently IEEE 1588 timer reference clock source is determined through
> hard-coded value in gianfar_ptp driver. This patch allows to select ptp
> clock source by means of device tree file node.
>
> For instance:
>
> fsl,cksel = <0>;
>
> for using external (TSEC_TMR_CLK input) high precision timer
> reference clock.
>
> Other acceptable values:
>
> <1> : eTSEC system clock
> <2> : eTSEC1 transmit clock
> <3> : RTC clock input
>
> When this attribute isn't used, eTSEC system clock will serve as
> IEEE 1588 timer reference clock.
>
> Signed-off-by: Aida Mynzhasova <aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 18 +++++++++++++++++-
> drivers/net/ethernet/freescale/gianfar_ptp.c | 4 +++-
> 2 files changed, 20 insertions(+), 2 deletions(-)
Acked-by: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
- k--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: question about map_read_chunks()
From: Tom Tucker @ 2013-09-27 15:23 UTC (permalink / raw)
To: Dan Carpenter
Cc: Tom Tucker, J. Bruce Fields, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130927122108.GF6247@mwanda>
Hi Dan,
On 9/27/13 7:21 AM, Dan Carpenter wrote:
> I have looked at this again, and I still worry that it looks like a bug.
> (remote security related blah blah blah).
>
> regards,
> dan carpenter
>
> On Mon, Feb 20, 2012 at 12:50:19PM +0300, Dan Carpenter wrote:
>> I had a couple questions about some map_read_chunks().
>>
>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>>
>> 150 ch_bytes = ntohl(ch->rc_target.rs_length);
>> ^^^^^^^^
>> It look like this is 32 bits from the network?
>>
>> 151 head->arg.head[0] = rqstp->rq_arg.head[0];
>> 152 head->arg.tail[0] = rqstp->rq_arg.tail[0];
>> 153 head->arg.pages = &head->pages[head->count];
>> 154 head->hdr_count = head->count; /* save count of hdr pages */
>> 155 head->arg.page_base = 0;
>> 156 head->arg.page_len = ch_bytes;
>> 157 head->arg.len = rqstp->rq_arg.len + ch_bytes;
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Can overflow.
>> 158 head->arg.buflen = rqstp->rq_arg.buflen + ch_bytes;
agreed.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Same. I didn't follow it through to see if an overflow matters. Does
>> it?
>>
>> 159 head->count++;
>> 160 chl_map->ch[0].start = 0;
>> 161 while (byte_count) {
>> 162 rpl_map->sge[sge_no].iov_base =
>> 163 page_address(rqstp->rq_arg.pages[page_no]) + page_off;
>> 164 sge_bytes = min_t(int, PAGE_SIZE-page_off, ch_bytes);
>> ^^^
>> This is the wrong cast to use. A large ch_bytes would be counted as a
>> negative value and get around the cap here.
True, but if we validate the wire data like we should, that's probably
not an issue.
>> 165 rpl_map->sge[sge_no].iov_len = sge_bytes;
>>
>> regards,
>> dan carpenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
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