* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Gleb Natapov @ 2015-01-06 19:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Greg Rose, Vlad Zolotarov, netdev, Avi Kivity, jeffrey.t.kirsher
In-Reply-To: <1420570744.5947.6.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Jan 06, 2015 at 10:59:04AM -0800, Eric Dumazet wrote:
> On Tue, 2015-01-06 at 20:04 +0200, Gleb Natapov wrote:
> > Is RSS hash security feature at all? Against what kind of attack? It
> > looks like some drivers (igb among them) use non random value for the key.
>
>
> Are you sure ? I thought I toko care of this already.
>
> For igb this was in :
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb31f8493eee1efcc194fdc98df830a503f572f1
>
Indeed. I looked in a couple of month old tree.
--
Gleb.
^ permalink raw reply
* Re: [PATCH net-next] Driver: Vmxnet3: Make Rx ring 2 size configurable
From: David Miller @ 2015-01-06 19:15 UTC (permalink / raw)
To: skhare; +Cc: sbhatewara, pv-drivers, netdev, linux-kernel, bollar
In-Reply-To: <1420564815-32101-1-git-send-email-skhare@vmware.com>
From: Shrikrishna Khare <skhare@vmware.com>
Date: Tue, 6 Jan 2015 09:20:15 -0800
> Rx ring 2 size can be configured by adjusting rx-jumbo parameter
> of ethtool -G.
>
> Signed-off-by: Ramya Bolla <bollar@vmware.com>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
> Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: cpsw: ignore VLAN ID 1
From: David Miller @ 2015-01-06 19:13 UTC (permalink / raw)
To: balbi; +Cc: netdev, linux-omap, stable, mugunthanvnm
In-Reply-To: <1420566212-30081-1-git-send-email-balbi@ti.com>
From: Felipe Balbi <balbi@ti.com>
Date: Tue, 6 Jan 2015 11:43:32 -0600
> CPSW completely hangs if we add, and later remove,
> VLAN ID #1. What happens is that after removing
> VLAN ID #1, no packets will be received by CPSW
> rendering network unusable.
>
> In order to "fix" the issue, we're returning -EINVAL
> if anybody tries to add VLAN ID #1. While at that,
> also filter out any ID > 4095 because we only have
> 12 bits for VLAN IDs.
>
> Fixes: 3b72c2f (drivers: net:ethernet: cpsw: add support for VLAN)
> Cc: <stable@vger.kernel.org> # v3.9+
> Cc: Mugunthan V N <mugunthanvnm@ti.com>
> Tested-by: Schuyler Patton <spatton@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
You can't just unilaterally make one VLAN ID unusable.
A better way to handle this situation must be found,
and if that means turning off hw VLAN support completely,
that's a much better alternative to this.
I'm not applying this patch, sorry.
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Jesse Gross @ 2015-01-06 19:11 UTC (permalink / raw)
To: Fan Du
Cc: Du, Fan, Thomas Graf, davem@davemloft.net, Michael S. Tsirkin,
Jason Wang, netdev@vger.kernel.org, fw@strlen.de,
dev@openvswitch.org, pshelar@nicira.com
In-Reply-To: <54ABAC13.9070402@gmail.com>
On Tue, Jan 6, 2015 at 4:34 AM, Fan Du <fengyuleidian0615@gmail.com> wrote:
>
> On 2015/1/6 1:58, Jesse Gross wrote:
>>
>> On Mon, Jan 5, 2015 at 1:02 AM, Fan Du <fengyuleidian0615@gmail.com>
>> wrote:
>>>
>>> 于 2014年12月03日 10:31, Du, Fan 写道:
>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Thomas Graf [mailto:tgr@infradead.org] On Behalf Of Thomas Graf
>>>>> Sent: Wednesday, December 3, 2014 1:42 AM
>>>>> To: Michael S. Tsirkin
>>>>> Cc: Du, Fan; 'Jason Wang'; netdev@vger.kernel.org; davem@davemloft.net;
>>>>> fw@strlen.de; dev@openvswitch.org; jesse@nicira.com; pshelar@nicira.com
>>>>> Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger
>>>>> than
>>>>> MTU
>>>>>
>>>>> On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
>>>>>>
>>>>>> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote:
>>>>>>>
>>>>>>> On 12/02/14 at 01:48pm, Flavio Leitner wrote:
>>>>>>>>
>>>>>>>> What about containers or any other virtualization environment that
>>>>>>>> doesn't use Virtio?
>>>>>>>
>>>>>>>
>>>>>>> The host can dictate the MTU in that case for both veth or OVS
>>>>>>> internal which would be primary container plumbing techniques.
>>>>>>
>>>>>>
>>>>>> It typically can't do this easily for VMs with emulated devices:
>>>>>> real ethernet uses a fixed MTU.
>>>>>>
>>>>>> IMHO it's confusing to suggest MTU as a fix for this bug, it's an
>>>>>> unrelated optimization.
>>>>>> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here.
>>>>>
>>>>>
>>>>> PMTU discovery only resolves the issue if an actual IP stack is running
>>>>> inside the
>>>>> VM. This may not be the case at all.
>>>>
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>> Some thoughts here:
>>>>
>>>> Think otherwise, this is indeed what host stack should forge a
>>>> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED
>>>> message with _inner_ skb network and transport header, do whatever type
>>>> of
>>>> encapsulation,
>>>> and thereafter push such packet upward to Guest/Container, which make
>>>> them
>>>> feel, the intermediate node
>>>> or the peer send such message. PMTU should be expected to work correct.
>>>> And such behavior should be shared by all other encapsulation tech if
>>>> they
>>>> are also suffered.
>>>
>>>
>>> Hi David, Jesse and Thomas
>>>
>>> As discussed in here:
>>> https://www.marc.info/?l=linux-netdev&m=141764712631150&w=4 and
>>> quotes from Jesse:
>>> My proposal would be something like this:
>>> * For L2, reduce the VM MTU to the lowest common denominator on the
>>> segment.
>>> * For L3, use path MTU discovery or fragment inner packet (i.e.
>>> normal routing behavior).
>>> * As a last resort (such as if using an old version of virtio in the
>>> guest), fragment the tunnel packet.
>>>
>>>
>>> For L2, it's a administrative action
>>> For L3, PMTU approach looks better, because once the sender is alerted
>>> the
>>> reduced MTU,
>>> packet size after encapsulation will not exceed physical MTU, so no
>>> additional fragments
>>> efforts needed.
>>> For "As a last resort... fragment the tunnel packet", the original patch:
>>> https://www.marc.info/?l=linux-netdev&m=141715655024090&w=4 did the job,
>>> but
>>> seems it's
>>> not welcomed.
>>
>> This needs to be properly integrated into IP processing if it is to
>> work correctly.
>
> Do you mean the original patch in this thread? yes, it works correctly
> in my cloud env. If you has any other concerns, please let me know. :)
Ok...but that doesn't actually address the points that I made.
>> One of the reasons for only doing path MTU discovery
>> for L3 is that it operates seamlessly as part of normal operation -
>> there is no need to forge addresses or potentially generate ICMP when
>> on an L2 network. However, this ignores the IP handling that is going
>> on (note that in OVS it is possible for L3 to be implemented as a set
>> of flows coming from a controller).
>>
>> It also should not be VXLAN specific or duplicate VXLAN encapsulation
>> code. As this is happening before encapsulation, the generated ICMP
>> does not need to be encapsulated either if it is created in the right
>> location.
>
> Yes, I agree. GRE share the same issue from the code flow.
> Pushing back ICMP msg back without encapsulation without circulating down
> to physical device is possible. The "right location" as far as I know
> could only be in ovs_vport_send. In addition this probably requires wrapper
> route looking up operation for GRE/VXLAN, after get the under layer device
> MTU
> from the routing information, then calculate reduced MTU becomes feasible.
As I said, it needs to be integrated into L3 processing. In OVS this
would mean adding some primitives to the kernel and then exposing the
functionality upwards into userspace/controller.
^ permalink raw reply
* Re: TCP connection issues against Amazon S3
From: Erik Grinaker @ 2015-01-06 19:01 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Eric Dumazet, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <CAK6E8=d5Z0W5sSAdeEcecKbqjj_UwGw4949=a20fetFpLVKwwA@mail.gmail.com>
> On 06 Jan 2015, at 18:33, Yuchung Cheng <ycheng@google.com> wrote:
>
> On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker <erik@bengler.no> wrote:
>>
>>> On 06 Jan 2015, at 17:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Tue, 2015-01-06 at 16:11 +0000, Erik Grinaker wrote:
>>>>> On 06 Jan 2015, at 16:04, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>> On Tue, 2015-01-06 at 15:14 +0000, Erik Grinaker wrote:
>>>>>> (CCing Yuchung, as his name comes up in the relevant commits)
>>>>>>
>>>>>> After upgrading from Ubuntu 12.04.5 to 14.04.1 we have begun seeing
>>>>>> intermittent TCP connection hangs for HTTP image requests against
>>>>>> Amazon S3. 3-5% of requests will suddenly stall in the middle of the
>>>>>> transfer before timing out. We see this problem across a range of
>>>>>> servers, in several data centres and networks, all located in Norway.
>>>>>>
>>>>>> A packet dump [1] shows repeated ACK retransmits for some of the
> TCP does not retransmit ACK ... do you mean DUPACKs sent by the receiver?
Ah, sorry, they are indeed DUPACKs; I thought they were the same thing.
> I am trying to understand the problem. Could you confirm that it's the
> HTTP responses sent from Amazon S3 got stalled, or HTTP requests sent
> from the receiver (your host)?
Yes. We run HTTP GET requests against S3 for images (typically a few megs in size). Once in a while, the response transfer stalls about halfway through, until the client (Curl) times out. The packet dump shows loads of DUPACKs early on, then TCP retransmissions until the connection is closed.
> btw I suspect some middleboxes are stripping SACKOK options from your
> SYNs (or Amazon SYN-ACKs) assuming Amazon supports SACK.
That may be. I just tested this on a server in the Netherlands, and I can not reproduce the problem there, while I can reproduce it from multiple locations and ISPs in Norway. Would it be helpful to have a packet dump from the functioning Netherlands server as well?
>>>>>> requests. Using Ubuntu mainline kernels, we found the problem to have
>>>>>> been introduced between 3.11.10 and 3.12.0, possibly in
>>>>>> 0f7cc9a3c2bd89b15720dbf358e9b9e62af27126. The problem is also present
>>>>>> in 3.18.1. Disabling tcp_window_scaling seems to solve it, but has
>>>>>> obvious drawbacks for transfer speeds. Other sysctls do not seem to
>>>>>> affect it.
>>>>>>
>>>>>> I am not sure if this is fundamentally a kernel bug or a network
>>>>>> issue, but we did not see this problem with older kernels.
>>>>>>
>>>>>> [1] http://abstrakt.bengler.no/tcp-issues-s3.pcap.bz2
>>>>>
>>>>>
>>>>> CC netdev
>>>>>
>>>>> This looks like the bug we fixed here :
>>>>>
>>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=39bb5e62867de82b269b07df900165029b928359
>>>>
>>>> Has that patch gone into a release? Because the problem persists with 3.18.1.
>>>
>>> Patch is in 3.18.1 yes.
>>>
>>> So thats a separate issue.
>>>
>>> Can you confirm pcap was taken at receiver (195.159.221.106), not sender
>>> (54.231.136.74) , and on which host is running the 'buggy kernel' ?
>>
>> Yes, pcap was taken on receiver (195.159.221.106).
>>
>>> If the sender is broken, changing the kernel on receiver wont help.
>>>
>>> BTW not using sack (on 54.231.132.98) is terrible for performance in
>>> lossy environments.
>>
>> It may well be that the sender is broken; however, the sender is Amazon S3, so I do not have any control over it. And in any case, the problem goes away with 3.11.10 on receiver, but persists with 3.12.0 (or later) on receiver, so there must be some change in 3.12.0 which has caused this to trigger.
>>
>> If you are confident that the problem is with Amazon, I can get in touch with their engineering department.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Eric Dumazet @ 2015-01-06 18:59 UTC (permalink / raw)
To: Gleb Natapov
Cc: Greg Rose, Vlad Zolotarov, netdev, Avi Kivity, jeffrey.t.kirsher
In-Reply-To: <20150106180455.GB29721@cloudius-systems.com>
On Tue, 2015-01-06 at 20:04 +0200, Gleb Natapov wrote:
> Is RSS hash security feature at all? Against what kind of attack? It
> looks like some drivers (igb among them) use non random value for the key.
Are you sure ? I thought I toko care of this already.
For igb this was in :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb31f8493eee1efcc194fdc98df830a503f572f1
^ permalink raw reply
* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Gleb Natapov @ 2015-01-06 18:44 UTC (permalink / raw)
To: Greg Rose; +Cc: Vlad Zolotarov, netdev, Avi Kivity, jeffrey.t.kirsher, davem
In-Reply-To: <CALgkqUpsw3ZBi600tC5H-8LJKLrOgSAX=0+xU4V=aMAGacEEUQ@mail.gmail.com>
On Tue, Jan 06, 2015 at 10:30:59AM -0800, Greg Rose wrote:
> On Tue, Jan 6, 2015 at 10:04 AM, Gleb Natapov <gleb@cloudius-systems.com> wrote:
> > On Tue, Jan 06, 2015 at 08:59:41AM -0800, Greg Rose wrote:
> >> On Tue, Jan 6, 2015 at 2:58 AM, Vlad Zolotarov
> >> <vladz@cloudius-systems.com> wrote:
> >> >
> >> >
> >> > I agree with Gleb here: when we started with just thinking about the idea of
> >> > this patch the possible security issue was the first thing that came into
> >> > our minds.
> >> > But eventually we couldn't come up with any security risk or attack example
> >> > that is exclusively caused by the fact that VF knows the indirection table
> >> > and/or RSS hash key of the PF.
> >> >
> >> > So, Greg, if we have missed anything and your have such an example could you
> >> > share it here, please?
> >>
> >> I don't have any examples and that is not my area of expertise. But
> >> just because we can't think of a security risk or attack example
> >> doesn't mean there isn't one.
> >>
> > Is RSS hash security feature at all? Against what kind of attack? It
> > looks like some drivers (igb among them) use non random value for the key.
>
> I don't believe RSS hashing itself is a security feature - I don't
> know that sharing the RSS info with a VF is a security risk. I'm just
> asking that we preserve default behavior to avoid the possibility.
>
> >
> >> Just add a policy hook so that the system admin can decide whether
> >> this information should be shared with the VFs and then we're covered
> >> for cases of both known and unknown exploits, risks, etc.
> >>
> > Default off means that it will stay that way for most installations and
> > information will not be available for "cloud" users. It is hard to get
> > proper support on public cloud for less trivial issues than changing
> > host HW configuration.
>
> Someone in the host is configuring the VF HW to begin with. Someone
> had to create the VFs in the first place so I presume they could set
> the policy for this feature as well at the same time. To return to an
> example I provided to Vlad - anti-spoof checking is on by default but
> we allow system admins to turn it off so that other features, such as
> bonding, can be used. I just want to preserve current behavior while
> allowing the feature you want to add to be available for those who
> want it.
>
> If Dave and the rest of community feel that there is no risk to these
> patches and that they should be applied then I'll go away and shut up
> about it. But for now I'm just approaching this from a "better safe
> than sorry" viewpoint.
>
Thanks Greg for explaining your position clearly on this matter. I CCed
Dave to get his opinion. Vlad is going to work on adding this knob
anyway meanwhile, but we still have a hope that default could be "on".
--
Gleb.
^ permalink raw reply
* Re: [PATCH 11/28] net: wireless: ath: ath5k: drop owner assignment from platform_drivers
From: Kalle Valo @ 2015-01-06 18:41 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-kernel, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
linux-wireless, ath5k-devel, netdev
In-Reply-To: <1419196495-9626-12-git-send-email-wsa@the-dreams.de>
Wolfram Sang <wsa@the-dreams.de> writes:
> This platform_driver does not need to set an owner, it will be populated by the
> driver core.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> ---
> Generated with coccinelle. SmPL file is in the introductory msg. The big
> cleanup was pulled in this merge window. This series catches the bits fallen
> through. The patches shall go in via the subsystem trees.
Thanks, applied to wireless-drivers-next.git. But I simplified the patch
title:
c0c3163a7213 ath5k: drop owner assignment from platform_drivers
--
Kalle Valo
^ permalink raw reply
* Re: TCP connection issues against Amazon S3
From: Yuchung Cheng @ 2015-01-06 18:33 UTC (permalink / raw)
To: Erik Grinaker; +Cc: Eric Dumazet, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <8C4F7938-DCA1-46F5-A3C9-7DF62511DEE7@bengler.no>
On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker <erik@bengler.no> wrote:
>
>> On 06 Jan 2015, at 17:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Tue, 2015-01-06 at 16:11 +0000, Erik Grinaker wrote:
>>>> On 06 Jan 2015, at 16:04, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>> On Tue, 2015-01-06 at 15:14 +0000, Erik Grinaker wrote:
>>>>> (CCing Yuchung, as his name comes up in the relevant commits)
>>>>>
>>>>> After upgrading from Ubuntu 12.04.5 to 14.04.1 we have begun seeing
>>>>> intermittent TCP connection hangs for HTTP image requests against
>>>>> Amazon S3. 3-5% of requests will suddenly stall in the middle of the
>>>>> transfer before timing out. We see this problem across a range of
>>>>> servers, in several data centres and networks, all located in Norway.
>>>>>
>>>>> A packet dump [1] shows repeated ACK retransmits for some of the
TCP does not retransmit ACK ... do you mean DUPACKs sent by the receiver?
I am trying to understand the problem. Could you confirm that it's the
HTTP responses sent from Amazon S3 got stalled, or HTTP requests sent
from the receiver (your host)?
btw I suspect some middleboxes are stripping SACKOK options from your
SYNs (or Amazon SYN-ACKs) assuming Amazon supports SACK.
>>>>> requests. Using Ubuntu mainline kernels, we found the problem to have
>>>>> been introduced between 3.11.10 and 3.12.0, possibly in
>>>>> 0f7cc9a3c2bd89b15720dbf358e9b9e62af27126. The problem is also present
>>>>> in 3.18.1. Disabling tcp_window_scaling seems to solve it, but has
>>>>> obvious drawbacks for transfer speeds. Other sysctls do not seem to
>>>>> affect it.
>>>>>
>>>>> I am not sure if this is fundamentally a kernel bug or a network
>>>>> issue, but we did not see this problem with older kernels.
>>>>>
>>>>> [1] http://abstrakt.bengler.no/tcp-issues-s3.pcap.bz2
>>>>
>>>>
>>>> CC netdev
>>>>
>>>> This looks like the bug we fixed here :
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=39bb5e62867de82b269b07df900165029b928359
>>>
>>> Has that patch gone into a release? Because the problem persists with 3.18.1.
>>
>> Patch is in 3.18.1 yes.
>>
>> So thats a separate issue.
>>
>> Can you confirm pcap was taken at receiver (195.159.221.106), not sender
>> (54.231.136.74) , and on which host is running the 'buggy kernel' ?
>
> Yes, pcap was taken on receiver (195.159.221.106).
>
>> If the sender is broken, changing the kernel on receiver wont help.
>>
>> BTW not using sack (on 54.231.132.98) is terrible for performance in
>> lossy environments.
>
> It may well be that the sender is broken; however, the sender is Amazon S3, so I do not have any control over it. And in any case, the problem goes away with 3.11.10 on receiver, but persists with 3.12.0 (or later) on receiver, so there must be some change in 3.12.0 which has caused this to trigger.
>
> If you are confident that the problem is with Amazon, I can get in touch with their engineering department.
^ permalink raw reply
* Re: TCP connection issues against Amazon S3
From: Eric Dumazet @ 2015-01-06 18:32 UTC (permalink / raw)
To: Erik Grinaker; +Cc: linux-kernel, Yuchung Cheng, netdev
In-Reply-To: <8C4F7938-DCA1-46F5-A3C9-7DF62511DEE7@bengler.no>
On Tue, 2015-01-06 at 18:17 +0000, Erik Grinaker wrote:
> Yes, pcap was taken on receiver (195.159.221.106).
>
> > If the sender is broken, changing the kernel on receiver wont help.
> >
> > BTW not using sack (on 54.231.132.98) is terrible for performance in
> > lossy environments.
>
> It may well be that the sender is broken; however, the sender is
> Amazon S3, so I do not have any control over it. And in any case, the
> problem goes away with 3.11.10 on receiver, but persists with 3.12.0
> (or later) on receiver, so there must be some change in 3.12.0 which
> has caused this to trigger.
In fact I saw nothing obviously wrong in pcap (but I have not done a
full analysis)
It might simply be an application bug, triggering a timeout too soon.
A kernel change can be good, but by changing timings a bit, trigger
application bugs.
^ permalink raw reply
* Re: [net 1/3] i40e: fix un-necessary Tx hangs
From: David Miller @ 2015-01-06 18:31 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: jeffrey.t.kirsher, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20150106090440.00006a7d@unknown>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Tue, 6 Jan 2015 09:04:40 -0800
> Dave, sorry to do this but we discovered a bug in this patch (where
> this patch impacts performance) and didn't interrupt Jeff before he sent
> it (my mistake) I will prep a v2 for Jeff.
>
> Please do not apply.
Ok.
^ permalink raw reply
* Re: [net 0/3][pull request] Intel Wired LAN Driver Updates 2015-01-06
From: David Miller @ 2015-01-06 18:31 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1420533864-13125-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 6 Jan 2015 00:44:21 -0800
> This series contains fixes to i40e only.
>
> Jesse provides a fix for when the driver was polling with interrupts
> disabled the hardware would occasionally not write back descriptors.
> His fix causes the driver to detect this situation and force an interrupt
> to fire which will flush the stuck descriptor.
>
> Anjali provides a couple of fixes, the first corrects an issue where
> the receive port checksum error counter was incrementing incorrectly with
> UDP encapsulated tunneled traffic. The second fix resolves an issue where
> the driver was examining the outer protocol layer to set the inner protocol
> layer checksum offload. In the case of TCP over IPv6 over an IPv4 based
> VXLAN, the inner checksum offloads would be set to look for IPv4/UDP
> instead of IPv6/TCP, so fixed the issue so that the driver will look at
> the proper layer for encapsulation offload settings.
Not pulled, waiting for a respin with the fix for patch #1, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Greg Rose @ 2015-01-06 18:30 UTC (permalink / raw)
To: Gleb Natapov; +Cc: Vlad Zolotarov, netdev, Avi Kivity, jeffrey.t.kirsher
In-Reply-To: <20150106180455.GB29721@cloudius-systems.com>
On Tue, Jan 6, 2015 at 10:04 AM, Gleb Natapov <gleb@cloudius-systems.com> wrote:
> On Tue, Jan 06, 2015 at 08:59:41AM -0800, Greg Rose wrote:
>> On Tue, Jan 6, 2015 at 2:58 AM, Vlad Zolotarov
>> <vladz@cloudius-systems.com> wrote:
>> >
>> >
>> > I agree with Gleb here: when we started with just thinking about the idea of
>> > this patch the possible security issue was the first thing that came into
>> > our minds.
>> > But eventually we couldn't come up with any security risk or attack example
>> > that is exclusively caused by the fact that VF knows the indirection table
>> > and/or RSS hash key of the PF.
>> >
>> > So, Greg, if we have missed anything and your have such an example could you
>> > share it here, please?
>>
>> I don't have any examples and that is not my area of expertise. But
>> just because we can't think of a security risk or attack example
>> doesn't mean there isn't one.
>>
> Is RSS hash security feature at all? Against what kind of attack? It
> looks like some drivers (igb among them) use non random value for the key.
I don't believe RSS hashing itself is a security feature - I don't
know that sharing the RSS info with a VF is a security risk. I'm just
asking that we preserve default behavior to avoid the possibility.
>
>> Just add a policy hook so that the system admin can decide whether
>> this information should be shared with the VFs and then we're covered
>> for cases of both known and unknown exploits, risks, etc.
>>
> Default off means that it will stay that way for most installations and
> information will not be available for "cloud" users. It is hard to get
> proper support on public cloud for less trivial issues than changing
> host HW configuration.
Someone in the host is configuring the VF HW to begin with. Someone
had to create the VFs in the first place so I presume they could set
the policy for this feature as well at the same time. To return to an
example I provided to Vlad - anti-spoof checking is on by default but
we allow system admins to turn it off so that other features, such as
bonding, can be used. I just want to preserve current behavior while
allowing the feature you want to add to be available for those who
want it.
If Dave and the rest of community feel that there is no risk to these
patches and that they should be applied then I'll go away and shut up
about it. But for now I'm just approaching this from a "better safe
than sorry" viewpoint.
Thanks,
- Greg
>
> --
> Gleb.
^ permalink raw reply
* Re: [PATCH net] r8152: support ndo_features_check
From: David Miller @ 2015-01-06 18:30 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-113-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Tue, 6 Jan 2015 17:41:58 +0800
> Support ndo_features_check to avoid:
> - the transport offset is more than the hw limitation when using hw checksum.
> - the skb->len of a GSO packet is more than the limitation.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied, thanks.
^ permalink raw reply
* Re: pull-request: mac80211 2015-01-06
From: David Miller @ 2015-01-06 18:30 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420546548.1966.26.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 06 Jan 2015 13:15:48 +0100
> Here's just a single fix - a revert of a patch that broke the
> p54 and cw2100 drivers (arguably due to bad assumptions there.)
> Since this affects kernels since 3.17, I decided to revert for
> now and we'll revisit this optimisation properly for -next.
Pulled, thanks Johannes.
> Also -- happy New Year, and sorry about the genl issue :(
No problem.
> I'm still a bit confused about whether you wanted the pull request with
> the text in the email or in the tag, or branch, or something - I
> interpreted what you said to Kalle differently to what you said to me.
> I've duplicated it for now :)
If you put it in the tag, that's fine, I'll just add my signoff to
it.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add PCI device ID for new T5 adapter
From: David Miller @ 2015-01-06 18:27 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan
In-Reply-To: <1420545706-13763-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 6 Jan 2015 17:31:46 +0530
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] arm_arch_timer: include clocksource.h directly
From: David Miller @ 2015-01-06 18:27 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, linux-kernel, linux
In-Reply-To: <1420550773-6752-1-git-send-email-richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 6 Jan 2015 14:26:13 +0100
> This driver makes use of the clocksource code. Previously it had only
> included the proper header indirectly, but that chain was inadvertently
> broken by 74d23cc "time: move the timecounter/cyclecounter code into its
> own file."
>
> This patch fixes the issue by including clocksource.h directly.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Greg Rose @ 2015-01-06 18:22 UTC (permalink / raw)
To: Vlad Zolotarov; +Cc: Gleb Natapov, netdev, Avi Kivity, jeffrey.t.kirsher
In-Reply-To: <54AC1BBA.3010206@cloudius-systems.com>
I accidentally replied just to Vlad - here is a reply to all.
On Tue, Jan 6, 2015 at 9:30 AM, Vlad Zolotarov
<vladz@cloudius-systems.com> wrote:
>
> On 01/06/15 18:59, Greg Rose wrote:
>>
[snip]
>>
>> I don't have any examples and that is not my area of expertise. But
>> just because we can't think of a security risk or attack example
>> doesn't mean there isn't one.
>>
>> Just add a policy hook so that the system admin can decide whether
>> this information should be shared with the VFs and then we're covered
>> for cases of both known and unknown exploits, risks, etc.
>
>
> I absolutely disagree with u in regard of defining an RSS redirection table
> and RSS hash key as a security sensitive data. I don't know how u got to
> this conclusion.
I have not reached any such conclusion - let me reiterate: I have no
idea. It is not my area of expertise. However, to take the lowest
risk route just add a policy hook so that a system admin can turn the
feature on through the PF driver (which is acknowledged as secure) if
they wish then there is no worry.
> However I don't want to argue about any longer. Let's move on.
>
> Let's clarify one thing about this "hook". Do u agree that it should cover
> only the cases when VF shares the mentioned above data with PF - namely for
> all devices but x550?
Look at how spoof checking is turned off/on for each VF using the "ip
link set" commands. That's what I'm envisioning - some way to decide
on a per VF basis which VFs should be allowed to perform the query.
Thanks,
- Greg
^ permalink raw reply
* Re: [PATCH] b43legacy: Remove unused function
From: Rafał Miłecki @ 2015-01-06 18:19 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Larry Finger, Stefano Brivio, Network Development,
linux-wireless@vger.kernel.org, Linux Kernel Mailing List,
b43-dev
In-Reply-To: <1420567175-17323-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On 6 January 2015 at 18:59, Rickard Strandqvist
<rickard_strandqvist@spectrumdigital.se> wrote:
> Remove the function b43legacy_radio_set_tx_iq() that is not used anywhere.
>
> This was partially found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
^ permalink raw reply
* Re: TCP connection issues against Amazon S3
From: Erik Grinaker @ 2015-01-06 18:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, Yuchung Cheng, netdev
In-Reply-To: <1420564837.32621.30.camel@edumazet-glaptop2.roam.corp.google.com>
> On 06 Jan 2015, at 17:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2015-01-06 at 16:11 +0000, Erik Grinaker wrote:
>>> On 06 Jan 2015, at 16:04, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Tue, 2015-01-06 at 15:14 +0000, Erik Grinaker wrote:
>>>> (CCing Yuchung, as his name comes up in the relevant commits)
>>>>
>>>> After upgrading from Ubuntu 12.04.5 to 14.04.1 we have begun seeing
>>>> intermittent TCP connection hangs for HTTP image requests against
>>>> Amazon S3. 3-5% of requests will suddenly stall in the middle of the
>>>> transfer before timing out. We see this problem across a range of
>>>> servers, in several data centres and networks, all located in Norway.
>>>>
>>>> A packet dump [1] shows repeated ACK retransmits for some of the
>>>> requests. Using Ubuntu mainline kernels, we found the problem to have
>>>> been introduced between 3.11.10 and 3.12.0, possibly in
>>>> 0f7cc9a3c2bd89b15720dbf358e9b9e62af27126. The problem is also present
>>>> in 3.18.1. Disabling tcp_window_scaling seems to solve it, but has
>>>> obvious drawbacks for transfer speeds. Other sysctls do not seem to
>>>> affect it.
>>>>
>>>> I am not sure if this is fundamentally a kernel bug or a network
>>>> issue, but we did not see this problem with older kernels.
>>>>
>>>> [1] http://abstrakt.bengler.no/tcp-issues-s3.pcap.bz2
>>>
>>>
>>> CC netdev
>>>
>>> This looks like the bug we fixed here :
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=39bb5e62867de82b269b07df900165029b928359
>>
>> Has that patch gone into a release? Because the problem persists with 3.18.1.
>
> Patch is in 3.18.1 yes.
>
> So thats a separate issue.
>
> Can you confirm pcap was taken at receiver (195.159.221.106), not sender
> (54.231.136.74) , and on which host is running the 'buggy kernel' ?
Yes, pcap was taken on receiver (195.159.221.106).
> If the sender is broken, changing the kernel on receiver wont help.
>
> BTW not using sack (on 54.231.132.98) is terrible for performance in
> lossy environments.
It may well be that the sender is broken; however, the sender is Amazon S3, so I do not have any control over it. And in any case, the problem goes away with 3.11.10 on receiver, but persists with 3.12.0 (or later) on receiver, so there must be some change in 3.12.0 which has caused this to trigger.
If you are confident that the problem is with Amazon, I can get in touch with their engineering department.
^ permalink raw reply
* Re: [PATCH] net: wireless: rtlwifi: btcoexist: halbtc8821a2ant: Remove some unused functions
From: Kalle Valo @ 2015-01-06 18:14 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Larry Finger, Chaoming Li, Greg Kroah-Hartman, Fengguang Wu,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1420230361-1862-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> writes:
> Removes some functions that are not used anywhere:
> ex_halbtc8821a2ant_periodical() ex_halbtc8821a2ant_halt_notify()
> ex_halbtc8821a2ant_bt_info_notify()
> ex_halbtc8821a2ant_special_packet_notify()
> ex_halbtc8821a2ant_connect_notify() ex_halbtc8821a2ant_scan_notify()
> ex_halbtc8821a2ant_lps_notify() ex_halbtc8821a2ant_ips_notify()
> ex_halbtc8821a2ant_display_coex_info() ex_halbtc8821a2ant_init_coex_dm()
> ex_halbtc8821a2ant_init_hwconfig()
>
> This was partially found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Rickard, I have dropped all your patches because I lost track which I
should apply and which not and I do not want to waste half an hour
figuring out. Please resend the ones which are still valid.
And to make it easier for everyone please group these wireless-drivers
cleanup patches into a larger patchset (like 10-15 patches max per
patchset). That way it's a lot easier for me tomanage them. Sending one
patch a day is not recommended, especially when we are talking trivial
cleanup patches like this.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Gleb Natapov @ 2015-01-06 18:04 UTC (permalink / raw)
To: Greg Rose; +Cc: Vlad Zolotarov, netdev, Avi Kivity, jeffrey.t.kirsher
In-Reply-To: <CALgkqUqh4uMxhnTA9yOm2m0Z3tOZ1E2+Z8Y68Kv5HJ6vP=Fk2A@mail.gmail.com>
On Tue, Jan 06, 2015 at 08:59:41AM -0800, Greg Rose wrote:
> On Tue, Jan 6, 2015 at 2:58 AM, Vlad Zolotarov
> <vladz@cloudius-systems.com> wrote:
> >
> > On 01/06/15 08:55, Gleb Natapov wrote:
> >>
> >> On Mon, Jan 05, 2015 at 03:54:52PM -0800, Greg Rose wrote:
> >>>
> >>> On Mon, Jan 5, 2015 at 6:15 AM, Vlad Zolotarov
> >>> <vladz@cloudius-systems.com> wrote:
> >>>>
> >>>> Add the ethtool ops to VF driver to allow querying the RSS indirection
> >>>> table
> >>>> and RSS Random Key.
> >>>>
> >>>> - PF driver: Add new VF-PF channel commands.
> >>>> - VF driver: Utilize these new commands and add the corresponding
> >>>> ethtool callbacks.
> >>>>
> >>>> New in v3:
> >>>> - Added a missing support for x550 devices.
> >>>> - Mask the indirection table values according to PSRTYPE[n].RQPL.
> >>>> - Minimized the number of added VF-PF commands.
> >>>>
> >>>> New in v2:
> >>>> - Added a detailed description to patches 4 and 5.
> >>>>
> >>>> New in v1 (compared to RFC):
> >>>> - Use "if-else" statement instead of a "switch-case" for a single
> >>>> option case.
> >>>> More specifically: in cases where the newly added API version is
> >>>> the only one
> >>>> allowed. We may consider using a "switch-case" back again when the
> >>>> list of
> >>>> allowed API versions in these specific places grows up.
> >>>>
> >>>> Vlad Zolotarov (5):
> >>>> ixgbe: Add a RETA query command to VF-PF channel API
> >>>> ixgbevf: Add a RETA query code
> >>>> ixgbe: Add GET_RSS_KEY command to VF-PF channel commands set
> >>>> ixgbevf: Add RSS Key query code
> >>>> ixgbevf: Add the appropriate ethtool ops to query RSS indirection
> >>>> table and key
> >>>>
> >>>> drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 10 ++
> >>>> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 91
> >>>> +++++++++++++++
> >>>> drivers/net/ethernet/intel/ixgbevf/ethtool.c | 43 +++++++
> >>>> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 +-
> >>>> drivers/net/ethernet/intel/ixgbevf/mbx.h | 10 ++
> >>>> drivers/net/ethernet/intel/ixgbevf/vf.c | 132
> >>>> ++++++++++++++++++++++
> >>>> drivers/net/ethernet/intel/ixgbevf/vf.h | 2 +
> >>>> 7 files changed, 291 insertions(+), 1 deletion(-)
> >>>
> >>> I've given this code a review and I don't see a way to
> >>> set a policy in the PF driver as to whether this request should be
> >>> allowed or not. We cannot enable this query by default - it is a
> >>> security risk. To make this acceptable you need to do a
> >>> couple of things.
> >>>
> >> Can you please elaborate on the security risk this information poses?
> >> Is toeplitz hash function cryptographically strong enough so that VF
> >> cannot reconstruct the hash key from hash result provided in packet
> >> descriptor? The abstract of this paper [1] claims it is not, but I do
> >> not have access to the full article unfortunately hence the question.
> >>
> >> [1]
> >> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5503170&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5503170
> >
> >
> > I agree with Gleb here: when we started with just thinking about the idea of
> > this patch the possible security issue was the first thing that came into
> > our minds.
> > But eventually we couldn't come up with any security risk or attack example
> > that is exclusively caused by the fact that VF knows the indirection table
> > and/or RSS hash key of the PF.
> >
> > So, Greg, if we have missed anything and your have such an example could you
> > share it here, please?
>
> I don't have any examples and that is not my area of expertise. But
> just because we can't think of a security risk or attack example
> doesn't mean there isn't one.
>
Is RSS hash security feature at all? Against what kind of attack? It
looks like some drivers (igb among them) use non random value for the key.
> Just add a policy hook so that the system admin can decide whether
> this information should be shared with the VFs and then we're covered
> for cases of both known and unknown exploits, risks, etc.
>
Default off means that it will stay that way for most installations and
information will not be available for "cloud" users. It is hard to get
proper support on public cloud for less trivial issues than changing
host HW configuration.
--
Gleb.
^ permalink raw reply
* Re: route/max_size sysctl in ipv4
From: Eric Dumazet @ 2015-01-06 18:09 UTC (permalink / raw)
To: Ani Sinha; +Cc: Pádraig Brady, David Miller, netdev@vger.kernel.org
In-Reply-To: <CAOxq_8O-YME=m9NnCQ7hPWjr6jWqcqUkgeqM=ZY6VW+icNsO2g@mail.gmail.com>
On Tue, 2015-01-06 at 09:11 -0800, Ani Sinha wrote:
> Why can't se simply change the documentation to reflect the fact that
> this sysctl is no longer in operation?
It is still in operation for IPv6
Looks like you propose to update the documentation.
This is great !
Why don't you send an official patch ?
^ permalink raw reply
* Re: [PATCH] b43legacy: Remove unused function
From: Larry Finger @ 2015-01-06 18:08 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Kalle Valo, linux-wireless, b43-dev, netdev, linux-kernel
In-Reply-To: <1420567175-17323-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On 01/06/2015 11:59 AM, Rickard Strandqvist wrote:
> Remove the function b43legacy_radio_set_tx_iq() that is not used anywhere.
>
> This was partially found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
> drivers/net/wireless/b43legacy/radio.c | 19 -------------------
> drivers/net/wireless/b43legacy/radio.h | 1 -
> 2 files changed, 20 deletions(-)
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
>
> diff --git a/drivers/net/wireless/b43legacy/radio.c b/drivers/net/wireless/b43legacy/radio.c
> index 8961776..9501420 100644
> --- a/drivers/net/wireless/b43legacy/radio.c
> +++ b/drivers/net/wireless/b43legacy/radio.c
> @@ -1743,25 +1743,6 @@ u16 freq_r3A_value(u16 frequency)
> return value;
> }
>
> -void b43legacy_radio_set_tx_iq(struct b43legacy_wldev *dev)
> -{
> - static const u8 data_high[5] = { 0x00, 0x40, 0x80, 0x90, 0xD0 };
> - static const u8 data_low[5] = { 0x00, 0x01, 0x05, 0x06, 0x0A };
> - u16 tmp = b43legacy_radio_read16(dev, 0x001E);
> - int i;
> - int j;
> -
> - for (i = 0; i < 5; i++) {
> - for (j = 0; j < 5; j++) {
> - if (tmp == (data_high[i] | data_low[j])) {
> - b43legacy_phy_write(dev, 0x0069, (i - j) << 8 |
> - 0x00C0);
> - return;
> - }
> - }
> - }
> -}
> -
> int b43legacy_radio_selectchannel(struct b43legacy_wldev *dev,
> u8 channel,
> int synthetic_pu_workaround)
> diff --git a/drivers/net/wireless/b43legacy/radio.h b/drivers/net/wireless/b43legacy/radio.h
> index bccb3d7..dd2976d 100644
> --- a/drivers/net/wireless/b43legacy/radio.h
> +++ b/drivers/net/wireless/b43legacy/radio.h
> @@ -92,7 +92,6 @@ void b43legacy_nrssi_hw_write(struct b43legacy_wldev *dev, u16 offset, s16 val);
> void b43legacy_nrssi_hw_update(struct b43legacy_wldev *dev, u16 val);
> void b43legacy_nrssi_mem_update(struct b43legacy_wldev *dev);
>
> -void b43legacy_radio_set_tx_iq(struct b43legacy_wldev *dev);
> u16 b43legacy_radio_calibrationvalue(struct b43legacy_wldev *dev);
>
> #endif /* B43legacy_RADIO_H_ */
>
^ permalink raw reply
* Re: [PATCH] net: wireless: ipw2x00: ipw2200.c: Remove unused function
From: Kalle Valo @ 2015-01-06 18:04 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Stanislav Yakovlev, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1419078599-31118-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> writes:
> Remove the function ipw_alive() that is not used anywhere.
>
> This was partially found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Please improve the patch title and make it more unique like:
ipw2200: remove unused ipw_alive()
--
Kalle Valo
^ 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