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
Date: Fri, 15 Mar 2013 19:10:51 -0700
Any way we can avoid adding this to fast path, for people not using
macvtap and ixgbe ?
Likew
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
ction for (e.g.) the crypto and networking subsystems.
Signed-off-by: Daniel Borkmann
---
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..cf42800 1
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?
As the
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. I
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. Wha
On Tue, Sep 4, 2012 at 4:16 PM, Iulius Curt 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 socket in a network
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/rando
prandom_u32_max() generates numbers in [0, end] interval.
Signed-off-by: Daniel Borkmann
Cc: Theodore Ts'o
Cc: Joe Perches
Cc: linux-kernel@vger.kernel.org
---
include/linux/random.h | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/linux/rando
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: D
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 ob
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 ("ne
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 wrote:
From: Eliezer Tamir
Date: Tue, 11 Jun 2013 17:24:28 +0300
depends on X86_TSC
Wait a second, I didn't notice this before. There ne
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/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/27/2013 09:42 AM, Andy Shevchenko wrote:
On Thu, 2013-06-27 at 14:43 +0800, Cong Wang wrote:
Cc: Daniel Borkmann
Signed-off-by: Cong Wang
I was about to answer for the Daniel's patch about %pig.
Daniel, could you resend your patch series to the LKML, since it touches
lib/vspri
lly.
Likely, there are many other areas than just SCTP in the kernel to make
use of this extension as well.
Signed-off-by: Daniel Borkmann
CC: linux-kernel@vger.kernel.org
---
v1->v2:
- Added documentation into printk-formats.txt, thanks Vlad Yasevich
- Changed %pig/%pIg into %piS/%pIS, th
essed format specified by 'c' and
various other IPv4 extensions as stated in the documentation part.
Likely, there are many other areas than just SCTP in the kernel to make
use of this extension as well.
[1] http://patchwork.ozlabs.org/patch/31480/
Signed-off-by: Daniel Borkmann
CC:
This might have been an oversight, as '4' is needed as %pI4/%pi4
are format specifiers and [hnbl] are extensions of it.
Signed-off-by: Daniel Borkmann
CC: Joe Perches
---
Documentation/printk-formats.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentat
On 06/28/2013 05:44 PM, Joe Perches wrote:
On Fri, 2013-06-28 at 14:05 +0200, Daniel Borkmann wrote:
In order to avoid making code that deals with printing both, IPv4 and
IPv6 addresses, unnecessary complicated as for example ...
Thanks Daniel, seems sensible. Just trivial comments...
Ok
On 06/28/2013 05:53 PM, Daniel Borkmann wrote:
On 06/28/2013 05:44 PM, Joe Perches wrote:
On Fri, 2013-06-28 at 14:05 +0200, Daniel Borkmann wrote:
In order to avoid making code that deals with printing both, IPv4 and
IPv6 addresses, unnecessary complicated as for example ...
Thanks Daniel
On 06/28/2013 06:04 PM, Joe Perches wrote:
On Fri, 2013-06-28 at 17:53 +0200, Daniel Borkmann wrote:
On 06/28/2013 05:44 PM, Joe Perches wrote:
On Fri, 2013-06-28 at 14:05 +0200, Daniel Borkmann wrote:
In order to avoid making code that deals with printing both, IPv4 and
IPv6 addresses
essed format specified by 'c' and
various other IPv4 extensions as stated in the documentation part.
Likely, there are many other areas than just SCTP in the kernel to make
use of this extension as well.
[1] http://patchwork.ozlabs.org/patch/31480/
Signed-off-by: Daniel Borkmann
CC:
: Daniel Borkmann
---
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 ktime_add_safe(const
roseconds and one in nanoseconds with the
macro NSEC_PER_USEC.
Signed-off-by: Liu Ying
Cc: David S. Miller
Cc: Daniel Borkmann
Cc: Thomas Gleixner
Cc: John Stultz
---
include/linux/ktime.h |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/ktime.h b/i
On 05/07/2013 11:08 AM, Liu Ying wrote:
2013/5/7 Liu Ying
2013/5/7 Daniel Borkmann
On 05/06/2013 02:42 PM, y...@shlinux1.ap.freescale.net wrote:
From: Liu Ying
If you only have 1 patch, then you don't need "1/1" in the subject.
The term magic number here might be a lit
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, "filte
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 se
On 04/25/2013 01:04 PM, Alexandru Copot wrote:
Signed-of-by Alexandru Copot
Cc: Daniel Baluta
---
tools/testing/selftests/Makefile| 3 +-
tools/testing/selftests/lib/Makefile| 14 +++
tools/testing/selftests/lib/selftests.c | 57
tools/testing/
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 ref
On 04/26/2013 02:31 PM, Xi Wang wrote:
On Fri, Apr 26, 2013 at 7:46 AM, Daniel Borkmann 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/233416/
Thank
On 04/26/2013 09:26 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann 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 jit_ctx *out_
On 04/26/2013 10:09 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann wrote:
On 04/26/2013 09:26 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann wrote:
On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
@@ -858,7 +858,7
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 sha
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
Cc: Daniel Borkmann
Cc: Heiko Carstens
Cc: Will Drewry
Cc: Eric Dumazet
Cc: Russell King
Cc: David Laight
Cc: "David S. Miller"
On 04/27/2013 08:32 PM, Xi Wang wrote:
On Sat, Apr 27, 2013 at 2:27 AM, Daniel Borkmann 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 in the other post i
Dumazet
Great work !
Probably other archs could later on follow-up with setting to read-only, too.
Reviewed-by: Daniel Borkmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
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
t
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
Date: Wed, 22 May 2013 00:14:58 -0700
On Wed, 22 May 2013 00:07:48 -0700 (PDT) David Miller
wrote:
From: Andrew Morton
Date: Tue, 21 May 2013 13:04:38 -0700
Nicolas, I think the patches need a re-check so I'll drop the vers
On 05/22/2013 01:54 AM, Stephen Rothwell wrote:
Hi Daniel,
On Tue, 21 May 2013 09:44:13 +0200 Daniel Borkmann 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
wit
On 07/19/2016 06:34 PM, Alexei Starovoitov wrote:
On Tue, Jul 19, 2016 at 01:17:53PM +0200, Daniel Borkmann wrote:
+ return -EINVAL;
+
+ /* Is this a user address, or a kernel address? */
+ if (!access_ok(VERIFY_WRITE, to, size))
+ return -EINVAL
On 07/20/2016 05:02 AM, Alexei Starovoitov wrote:
On Wed, Jul 20, 2016 at 01:19:51AM +0200, Daniel Borkmann wrote:
On 07/19/2016 06:34 PM, Alexei Starovoitov wrote:
On Tue, Jul 19, 2016 at 01:17:53PM +0200, Daniel Borkmann wrote:
+ return -EINVAL;
+
+ /* Is this a user
On 07/20/2016 11:58 AM, Sargun Dhillon wrote:
[...]
So, with that, what about the following:
It includes
-Desupporting no MMU platforms as we've deemed them incapable of being
safe
-Checking that we're not in a kthread
-Checking that the active mm is the thread's mm
-A log message indicating th
On 07/21/2016 12:47 PM, Sargun Dhillon wrote:
On Thu, Jul 21, 2016 at 01:00:51AM +0200, Daniel Borkmann wrote:
[...]
I don't really like couple of things, your ifdef CONFIG_MMU might not be
needed I think, couple of these checks seem redundant, (I'm not yet sure
about the task-&
: 555c8a8623a3 ("bpf: avoid stack copy and use skb ctx for event output")
Fixes: 7e3f977edd0b ("perf, events: add non-linear data support for raw
records")
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
include/linux/bpf.h| 2 +-
include/linux/perf_eve
f crashing
the system, we print a warning on invocation.
It was tested with the tracex7 program on x86-64.
Signed-off-by: Sargun Dhillon
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
---
include/uapi/linux/bpf.h | 12
kernel/bpf/verifier.c | 9 +
kernel/trace/bpf_tra
. However, this fix is important for
future unprivileged eBPF program types which could use pointers in their
context.
Signed-off-by: Mickaël Salaün
Fixes: 969bf05eb3ce ("bpf: direct packet access")
Cc: Alexei Starovoitov
Cc: Andy Lutomirski
Cc: Daniel Borkmann
Cc: Kees Cook
Acked-by: Sarg
On 09/02/2016 08:39 AM, David Miller wrote:
From: Eric Dumazet
Date: Wed, 31 Aug 2016 10:42:29 -0700
From: Eric Dumazet
A while back, Paolo and Hannes sent an RFC patch adding threaded-able
napi poll loop support : (https://patchwork.ozlabs.org/patch/620657/)
The problem seems to be that so
On 09/23/2016 10:35 PM, Naveen N. Rao wrote:
In line with similar support for other architectures by Daniel Borkmann.
'MOD Default X' from test_bpf without constant blinding:
84 bytes emitted from JIT compiler (pass:3, flen:7)
d58a4688 + :
0: nop
4: nop
8: std
On 09/23/2016 10:35 PM, Naveen N. Rao wrote:
Tail calls allow JIT'ed eBPF programs to call into other JIT'ed eBPF
programs. This can be achieved either by:
(1) retaining the stack setup by the first eBPF program and having all
subsequent eBPF programs re-using it, or,
(2) by unwinding/tearing dow
On 09/26/2016 10:56 AM, Naveen N. Rao wrote:
On 2016/09/24 03:30AM, Alexei Starovoitov wrote:
On Sat, Sep 24, 2016 at 12:33:54AM +0200, Daniel Borkmann wrote:
On 09/23/2016 10:35 PM, Naveen N. Rao wrote:
Tail calls allow JIT'ed eBPF programs to call into other JIT'ed eBPF
programs
Starovoitov
Cc: Daniel Borkmann
Seems okay to me:
Acked-by: Daniel Borkmann
Shaohua,
On 09/27/2016 01:51 AM, Alexei Starovoitov wrote:
On Mon, Sep 26, 2016 at 11:14:50AM -0700, Shaohua Li wrote:
put_cpu_var takes the percpu data, not the data returned from
get_cpu_var.
This doesn't change the behavior.
Cc: Tejun Heo
Cc: Alexei Starovoitov
Signed-off-by: Shaohua Li
On 09/06/2016 11:03 PM, Kees Cook wrote:
On Sat, Sep 3, 2016 at 8:15 AM, Dmitry Vyukov wrote:
Hello,
While running syzkaller fuzzer I've got the following GPF:
general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU
On 09/08/2016 09:01 AM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Thu, Sep 08, 2016 at 08:30:52AM +0200, Ingo Molnar wrote:
Thanks for the fix. Just saw build bot complaining last night and
by the morning your fix is already here. Thanks!
Guys, this is the first time I saw this patch (an
On 09/01/2016 09:44 AM, Peter Zijlstra wrote:
On Wed, Aug 31, 2016 at 02:50:39PM -0700, Alexei Starovoitov wrote:
+static u32 pe_prog_convert_ctx_access(enum bpf_access_type type, int dst_reg,
+ int src_reg, int ctx_off,
+ s
On 08/04/2016 10:21 PM, John Fastabend wrote:
On 16-08-04 12:36 PM, kan.li...@intel.com wrote:
From: Kan Liang
To achieve better network performance, the key step is to distribute the
packets to dedicated queues according to policy and system run time
status.
This patch provides an interface
On 08/05/2016 12:54 AM, Andi Kleen wrote:
+1, I tried to bring this up here [1] in the last spin. I think only very
few changes would be needed, f.e. on eBPF side to add a queue setting
helper function which is probably straight forward ~10loc patch; and with
regards to actually picking it up aft
Hi Michael,
On 08/16/2017 07:15 AM, Michael Ellerman wrote:
The sysctl documentation states that the JIT is only available on
x86_64, which is no longer correct.
Update the list to include all architectures that enable HAVE_CBPF_JIT
or HAVE_EBPF_JIT under some configuration.
Signed-off-by: Mic
On 08/16/2017 01:10 PM, Michael Ellerman wrote:
Daniel Borkmann writes:
On 08/16/2017 07:15 AM, Michael Ellerman wrote:
The sysctl documentation states that the JIT is only available on
x86_64, which is no longer correct.
Update the list to include all architectures that enable HAVE_CBPF_JIT
).
Signed-off-by: Michael Ellerman
The last paragraph speaking about tcpdump, I can take care of
later, also given the patch is about updating list of archs, so
lgtm, thanks!
Acked-by: Daniel Borkmann
On 06/20/2017 03:34 AM, Shubham Bansal wrote:
Hi Daniel,
Sorry, had a travel over the weekend, so didn't read it in time.
What is the issue with imitating in JIT what the interpreter is
doing as a starting point? That should be generic enough to handle
any case.
Why not proceeding this way f
On 06/21/2017 04:26 PM, Shubham Bansal wrote:
[...]
So ultimately, we call helper_function which takes u64 as arguments
only. I know its asking a lot, but can you please confirm this asap? I
would like to start implementing it.
Yes, that is correct. I think it would be the better, more generic
On 06/21/2017 09:37 PM, Shubham Bansal wrote:
Hi Daniel,
Good news. Got the CALL to work.
[ 145.670882] test_bpf: Summary: 316 PASSED, 0 FAILED, [287/308 JIT'ed]
Awesome. Do you think with this implementation, the patch could get
accepted? If you think so, then I will send the patch in couple
get switch includes appropriate target specific files
while cross compiling
Tested on x86 and arm64.
Signed-off-by: Abhijit Ayarekar
Acked-by: Daniel Borkmann
[ +Tejun, Mark, John ]
On 10/16/2017 12:00 AM, Richard Weinberger wrote:
max_entries is user controlled and used as input for __alloc_percpu().
This function expects that the allocation size is a power of two and
less than PCPU_MIN_UNIT_SIZE.
Otherwise a WARN() is triggered.
Fixes: 11393cc9b9be
On 10/16/2017 08:18 PM, Richard Weinberger wrote:
task is never used in bpf_get_current_uid_gid(), kill it.
Signed-off-by: Richard Weinberger
---
kernel/bpf/helpers.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index e8845adcd15e..511c9d522c
On 10/16/2017 08:59 PM, Richard Weinberger wrote:
Am Montag, 16. Oktober 2017, 20:54:36 CEST schrieb Daniel Borkmann:
On 10/16/2017 08:18 PM, Richard Weinberger wrote:
task is never used in bpf_get_current_uid_gid(), kill it.
Signed-off-by: Richard Weinberger
---
kernel/bpf/helpers.c | 1
On 10/16/2017 09:22 PM, Richard Weinberger wrote:
[...]
So, I can happily squash 2/3 into 1/3 and resent.
Yeah, please just squash them.
Thanks,
Daniel
On 10/16/2017 08:18 PM, Richard Weinberger wrote:
Sadly we cannot use get_task_comm() since bpf_get_current_comm()
allows truncation.
Signed-off-by: Richard Weinberger
---
kernel/bpf/helpers.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
On 10/16/2017 10:55 PM, Richard Weinberger wrote:
Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel Borkmann:
struct task_struct *task = current;
+ task_lock(task);
strncpy(buf, task->comm, size);
+ task_unlock(task);
Wouldn't this potentially l
On 10/17/2017 12:10 AM, Alexei Starovoitov wrote:
On Mon, Oct 16, 2017 at 2:10 PM, Richard Weinberger wrote:
Am Montag, 16. Oktober 2017, 23:02:06 CEST schrieb Daniel Borkmann:
On 10/16/2017 10:55 PM, Richard Weinberger wrote:
Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel
On 10/17/2017 12:29 PM, Mark Rutland wrote:
On Mon, Oct 16, 2017 at 08:52:13PM +0200, Daniel Borkmann wrote:
[ +Tejun, Mark, John ]
On 10/16/2017 12:00 AM, Richard Weinberger wrote:
max_entries is user controlled and used as input for __alloc_percpu().
This function expects that the
pass
__GFP_NOWARN instead.
Fixes: 11393cc9b9be ("xdp: Add batching support to redirect map")
Reported-by: Mark Rutland
Reported-by: Shankara Pailoor
Reported-by: Richard Weinberger
Signed-off-by: Daniel Borkmann
Cc: John Fastabend
---
kernel/bpf/devmap.c | 5 +++--
1 file change
generically by supporting the
__GFP_NOWARN flag that users can then use with calling the
__alloc_percpu_gfp() helper instead.
Signed-off-by: Daniel Borkmann
Cc: Tejun Heo
Cc: Mark Rutland
---
mm/percpu.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/mm/percpu.c b
_SIZE checks, which are percpu allocator
internals and should not be used.
Thanks!
Daniel Borkmann (3):
mm, percpu: add support for __GFP_NOWARN flag
bpf: fix splat for illegal devmap percpu allocation
bpf: do not test for PCPU_MIN_UNIT_SIZE before percpu allocations
kernel/bpf/arraymap.c
() calls
which use the flag already.
Signed-off-by: Daniel Borkmann
---
kernel/bpf/arraymap.c | 2 +-
kernel/bpf/hashtab.c | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 98c0f00..e263673 100644
--- a/kernel/bpf/arraymap.c
On 10/17/2017 05:03 PM, David Laight wrote:
From: Daniel Borkmann
Sent: 17 October 2017 15:56
The set fixes a splat in devmap percpu allocation when we alloc
the flush bitmap. Patch 1 is a prerequisite for the fix in patch 2,
patch 1 is rather small, so if this could be routed via -net, for
On 05/26/2017 02:38 AM, David Daney wrote:
Since the eBPF machine has 64-bit registers, we only support this in
64-bit kernels. As of the writing of this commit log test-bpf is showing:
test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
All current test cases are successfully compile
On 05/26/2017 05:14 PM, Daniel Borkmann wrote:
On 05/26/2017 02:38 AM, David Daney wrote:
Since the eBPF machine has 64-bit registers, we only support this in
64-bit kernels. As of the writing of this commit log test-bpf is showing:
test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT&#x
On 05/26/2017 05:39 PM, David Daney wrote:
On 05/26/2017 08:14 AM, Daniel Borkmann wrote:
On 05/26/2017 02:38 AM, David Daney wrote:
Since the eBPF machine has 64-bit registers, we only support this in
64-bit kernels. As of the writing of this commit log test-bpf is showing:
test_bpf
On 05/26/2017 09:20 PM, David Daney wrote:
On 05/26/2017 12:09 PM, Daniel Borkmann wrote:
On 05/26/2017 05:39 PM, David Daney wrote:
On 05/26/2017 08:14 AM, Daniel Borkmann wrote:
On 05/26/2017 02:38 AM, David Daney wrote:
Since the eBPF machine has 64-bit registers, we only support this in
On 11/01/2017 06:00 PM, Josef Bacik wrote:
From: Josef Bacik
Error injection is sloppy and very ad-hoc. BPF could fill this niche
perfectly with it's kprobe functionality. We could make sure errors are
only triggered in specific call chains that we care about with very
specific situations. A
gical vs. bitwise operator")
Fixes: 3f7889c4c79b ("net: sched: cls_bpf: call block callbacks for offload)
Signed-off-by: Colin Ian King
Acked-by: Daniel Borkmann
, and I've verified this with
many randconfig builds
Fixes: 4f9218aaf8a4 ("bpf: move knowledge about post-translation offsets out of
verifier")
Signed-off-by: Arnd Bergmann
Acked-by: Daniel Borkmann
re")
Signed-off-by: Arnd Bergmann
Acked-by: Daniel Borkmann
LGTM, and bpf_analyzer() already has proper logic to bail out for
such cases (although only used by nfp right now, which is there
when NET is configured anyway).
Hi Josef,
one more issue I just noticed, see comment below:
On 11/02/2017 03:37 PM, Josef Bacik wrote:
[...]
diff --git a/include/linux/filter.h b/include/linux/filter.h
index cdd78a7beaae..dfa44fd74bae 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -458,7 +458,8 @@ struct
/lkml/2017/11/2/907).
Signed-off-by: Randy Dunlap
Cc: Andrea Arcangeli
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
For BPF bits:
Acked-by: Daniel Borkmann
On 11/03/2017 03:31 PM, Josef Bacik wrote:
On Fri, Nov 03, 2017 at 12:12:13AM +0100, Daniel Borkmann wrote:
Hi Josef,
one more issue I just noticed, see comment below:
On 11/02/2017 03:37 PM, Josef Bacik wrote:
[...]
diff --git a/include/linux/filter.h b/include/linux/filter.h
index
On 10/18/2017 03:25 PM, Tejun Heo wrote:
Hello, Daniel.
(cc'ing Dennis)
On Tue, Oct 17, 2017 at 04:55:51PM +0200, Daniel Borkmann wrote:
The set fixes a splat in devmap percpu allocation when we alloc
the flush bitmap. Patch 1 is a prerequisite for the fix in patch 2,
patch 1 is rather
On 10/18/2017 04:03 PM, Daniel Borkmann wrote:
On 10/18/2017 03:25 PM, Tejun Heo wrote:
Hello, Daniel.
(cc'ing Dennis)
On Tue, Oct 17, 2017 at 04:55:51PM +0200, Daniel Borkmann wrote:
The set fixes a splat in devmap percpu allocation when we alloc
the flush bitmap. Patch 1 is a prerequ
On 10/18/2017 05:28 PM, Alexei Starovoitov wrote:
On Wed, Oct 18, 2017 at 7:22 AM, Daniel Borkmann wrote:
Higher prio imo would be to make the allocation itself faster
though, I remember we talked about this back in May wrt hashtable,
but I kind of lost track whether there was an update on
On 10/19/2017 03:05 PM, Mark Brown wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/bpf/test_verifier.c
between commit:
28e33f9d78eef ("bpf: disallow arithmetic operations on context pointer")
from the net tree and commit:
22c8
On 10/19/2017 03:55 PM, Mark Brown wrote:
Hi all,
After merging the net-next tree, today's linux-next build (x86allmodconfig)
failed like this:
/home/broonie/tmpfs/next/kernel/bpf/verifier.c: In function 'check_mem_access':
/home/broonie/tmpfs/next/kernel/bpf/verifier.c:1010:12: error: passing
On 10/05/2015 10:48 PM, Alexei Starovoitov wrote:
In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent pointer leaks.
Verifier will prevent
- any arithmetic on pointers
(except R10+Imm which is used to compute stack addresses)
- comparison of pointers
- p
On 10/06/2015 09:13 AM, Ingo Molnar wrote:
* Alexei Starovoitov wrote:
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->cb[] (either from the current layer or an old
one from a different layer that
On 10/06/2015 10:20 AM, Ingo Molnar wrote:
* Daniel Borkmann wrote:
On 10/06/2015 09:13 AM, Ingo Molnar wrote:
* Alexei Starovoitov wrote:
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->
On 10/06/2015 02:51 AM, Alexei Starovoitov wrote:
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->cb[] (either from the current layer or an old
one from a different layer that the skb went thro
1 - 100 of 1279 matches
Mail list logo
