On 03/19/2013 01:13 PM, Eric Dumazet wrote:
On Tue, 2013-03-19 at 17:26 +0800, Jason Wang wrote:
On 03/18/2013 12:13 AM, David Miller wrote:
From: Eric Dumazet eric.duma...@gmail.com
Date: Fri, 15 Mar 2013 19:10:51 -0700
Any way we can avoid adding this to fast path, for people not using
On 03/19/2013 01:59 PM, Eric Dumazet wrote:
On Tue, 2013-03-19 at 13:58 +0100, Daniel Borkmann wrote:
Yes, will post them in a couple of minutes.
Please target net tree for the first patch (adding thoff into struct
flow_keys), so that Jason or me can fix DODGY providers.
Sorry, I received
for (e.g.) the crypto and networking subsystems.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
include/linux/string.h | 3 +++
lib/string.c | 22 ++
2 files changed, 25 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index ac889c5
On 02/11/2013 12:24 AM, Joe Perches wrote:
On Sun, 2013-02-10 at 23:00 +0100, Daniel Borkmann wrote:
add memcmp_nta ({n}o {t}iming {a}ttacks)
Why should this be in the kernel?
As the commit message already says, so that current or future (e.g.) network
protocol code or modules can make use
On 02/11/2013 12:50 AM, Greg KH wrote:
On Mon, Feb 11, 2013 at 12:30:51AM +0100, Daniel Borkmann wrote:
On 02/11/2013 12:24 AM, Joe Perches wrote:
On Sun, 2013-02-10 at 23:00 +0100, Daniel Borkmann wrote:
add memcmp_nta ({n}o {t}iming {a}ttacks)
Why should this be in the kernel
On 02/11/2013 07:37 PM, Andy Lutomirski wrote:
On 02/10/2013 02:00 PM, Daniel Borkmann wrote:
If you need to compare a password or a hash value, the timing of the
comparison function can give valuable clues to the attacker. Let's
say the password is 123456 and the attacker tries abcdef
On 02/11/2013 08:00 PM, Florian Weimer wrote:
* Daniel Borkmann:
Thanks for your feedback, Florian!
+ * memcmp_nta - memcmp that is secure against timing attacks
It's not providing an ordering, so it should not have cmp in the
name.
I agree. What would you suggest? Probably, it would make
On Tue, Sep 4, 2012 at 4:16 PM, Iulius Curt iulius.c...@gmail.com wrote:
synchronize_net is called every time we close a PF_PACKET socket which is
causing performance loss when doing this on many sockets.
Do you have any particular use case in mind? I can imagine if you are
closing a PF_PACKET
: bpf: don't forget to free sk_filter
or the like. Also it's enough to say 'This memory leak was introduced
by commit d45ed4a4e3 (net: fix unsafe set_memory_rw from softirq)'
instead of copying the whole log. Anyways, for v2 with feedback included
then:
Acked-by: Daniel Borkmann dbork...@redhat.com
On 11/06/2013 08:28 PM, Eric Dumazet wrote:
On Wed, 2013-11-06 at 20:19 +0100, Daniel Borkmann wrote:
When you send v2 with Alexei's feedback, please also be more specific
in your subject like net: x86: bpf: don't forget to free sk_filter
or the like. Also it's enough to say 'This memory leak
On 11/25/2013 04:59 PM, James Yonan wrote:
On 24/11/2013 14:12, Cesar Eduardo Barros wrote:
Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.
Instead of disabling compiler optimizations, use a
-independent timing) even if it is inlined at its call sites. That
can be done later in a followup patch.
Compile-tested on x86_64.
Signed-off-by: Cesar Eduardo Barros ces...@cesarb.eti.br
Acked-by: Daniel Borkmann dbork...@redhat.com
Looks good, thanks!
--
To unsubscribe from this list: send
On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote:
Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.
Instead of disabling compiler optimizations, use a dummy inline assembly
(based on
On 11/26/2013 10:44 PM, Cesar Eduardo Barros wrote:
Em 26-11-2013 17:27, Daniel Borkmann escreveu:
On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote:
Compile-tested on x86_64.
Actually with yet another version, I hoped that the compile-tested-only
statement would eventually disappear, ohh
Hi Stephen,
On 11/12/2013 05:55 AM, Stephen Rothwell wrote:
Hi Ted,
Today's linux-next merge of the random tree got a conflict in
drivers/char/random.c between commit 0244ad004a54 (random32: add
prandom_reseed_late() and call when nonblocking pool becomes
initialized) from the net-next tree
On 11/13/2013 03:54 AM, Chang wrote:
On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
Look for the __two__ most recently used path/transport and set to active_path
and retran_path respectively
Please also for the log, elaborate a bit more,
On 11/13/2013 08:06 PM, Chang wrote:
On 11/13/2013 09:44 AM, Daniel Borkmann wrote:
On 11/13/2013 03:54 AM, Chang wrote:
On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
Look for the __two__ most recently used path/transport and set to active_path
On 11/13/2013 10:23 PM, Chang wrote:
[...]
Let's say the following condition
A - the initial revision
B - something was wrong that introduced a bug
C - latest revision
MyFix - fixing the bug caused by B. Shall I specify B or C in the fixes: tag?
revision introduces a bug
|
A
On 03/14/2014 09:08 PM, David Miller wrote:
From: Alexei Starovoitov a...@plumgrid.com
Date: Fri, 14 Mar 2014 12:51:17 -0700
can you please explain why the status of these
patches is 'deferred' in patchwork ?
Is it because of bpf vs nft thread?
I think that's orthogonal.
I do not find it
On 02/21/2014 11:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the call sites).
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Francesco Fusco ffu...@redhat.com
Cc: Daniel Borkmann dbork...@redhat.com
Cc: Thomas Graf tg
On 02/24/2014 09:03 AM, Jan Beulich wrote:
On 22.02.14 at 13:09, Daniel Borkmann dbork...@redhat.com wrote:
On 02/21/2014 11:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the call sites).
Signed-off-by: Jan Beulich jbeul
On 02/24/2014 11:53 AM, Jan Beulich wrote:
On 24.02.14 at 11:22, Daniel Borkmann dbork...@redhat.com wrote:
On 02/24/2014 09:03 AM, Jan Beulich wrote:
On 22.02.14 at 13:09, Daniel Borkmann dbork...@redhat.com wrote:
On 02/21/2014 11:33 AM, Jan Beulich wrote:
... to match its two callers (i.e
On 02/24/2014 02:01 PM, H. Peter Anvin wrote:
On 02/24/2014 04:51 AM, H. Peter Anvin wrote:
On 02/24/2014 04:41 AM, Jan Beulich wrote:
So I'm guessing this hash is deliberately using the CRC32 instruction
backwards, which would actually make sense: an actual CRC is actually
a pretty poor hash
?
Good point. I'm fine if this is going to be picked up
by x86 maintainers. Feel free to add my ...
Acked-by: Daniel Borkmann dbork...@redhat.com
... if you want to do an updated version that also
includes our recent findings/discussion, Jan.
Thanks!
--
To unsubscribe from this list: send the line
: Francesco Fusco ffu...@redhat.com
Cc: Daniel Borkmann dbork...@redhat.com
Cc: Thomas Graf tg...@redhat.com
Cc: David S. Miller da...@davemloft.net
Acked-by: Daniel Borkmann dbork...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On 02/27/2014 09:47 AM, Jan Beulich wrote:
- simplify switch statement
- add __init annotation to setup_arch_fast_hash()
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Francesco Fusco ffu...@redhat.com
Cc: Daniel Borkmann dbork...@redhat.com
Cc: Thomas Graf tg...@redhat.com
Cc: David S
Hi Alexei,
[also cc'ing Hagen and Jesse]
Just some minor comments below ... let me know what you think.
On 02/27/2014 03:38 AM, Alexei Starovoitov wrote:
Extended BPF (or 64-bit BPF) is an instruction set to
create safe dynamically loadable filters that can call fixed set
of kernel functions
On 02/28/2014 09:53 PM, Alexei Starovoitov wrote:
On Fri, Feb 28, 2014 at 4:45 AM, Daniel Borkmann dbork...@redhat.com wrote:
...
Did you also test that seccomp-BPF still works out?
yes. Have a prototype, but it needs a bit more cleanup.
Here's [1] actually some code snippet for user space
On 03/04/2014 06:18 AM, Alexei Starovoitov wrote:
Extended BPF extends old BPF in the following ways:
- from 2 to 10 registers
Original BPF has two registers (A and X) and hidden frame pointer.
Extended BPF has ten registers and read-only frame pointer.
- from 32-bit registers to 64-bit
On 03/04/2014 06:09 PM, Alexei Starovoitov wrote:
On Tue, Mar 4, 2014 at 1:59 AM, Daniel Borkmann dbork...@redhat.com wrote:
...
Hmm, so the case statement is about BPF_RET | BPF_A and BPF_RET | BPF_K
but BPF_RET | BPF_X is not mentioned. However, in BPF_SRC(fp-code)
selection you fall back
On 03/04/2014 06:53 PM, Alexei Starovoitov wrote:
On Tue, Mar 4, 2014 at 6:28 AM, Hagen Paul Pfeifer ha...@jauu.net wrote:
If all issues raised by Daniel are addresed:
Acked-by: Hagen Paul Pfeifer ha...@jauu.net
Thanks!
But ...
Future work:
0. seccomp
1. add extended BPF JIT for x86_64
On 03/04/2014 11:17 PM, Alexei Starovoitov wrote:
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
Reviewed-by: Daniel Borkmann dbork...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
. nftables with extended BPF
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
Acked-by: Hagen Paul Pfeifer ha...@jauu.net
From what I can tell, looks good to me:
Reviewed-by: Daniel Borkmann dbork...@redhat.com
So next step would be to add selftests and then after that JIT?
...
+#undef
config.h must be included before this header
This is similar to commit 3ce711a6abc27abce1554e1d671a8762b7187690
perf tools: bfd.h/libbfd detection fails with recent binutils
See: https://sourceware.org/bugzilla/show_bug.cgi?id=14243
CC: David S. Miller da...@davemloft.net
CC: Daniel Borkmann dbork
-like with extended BPF
4. OVS with extended BPF
5. nftables with extended BPF
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
Acked-by: Hagen Paul Pfeifer ha...@jauu.net
Reviewed-by: Daniel Borkmann dbork...@redhat.com
One more question or possible issue that came through my mind: When
someone
On 03/09/2014 06:08 PM, Alexei Starovoitov wrote:
On Sun, Mar 9, 2014 at 5:29 AM, Daniel Borkmann borkm...@iogearbox.net wrote:
On 03/09/2014 12:15 AM, Alexei Starovoitov wrote:
Extended BPF extends old BPF in the following ways:
- from 2 to 10 registers
Original BPF has two registers
On 03/11/2014 12:06 PM, Tobias Klauser wrote:
Make sure patches for these tools go to the netdev list as well.
References: https://marc.info/?l=linux-kernelm=139450284501328w=2
Cc: David S. Miller da...@davemloft.net
Cc: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Tobias Klauser tklau
On 03/11/2014 12:06 PM, Tobias Klauser wrote:
Make sure patches for these tools go to the netdev list as well.
References: https://marc.info/?l=linux-kernelm=139450284501328w=2
Cc: David S. Miller da...@davemloft.net
Cc: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Tobias Klauser tklau
This is being reliably triggered for each mmaped() packet(7)
socket from user space, basically during unmapping resp.
closing the TX socket.
I believe due to some change in transparent hugepages code ?
When I disable transparent hugepages, everything works fine,
no BUG triggered.
I'd be happy
On 01/11/2014 07:22 AM, Andrew Morton wrote:
On Fri, 10 Jan 2014 19:23:26 +0100 Daniel Borkmann borkm...@iogearbox.net
wrote:
This is being reliably triggered for each mmaped() packet(7)
socket from user space, basically during unmapping resp.
closing the TX socket.
I believe due to some
On 01/12/2014 10:39 AM, Bruce Liu wrote:
When timestamping is enabled, stmmac_tx_clean will call
stmmac_get_tx_hwtstamp to get tx TS.
It's possible that skb is NULL because there are other network frames that
use several descriptors.
So we must return immediately in
On 01/13/2014 11:16 AM, Vlastimil Babka wrote:
On 01/11/2014 02:32 PM, Daniel Borkmann wrote:
On 01/11/2014 07:22 AM, Andrew Morton wrote:
On Fri, 10 Jan 2014 19:23:26 +0100 Daniel Borkmann borkm...@iogearbox.net
wrote:
This is being reliably triggered for each mmaped() packet(7)
socket
everywhere else.
Also, use the normal comment style for the header comment. Last
but not least for readability, add some newlines.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
v1-v2:
- Applied most of Joe's feedback
lib/random32.c | 76
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully extended in specific places.
End result may look big at first glance, but every
On 02/13/2014 09:20 PM, Daniel Borkmann wrote:
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully extended in specific places.
End
On 02/13/2014 11:32 PM, H. Peter Anvin wrote:
On 02/06/2014 05:20 PM, Alexei Starovoitov wrote:
I believe that old BPF outlived itself and BPF64 should
replace it in all current use cases plus a lot more.
It just cannot happen at once.
BPF64 can come in. bpf32-bpf64 converter functioning.
JIT
On 02/13/2014 11:47 PM, H. Peter Anvin wrote:
On 02/13/2014 02:44 PM, Daniel Borkmann wrote:
Well, if that would be the case, then seccomp would have had JIT support
long ago. ;-) Right now BPF filters with seccomp are not JIT compiled
for _any_ architecture.
Really, I was under
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
I'm very curious, do you also have any performance numbers, e.g. for
networking by taking JIT'ed/non-JIT'ed BPF filters and compare them against
JIT'ed/non-JIT'ed eBPF filters to see how many pps we gain or loose e.g.
for a scenario with a
On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
...
Do you see a possibility to integrate your work step by step? That is,
Sure. let's see how we can do it.
to first integrate the interpreter part only; meaning, to detect old
BPF programs e.g. coming from SO_ATTACH_FILTER et al and run
On 02/14/2014 06:55 PM, Alexei Starovoitov wrote:
On Fri, Feb 14, 2014 at 9:02 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
I'm very curious, do you also have any performance numbers, e.g. for
networking by taking JIT'ed/non-JIT'ed BPF
On 02/17/2014 11:20 PM, Mikulas Patocka wrote:
...
The proper way to add commentary is to put it after the --- delimiter
at the end of the commit message and before the actual patch.
Interesting - I used --- as a delimiter between the commentary and the
git message in the past and some people
(please cc netdev)
On 02/12/2014 11:25 AM, Quinn Wood wrote:
If program on host A spoofs the source address of an outgoing IPv4 packet then
places that address in the first 32 bits of a UDP payload, a program on host B
that is aware of these behaviors can still reply to the program on host A.
)locking
Daniel Borkmann reported a bug with VM_BUG_ON assertions failing where
munlock_vma_pages_range() thinks it's unexpectedly in the middle of a THP page.
This can be reproduced in tools/testing/selftests/net/ by running make and
then ./psock_tpacket.
The problem is that an order=2 compound page
everywhere
else. random_get_entropy() results mostly into get_cycles()
which returns unsigned long whereas seed is given in u32. Last
but not least for readability, add some newlines.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
lib/random32.c | 15 +--
1 file changed, 9
Borkmann.
References: http://thread.gmane.org/gmane.linux.kernel/1665858
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Cc: Hagen Paul Pfeifer ha...@jauu.net
Cc: Kees Cook keesc...@chromium.org
Cc: Paul Moore pmo...@redhat.com
Cc: Ingo Molnar mi
in microseconds and one in nanoseconds with the
macro NSEC_PER_USEC.
Signed-off-by: Liu Ying ying@freescale.com
Cc: David S. Miller da...@davemloft.net
Cc: Daniel Borkmann dbork...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: John Stultz john.stu...@linaro.org
---
include/linux/ktime.h |7
On 06/07/2013 04:17 PM, Vitaly V. Bursov wrote:
07.06.2013 16:05, Daniel Borkmann пишет:
[...]
Ideas are welcome :)
Probably, that depends on _your scenario_ and/or BPF filter, but would it be
an alternative if you have only a few packet sockets (maybe one pinned to each
cpu) and cluster
On 06/13/2013 04:13 AM, Eliezer Tamir wrote:
On 13/06/2013 05:01, Stephen Hemminger wrote:
On Wed, 12 Jun 2013 15:12:05 -0700 (PDT)
David Miller da...@davemloft.net wrote:
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Tue, 11 Jun 2013 17:24:28 +0300
depends on X86_TSC
Wait
On 04/27/2013 08:32 PM, Xi Wang wrote:
On Sat, Apr 27, 2013 at 2:27 AM, Daniel Borkmann dbork...@redhat.com wrote:
Besides all that, I think I also pointed you to a patch that already made
it in for ARM, not sure why you keep posting the ARM JIT implementation?
That's why I asked
On 06/07/2013 02:41 PM, Mike Galbraith wrote:
(CC's net-fu dojo)
On Fri, 2013-06-07 at 14:56 +0300, Vitaly V. Bursov wrote:
Hello,
I have a Linux router with a lot of interfaces (hundreds or
thousands of VLANs) and an application that creates AF_PACKET
socket per interface and bind()s sockets
On 06/27/2013 09:42 AM, Andy Shevchenko wrote:
On Thu, 2013-06-27 at 14:43 +0800, Cong Wang wrote:
Cc: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Cong Wang amw...@redhat.com
I was about to answer for the Daniel's patch about %pig.
Daniel, could you resend your patch series
On 04/24/2013 07:27 PM, Nicolas Schichan wrote:
This is in preparation of bpf_jit support for seccomp filters.
Please also CC the netdev list for BPF related patches.
Just to give you a heads-up, this might likely lead to a merge
conflict with the net-next tree (commit 79617801ea0c0e66,
On 04/25/2013 01:04 PM, Alexandru Copot wrote:
This series adds a generic test abstraction that can make
writing testcases easier. A generic_test structure is
used to define a test and its methods: prepare, run, cleanup.
This is a generic implementation so it was placed in selftests/lib.
The
On 04/25/2013 01:04 PM, Alexandru Copot wrote:
Signed-of-by Alexandru Copot alex.miha...@gmail.com
Cc: Daniel Baluta dbal...@ixiacom.com
---
tools/testing/selftests/Makefile| 3 +-
tools/testing/selftests/lib/Makefile| 14 +++
tools/testing/selftests/lib/selftests.c | 57
On 04/26/2013 01:25 PM, Heiko Carstens wrote:
On Fri, Apr 26, 2013 at 03:51:40AM -0400, Xi Wang wrote:
This patchset brings JIT support to seccomp filters for x86_64 and ARM.
It is against the net-next tree.
The current BPF JIT interface only accepts sk_filter, not seccomp_filter.
Patch 1/6
On 04/26/2013 02:31 PM, Xi Wang wrote:
On Fri, Apr 26, 2013 at 7:46 AM, Daniel Borkmann dbork...@redhat.com wrote:
I think BPF JIT for seccomp on ARM recently got applied to -mm tree
if I'm not mistaken. It was from Nicolas Schichan (cc):
http://thread.gmane.org/gmane.linux.ports.arm.kernel
On 04/26/2013 09:26 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann a...@arndb.de wrote:
On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
@@ -858,7 +858,7 @@ b_epilogue:
}
-void bpf_jit_compile(struct sk_filter *fp)
+static void __bpf_jit_compile(struct
On 04/26/2013 10:09 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann dbork...@redhat.com wrote:
On 04/26/2013 09:26 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann a...@arndb.de wrote:
On Wednesday 24 April 2013 19:27:08 Nicolas Schichan
On 04/27/2013 12:18 AM, Xi Wang wrote:
Thanks for CCing. One way to clean up this would be to refactor the
bpf jit interface as:
bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen);
void bpf_jit_free(bpf_func_t bpf_func);
Then both packet and seccomp filters can
On 04/27/2013 04:17 AM, Xi Wang wrote:
This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction
in ARM JIT.
Signed-off-by: Xi Wang xi.w...@gmail.com
Cc: Daniel Borkmann dbork...@redhat.com
Cc: Heiko Carstens heiko.carst...@de.ibm.com
Cc: Will Drewry w...@chromium.org
Cc: Eric
-by: Daniel Borkmann dbork...@redhat.com
---
include/linux/ktime.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index bbca128..cededfd 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -338,7 +338,8 @@ extern ktime_t
...@zytor.com
Signed-off-by: Eric Dumazet eduma...@google.com
Great work !
Probably other archs could later on follow-up with setting to read-only, too.
Reviewed-by: Daniel Borkmann dbork...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On 05/20/2013 10:51 AM, David Laight wrote:
hpa bringed into my attention some security related issues
with BPF JIT on x86.
This patch makes sure the bpf generated code is marked read only,
as other kernel text sections.
It also splits the unused space (we vmalloc() and only use a fraction of
Hi Stephen,
On 05/21/2013 06:25 AM, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/arm/net/bpf_jit_32.c between commit aafc787e41fd (arm: bpf_jit: can
call module_free() from any context) from the net-next tree and commit
ARM: net: bpf_jit:
On 05/22/2013 09:19 AM, David Miller wrote:
From: Andrew Morton a...@linux-foundation.org
Date: Wed, 22 May 2013 00:14:58 -0700
On Wed, 22 May 2013 00:07:48 -0700 (PDT) David Miller da...@davemloft.net
wrote:
From: Andrew Morton a...@linux-foundation.org
Date: Tue, 21 May 2013 13:04:38
On 05/22/2013 01:54 AM, Stephen Rothwell wrote:
Hi Daniel,
On Tue, 21 May 2013 09:44:13 +0200 Daniel Borkmann dbork...@redhat.com wrote:
Also seccomp_jit_free() needs a change otherwise the kernel won't build
with CONFIG_SECCOMP_FILTER_JIT enabled since the work_struct is initialized
is insufficient
as two crcs and the length of the second piece is needed for
merging. The code is made generic, so that only polynomials
need to be passed for crc32_le resp. crc32c_le.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Cc: linux-kernel@vger.kernel.org
---
include/linux/crc32.h | 40
tests passed
[ 17.633089] alg: No test for crc32 (crc32-pclmul)
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Cc: linux-kernel@vger.kernel.org
---
lib/crc32.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/lib/crc32.c b/lib
This is nothing more but a whitepace cleanup, as 80 chars is not a
hard but soft limit, and otherwise makes the test cases arrary really
look ugly. So fix it up.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Cc: linux-kernel@vger.kernel.org
---
lib/crc32.c | 300
On 10/30/2013 03:10 PM, David Laight wrote:
+ {0x674bf11d, 0x0038, 0x0542, 0x0af6d466, 0xd8b6e4c1,
0xf6e93d6c},
these could be
+ {0x674bf11d, 0x38, 0x542, 0x0af6d466, 0xd8b6e4c1, 0xf6e93d6c},
Or even:
#define X(a, b, c, d, e, f) {0x##a, 0x##b, 0x##c, 0x##d, 0x##e.
: support IPIP encapsulation).
Cc: Eric Dumazet eduma...@google.com
Cc: Petr Matousek pmato...@redhat.com
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Jason Wang jasow...@redhat.com
Sorry, a bit late as I was offline last 4 days, but fwiw:
Acked
this. Thanks!
commit efba721f636ee016859d86d15748650119402b10
Author: Daniel Borkmann dbork...@redhat.com
Date: Wed Oct 30 11:50:50 2013 +0100
lib: crc32: add test cases for crc32{, c}_combine routines
We already have 100 test cases for crcs itself, so split the test
buffer with a-prio
v1-v2:
- migrated api to random.h, ccing lkml
- dropped second patch for now
Daniel Borkmann (2):
random: add prandom_u32_range and prandom_u32_max helpers
net: migrate direct users to prandom_u32_max
drivers/net/team/team_mode_random.c | 8 +---
include/linux/random.h
and prandom_u32_max() generates numbers in [0, end] interval.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Cc: Theodore Ts'o ty...@mit.edu
Cc: Joe Perches j...@perches.com
Cc: linux-kernel@vger.kernel.org
---
include/linux/random.h | 31 ++-
1 file changed, 30 insertions(+), 1
Users that directly use or reimplement what we have in prandom_u32_max()
can be migrated for now to use it directly, so that we can reduce code size
and avoid reimplementations. That's obvious, follow-up patches could inspect
modulo use cases for possible migration as well.
Signed-off-by: Daniel
On 09/04/2013 02:52 PM, Eric Dumazet wrote:
On Wed, 2013-09-04 at 14:37 +0200, Daniel Borkmann wrote:
Users that directly use or reimplement what we have in prandom_u32_max()
can be migrated for now to use it directly, so that we can reduce code size
and avoid reimplementations. That's obvious
On 09/05/2013 07:19 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/bridge/br_multicast.c between commit 2d98c29b6fb3 (net: bridge:
convert MLDv2 Query MRC into msecs_to_jiffies for max_delay) from Linus'
tree and commit e3f5b17047de (net:
[ Please also Cc Hannes in your series. ]
On 06/07/2014 10:31 AM, George Spelvin wrote:
Get rid of a few of the extraneous U suffixes on ordinary integers.
Signed-off-by: George Spelvin li...@horizon.com
---
lib/random32.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
On 06/07/2014 10:28 AM, George Spelvin wrote:
If you're going to bother randomizing it, do it right.
And use prandom_u32_max(), which is designed for the job, rather
than % 40.
Signed-off-by: George Spelvin li...@horizon.com
Fine by me this cleanup, although not strictly needed.
---
On 06/07/2014 10:28 AM, George Spelvin wrote:
The multiply-and-shift is efficient in the general case, but slower than
a simple bitwise AND if the range is a power of 2. Make the function
handle this case so callers don't have to worry about micro-optimizing it.
Signed-off-by: George Spelvin
On 06/08/2014 01:14 PM, George Spelvin wrote:
[ Please also Cc Hannes in your series. ]
Thank you! But there are two frequent kernel contributors with that name;
the other is Hannes Reinecke h...@suse.de.
I mean han...@stressinduktion.org which I already did for you. I
thought this would
On 06/07/2014 10:19 AM, George Spelvin wrote:
So it can be thrown away along with the code that uses it.
Signed-off-by: George Spelvin li...@horizon.com
Fine by me.
Acked-by: Daniel Borkmann dbork...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 06/07/2014 10:20 AM, George Spelvin wrote:
Unrolling code in single-use code paths is just silly. There are two
instances:
1) prandom_warmup() calls 10 times.
2) prandom_state_selftest() can avoid one call and simplify the
loop logic by repeating an assignment to a local variable
On 06/07/2014 10:22 AM, George Spelvin wrote:
The preferred Linux style for optional features is to define
no-op stub functions rather than wrap each call site in #ifdef.
Signed-off-by: George Spelvin li...@horizon.com
---
lib/random32.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 06/07/2014 10:25 AM, George Spelvin wrote:
The functions exist for a reason; the manual byte-at-a-time code
is unnecessarily slow (and bloated).
Signed-off-by: George Spelvin li...@horizon.com
Seems fine by me, since it's random anyway archs might not care
about the *_le32, though this
On 06/08/2014 01:30 PM, George Spelvin wrote:
Fine by me this cleanup, although not strictly needed.
Agreed. The timer slack is set to HZ (1 second) anyway.
It just dawned on me that a simpler and more efficient way to do this
(which I'll do in v2 of this) would be:
Note, when you talk
On 06/08/2014 02:42 PM, George Spelvin wrote:
Note, when you talk about efficiency here, this is called once every
40+ secs ... ;)
Agreed, in this case the code size saving (avoid a function call) is the
main benefit. And I prefer to avoid inefficiency on general priinciples,
if it's not
On 06/08/2014 07:34 PM, Hannes Frederic Sowa wrote:
...
Please check this as it makes the code more complicated and I doubt it is worth
it.
Agreed.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
On 06/08/2014 02:40 PM, George Spelvin wrote:
...
+ for (i = 0; i round_down(bytes, sizeof(u32)); i += sizeof(u32))
+ put_unaligned_le32(prandom_u32_state(state), p+i);
Nit: 'p + i'
I don't really care, but I'm happy without the spaces; I add them
to show what binds
-by: Xufeng Zhang xufeng.zh...@windriver.com
Looks good to me, thanks. This also needs to go to -stable.
Acked-by: Daniel Borkmann dbork...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
1 - 100 of 2268 matches
Mail list logo
