* [PATCH v4 09/20] selftests/memory-hotplug: add install target to enable test install
From: Shuah Khan @ 2015-01-06 19:43 UTC (permalink / raw)
To: mmarek-AlSwsSmVLrQ, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, keescook-F7+t8E8rja9g9hUCZPvPmw,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg,
cov-sgV2jX0FEOL9JmXXK+q4OQ, dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w,
hughd-hpIqsD4AKlfQT0dZR+AlfA, bobby.prani-Re5JQEeQqe8AvxtiuMwx3w,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, tim.bird-/MT0OVThwyLZJqsBc5GL+g,
josh-iaAMLnmF4UmaiuxdJuQwMA, koct9i-Re5JQEeQqe8AvxtiuMwx3w,
masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ
Cc: Shuah Khan, linux-kbuild-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1420571615.git.shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Add a new make target to enable installing test. This target
installs test in the kselftest install location and add to the
kselftest script to run the test. Install target can be run
only from top level kernel source directory.
Signed-off-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
tools/testing/selftests/memory-hotplug/Makefile | 14 ++++++++++++--
.../memory-hotplug/{on-off-test.sh => mem-on-off-test.sh} | 0
2 files changed, 12 insertions(+), 2 deletions(-)
rename tools/testing/selftests/memory-hotplug/{on-off-test.sh => mem-on-off-test.sh} (100%)
diff --git a/tools/testing/selftests/memory-hotplug/Makefile b/tools/testing/selftests/memory-hotplug/Makefile
index d46b8d4..3bb0a99 100644
--- a/tools/testing/selftests/memory-hotplug/Makefile
+++ b/tools/testing/selftests/memory-hotplug/Makefile
@@ -1,9 +1,19 @@
+TEST_STR=/bin/bash ./mem-on-off-test.sh -r 2 || echo 'memory-hotplug selftests: [FAIL]'
+
all:
+install:
+ifdef INSTALL_KSFT_PATH
+ install ./mem-on-off-test.sh $(INSTALL_KSFT_PATH)/mem-on-off-test.sh
+ @echo "$(TEST_STR)" >> $(KSELFTEST) >> $(KSELFTEST)
+else
+ @echo "Run make kselftest_install in top level source directory"
+endif
+
run_tests:
- @/bin/bash ./on-off-test.sh -r 2 || echo "memory-hotplug selftests: [FAIL]"
+ @$(TEST_STR)
run_full_test:
- @/bin/bash ./on-off-test.sh || echo "memory-hotplug selftests: [FAIL]"
+ @/bin/bash ./mem-on-off-test.sh || echo "memory-hotplug selftests: [FAIL]"
clean:
diff --git a/tools/testing/selftests/memory-hotplug/on-off-test.sh b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
similarity index 100%
rename from tools/testing/selftests/memory-hotplug/on-off-test.sh
rename to tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
--
2.1.0
^ permalink raw reply related
* [PATCH v4 08/20] selftests/memfd: add install target to enable test install
From: Shuah Khan @ 2015-01-06 19:43 UTC (permalink / raw)
To: mmarek, gregkh, akpm, rostedt, mingo, davem, keescook,
tranmanphong, mpe, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i,
masami.hiramatsu.pt
Cc: Shuah Khan, linux-kbuild, linux-kernel, linux-api, netdev
In-Reply-To: <cover.1420571615.git.shuahkh@osg.samsung.com>
Add a new make target to enable installing test. This target
installs test in the kselftest install location and add to the
kselftest script to run the test. Install target can be run
only from top level kernel source directory.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
---
tools/testing/selftests/memfd/Makefile | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/memfd/Makefile b/tools/testing/selftests/memfd/Makefile
index b80cd10..23c84bf 100644
--- a/tools/testing/selftests/memfd/Makefile
+++ b/tools/testing/selftests/memfd/Makefile
@@ -2,19 +2,30 @@ CFLAGS += -D_FILE_OFFSET_BITS=64
CFLAGS += -I../../../../include/uapi/
CFLAGS += -I../../../../include/
+INSTALL_PROGS = memfd_test fuse_test run_fuse_test.sh
+MEMFD_TEST_STR = ./memfd_test || echo 'memfd_test: [FAIL]'
+FUSE_TEST_STR = ./run_fuse_test.sh || echo 'fuse_test: [FAIL]'
+
all:
gcc $(CFLAGS) memfd_test.c -o memfd_test
+install:
+ifdef INSTALL_KSFT_PATH
+ install $(INSTALL_PROGS) $(INSTALL_KSFT_PATH)
+ @echo "$(MEMFD_TEST_STR)" >> $(KSELFTEST)
+else
+ @echo "Run make kselftest_install in top level source directory"
+endif
+
run_tests: all
- gcc $(CFLAGS) memfd_test.c -o memfd_test
- @./memfd_test || echo "memfd_test: [FAIL]"
+ @$(MEMFD_TEST_STR)
build_fuse:
gcc $(CFLAGS) fuse_mnt.c `pkg-config fuse --cflags --libs` -o fuse_mnt
gcc $(CFLAGS) fuse_test.c -o fuse_test
run_fuse: build_fuse
- @./run_fuse_test.sh || echo "fuse_test: [FAIL]"
+ @$(FUSE_TEST_STR)
clean:
$(RM) memfd_test fuse_test
--
2.1.0
^ permalink raw reply related
* [PATCH v4 07/20] selftests/kcmp: add install target to enable test install
From: Shuah Khan @ 2015-01-06 19:43 UTC (permalink / raw)
To: mmarek, gregkh, akpm, rostedt, mingo, davem, keescook,
tranmanphong, mpe, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i,
masami.hiramatsu.pt
Cc: Shuah Khan, linux-kbuild, linux-kernel, linux-api, netdev
In-Reply-To: <cover.1420571615.git.shuahkh@osg.samsung.com>
Add a new make target to enable installing test. This target
installs test in the kselftest install location and add to the
kselftest script to run the test. Install target can be run
only from top level kernel source directory.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
---
tools/testing/selftests/kcmp/Makefile | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kcmp/Makefile b/tools/testing/selftests/kcmp/Makefile
index ff0eefd..46267c1 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -1,10 +1,21 @@
CC := $(CROSS_COMPILE)$(CC)
CFLAGS += -I../../../../usr/include/
+TEST_STR = ./kcmp_test || echo 'kcmp_test: [FAIL]'
+
all: kcmp_test
+install:
+ifdef INSTALL_KSFT_PATH
+ install ./kcmp_test $(INSTALL_KSFT_PATH)
+ @echo "$(TEST_STR)" >> $(KSELFTEST)
+ @echo rm -f kcmp-test-file >> $(KSELFTEST)
+else
+ @echo "Run make kselftest_install in top level source directory"
+endif
+
run_tests: all
- @./kcmp_test || echo "kcmp_test: [FAIL]"
+ @$(TEST_STR)
clean:
$(RM) kcmp_test kcmp-test-file
--
2.1.0
^ permalink raw reply related
* [PATCH v4 06/20] selftests/ipc: add install target to enable test install
From: Shuah Khan @ 2015-01-06 19:43 UTC (permalink / raw)
To: mmarek, gregkh, akpm, rostedt, mingo, davem, keescook,
tranmanphong, mpe, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i,
masami.hiramatsu.pt
Cc: Shuah Khan, linux-kbuild, linux-kernel, linux-api, netdev
In-Reply-To: <cover.1420571615.git.shuahkh@osg.samsung.com>
Add a new make target to enable installing test. This target
installs test in the kselftest install location and add to the
kselftest script to run the test. Install target can be run
only from top level kernel source directory.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
---
tools/testing/selftests/ipc/Makefile | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ipc/Makefile b/tools/testing/selftests/ipc/Makefile
index 74bbefd..67ea3af 100644
--- a/tools/testing/selftests/ipc/Makefile
+++ b/tools/testing/selftests/ipc/Makefile
@@ -11,6 +11,8 @@ endif
CFLAGS += -I../../../../usr/include/
+TEST_STR = ./msgque_test || echo 'ipc msgque test: [FAIL]'
+
all:
ifeq ($(ARCH),x86)
gcc $(CFLAGS) msgque.c -o msgque_test
@@ -18,8 +20,23 @@ else
echo "Not an x86 target, can't build msgque selftest"
endif
+install:
+ifdef INSTALL_KSFT_PATH
+ifeq ($(ARCH),x86)
+ make all
+ install ./msgque_test $(INSTALL_KSFT_PATH)
+ @echo "$(TEST_STR)" >> $(KSELFTEST)
+else
+ @echo "Not an x86 target, unable to install ipc msgque selftests"
+endif
+else
+ @echo "Run make kselftest_install in top level source directory"
+endif
+
run_tests: all
- ./msgque_test
+ifeq ($(ARCH),x86)
+ @$(TEST_STR)
+endif
clean:
rm -fr ./msgque_test
--
2.1.0
^ permalink raw reply related
* [PATCH v4 03/20] selftests/efivarfs: add install target to enable test install
From: Shuah Khan @ 2015-01-06 19:43 UTC (permalink / raw)
To: mmarek, gregkh, akpm, rostedt, mingo, davem, keescook,
tranmanphong, mpe, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i,
masami.hiramatsu.pt
Cc: Shuah Khan, linux-kbuild, linux-kernel, linux-api, netdev
In-Reply-To: <cover.1420571615.git.shuahkh@osg.samsung.com>
Add a new make target to enable installing test. This target
installs test in the kselftest install location and add to the
kselftest script to run the test. Install target can be run
only from top level kernel source directory.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
---
tools/testing/selftests/efivarfs/Makefile | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/efivarfs/Makefile b/tools/testing/selftests/efivarfs/Makefile
index 29e8c6b..c5f389d 100644
--- a/tools/testing/selftests/efivarfs/Makefile
+++ b/tools/testing/selftests/efivarfs/Makefile
@@ -3,10 +3,22 @@ CFLAGS = -Wall
test_objs = open-unlink create-read
-all: $(test_objs)
+TEST_STR = /bin/bash ./efivarfs.sh || echo 'efivarfs selftests: [FAIL]'
+
+all:
+ gcc open-unlink.c -o open-unlink
+ gcc create-read.c -o create-read
+
+install:
+ifdef INSTALL_KSFT_PATH
+ install ./efivarfs.sh $(test_objs) $(INSTALL_KSFT_PATH)
+ @echo "$(TEST_STR)" >> $(KSELFTEST)
+else
+ @echo "Run make kselftest_install in top level source directory"
+endif
run_tests: all
- @/bin/bash ./efivarfs.sh || echo "efivarfs selftests: [FAIL]"
+ @$(TEST_STR)
clean:
rm -f $(test_objs)
--
2.1.0
^ permalink raw reply related
* [PATCH v4 01/20] selftests/breakpoints: add install target to enable test install
From: Shuah Khan @ 2015-01-06 19:43 UTC (permalink / raw)
To: mmarek, gregkh, akpm, rostedt, mingo, davem, keescook,
tranmanphong, mpe, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i,
masami.hiramatsu.pt
Cc: Shuah Khan, linux-kbuild, linux-kernel, linux-api, netdev
In-Reply-To: <cover.1420571615.git.shuahkh@osg.samsung.com>
Add a new make target to enable installing test. This target
installs test in the kselftest install location and add to the
kselftest script to run the test. Install target can be run
only from top level kernel source directory.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
---
tools/testing/selftests/breakpoints/Makefile | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/breakpoints/Makefile b/tools/testing/selftests/breakpoints/Makefile
index e18b42b..c738d4c 100644
--- a/tools/testing/selftests/breakpoints/Makefile
+++ b/tools/testing/selftests/breakpoints/Makefile
@@ -8,6 +8,7 @@ ifeq ($(ARCH),x86_64)
ARCH := x86
endif
+TEST_STR = ./breakpoint_test || echo 'breakpoints selftests: [FAIL]'
all:
ifeq ($(ARCH),x86)
@@ -16,8 +17,22 @@ else
echo "Not an x86 target, can't build breakpoints selftests"
endif
-run_tests:
- @./breakpoint_test || echo "breakpoints selftests: [FAIL]"
+install:
+ifdef INSTALL_KSFT_PATH
+ifeq ($(ARCH),x86)
+ install ./breakpoint_test $(INSTALL_KSFT_PATH)
+ @echo "$(TEST_STR)" >> $(KSELFTEST)
+else
+ @echo "Not an x86 target, unable to install breakpoints selftests"
+endif
+else
+ @echo "Run make kselftest_install in top level source directory"
+endif
+
+run_tests: all
+ifeq ($(ARCH),x86)
+ @$(TEST_STR)
+endif
clean:
rm -fr breakpoint_test
--
2.1.0
^ permalink raw reply related
* Re: TCP connection issues against Amazon S3
From: Erik Grinaker @ 2015-01-06 19:42 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Eric Dumazet, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <CAK6E8=cP0BFUob5MVj9M0hC0efgRnUY=JMUPKee+v-4TLvHBgg@mail.gmail.com>
> On 06 Jan 2015, at 19:18, Yuchung Cheng <ycheng@google.com> wrote:
>
> On Tue, Jan 6, 2015 at 11:01 AM, Erik Grinaker <erik@bengler.no> wrote:
>>
>>> 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.
>
> Without SACK, the sender uses NewReno fast recovery and recovers one
> packet per RTT. In contrast, SACK-based fast recovery can potentially
> recover all lost packets in one RTT.
The transfer on the functioning Netherlands server does indeed use SACKs, while the Norway servers do not.
For what it’s worth, I have made stripped down pcaps for a single failing transfer as well as a single functioning transfer in the Netherlands:
http://abstrakt.bengler.no/tcp-issues-s3-failure.pcap.bz2
http://abstrakt.bengler.no/tcp-issues-s3-success-netherlands.pcap.bz2
> I still can't explain the problem seen on newer kernel. But that got
> to be some receiver related changes, not
> 0f7cc9a3c2bd89b15720dbf358e9b9e62af27126 b/c it's a sender side
> change.
Yeah, I’m not really sure what exactly in 3.12.0 is causing it, that just seemed like a possible candidate to my untrained eye.
>>> 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 V2] net: eth: xgene: change APM X-Gene SoC platform ethernet to support ACPI
From: Feng Kan @ 2015-01-06 19:30 UTC (permalink / raw)
To: David Miller; +Cc: patches, netdev, linux-kernel@vger.kernel.org
In-Reply-To: <20150105.231054.790363276763745624.davem@davemloft.net>
On Mon, Jan 5, 2015 at 8:10 PM, David Miller <davem@davemloft.net> wrote:
> From: Feng Kan <fkan@apm.com>
> Date: Mon, 5 Jan 2015 20:05:28 -0800
>
>> I see, I initially tried on the net-next tree which did not build for
>> me, failed somewhere else but builds xgene enet ok.
>> Then I tested on net/master which builds fine for me.
>> Would you please point me to the branch you are using?
>
> net-next
David, I am not sure what I am missing here. I encountered a lot of
errors while compiling
the net-next.git. Mostly complaining of implicit declaration of
functions. Once I fixed those,
the compilation passes fine for defconfig in arm64. By default OF
should be enabled for
the platform, I am not sure how to recreate this. I have tested the
image for OF and ACPI
and both works.
^ permalink raw reply
* Re: [PATCH] Fix NUL (\0 or \x00) specification in string
From: Giel van Schijndel @ 2015-01-06 19:28 UTC (permalink / raw)
To: dsterba, linux-kernel, Armin Schindler, Karsten Keil,
open list:ISDN SUBSYSTEM
In-Reply-To: <20150105150026.GG6114@twin.jikos.cz>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Mon, Jan 05, 2015 at 16:00:26 +0100, David Sterba wrote:
> I'm replying to all your recent patches here as they are fixing things
> reported in http://www.viva64.com/en/b/0299/ . I'ts a good practice to
> give the credit the reporter.
>
> The blogpost also contains analyses of the issues so it could help
> reviewing the patches.
I guess you suggest I use a 'Reported-(at|by)' line?
Would something like the below suffice? I found similar log entries in the
commit log, e.g. bf3204cb, except that those add an e-mail address for
the reporters, which I don't think is necessary in this case.
> Reported-at: http://www.viva64.com/en/b/0299/
> Reported-by: Andrey Karpov
> Reported-by: Svyatoslav Razmyslov
--
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
--
The #1 programmer excuse for legitimately slacking off:
"My code's compiling."
-- http://xkcd.com/303/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: pull request [net]: batman-adv 20150106
From: David Miller @ 2015-01-06 19:25 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1420542605-28865-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Tue, 6 Jan 2015 12:09:59 +0100
> here you have some small fixes for your 'net' tree.
>
> Patch 1 fixes a regression in the "bonding" code introduced while
> implementing the multi-interface optimization feature, by Simon
> Wunderlich.
>
> Patch 2 ensures that the "last-seen" timestamp for a newly created
> originator object is properly initialised in order to avoid a non-critical
> race condition, by Linus Lüssing.
>
> Patch 3 avoids false positive splats when lockdep is enabled by assigning
> the proper lock class to locks used by the network coding feature, by
> Martin Hundebøll.
>
> Patches 4 and 5 fix the code counting the amount of multicast-disabled
> nodes in the network (used to avoid to enable the multicast optimisation
> when not possible), by Linus Lüssing.
>
> Patch 6 fixes a memory leak in the Translation Table code that can be
> triggered by doubling the current originator interval, by Linus Lüssing.
Pulled, thanks Antonio.
^ permalink raw reply
* Re: TCP connection issues against Amazon S3
From: Yuchung Cheng @ 2015-01-06 19:18 UTC (permalink / raw)
To: Erik Grinaker; +Cc: Eric Dumazet, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <03FC652E-AA01-42C7-BD52-019B6D922A9C@bengler.no>
On Tue, Jan 6, 2015 at 11:01 AM, Erik Grinaker <erik@bengler.no> wrote:
>
>> 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.
Without SACK, the sender uses NewReno fast recovery and recovers one
packet per RTT. In contrast, SACK-based fast recovery can potentially
recover all lost packets in one RTT.
I still can't explain the problem seen on newer kernel. But that got
to be some receiver related changes, not
0f7cc9a3c2bd89b15720dbf358e9b9e62af27126 b/c it's a sender side
change.
>
>> 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] xen-netback: fixing the propagation of the transmit shaper timeout
From: David Miller @ 2015-01-06 19:18 UTC (permalink / raw)
To: Ian.Campbell
Cc: imrep.amz, xen-devel, netdev, wei.liu2, linux-kernel, imrep,
aliguori
In-Reply-To: <1420559647.28863.174.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 6 Jan 2015 15:54:07 +0000
> On Tue, 2015-01-06 at 16:44 +0100, Imre Palik wrote:
>> From: "Palik, Imre" <imrep@amazon.de>
>>
>> Since e9ce7cb6b107 ("xen-netback: Factor queue-specific data into queue struct"),
>> the transimt shaper timeout is always set to 0. The value the user sets via
>> xenbus is never propagated to the transmit shaper.
>>
>> This patch fixes the issue.
>>
>> Cc: Anthony Liguori <aliguori@amazon.com>
>> Signed-off-by: Imre Palik <imrep@amazon.de>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: TCP connection issues against Amazon S3
From: Rick Jones @ 2015-01-06 19:16 UTC (permalink / raw)
To: Yuchung Cheng, Erik Grinaker
Cc: Eric Dumazet, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <CAK6E8=d5Z0W5sSAdeEcecKbqjj_UwGw4949=a20fetFpLVKwwA@mail.gmail.com>
>>>>>> 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.
The TCP Timestamp option too it seems.
Speaking of middleboxes... It is probably a fish that is red, but a
while back I stepped in a middle box (a load balancer) which decided
that if it saw "too many" retransmissions in a given TCP window that
something was seriously wrong and it would toast the connection. I
thought though that was an active reset on the part of the middlebox.
(And the client was the active sender not the back-end server)
I'm assuming one incident starts at XX:41:24.748265 in the trace? That
does look like it is slowly slogging its way through a bunch of lost
traffic, which was I think part of the problem I was seeing with the
middlebox I stepped in, but I don't think I see the reset where I would
have expected it. Still, it looks like the sender has an increasing TCP
RTO as it is going through the slog (as it likely must since there are
no TCP timestamps?), to the point it gets larger than I'm guessing curl
was willing to wait, so the FIN at XX:41:53.269534 after a ten second or
so gap.
rick jones
^ 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 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
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