On 01/03/2015 10:40 PM, Richard Weinberger wrote:
...
I'll pick up this patch.
Thanks a lot, Richard!
--
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 at http://vger.kernel.org/majordomo-info.ht
00 D syscall_table_size
After:
$ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table"
U sys_writev
R sys_call_table
D syscall_table_size
Fixes: a074335a370e ("x86, um: Mark system call tables readonly")
Cc: H. Pet
0 t arch_local_irq_enable
r crc32ctable_le
t crc32_exit
--
0960 t test_buf
2000 r crc32table_be
4000 r crc32table_le
1d1056e5 A __crc_crc32_be
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52181
Signed-off-by: Daniel Borkman
On 01/03/2015 02:08 AM, Andrew Morton wrote:
On Sat, 03 Jan 2015 01:12:43 +0100 Daniel Borkmann wrote:
Seems a lot of fuss. Why are these tables cacheline aligned anyway?
To avoid one cache miss (most of the time, presumably) in a 16k table.
Pretty marginal benefit, I suspect.
I guess, it
On 01/03/2015 12:35 AM, Andrew Morton wrote:
On Wed, 31 Dec 2014 20:03:28 +0100 Daniel Borkmann wrote:
Commit 8f243af42ade ("sections: fix const sections for crc32 table")
The 8f243af42ade changelog is rather poor :(. With the help of this
changelog I can now see what 8f243a
000960 t test_buf
2000 r crc32table_be
4000 r crc32table_le
1d1056e5 A __crc_crc32_be
Signed-off-by: Daniel Borkmann
Cc: Joe Mario
---
Makefile | 5 +
lib/Makefile | 3 +++
lib/gen_crc32table.c | 21 +++--
s
On 12/08/2014 10:15 PM, Paul Bolle wrote:
On Mon, 2014-12-08 at 21:36 +0100, Paul Bolle wrote:
On Mon, 2014-12-08 at 20:41 +0100, Paul Bolle wrote:
Well, it seems the treewide "boolean" cleanup should be done first.
Removing support for "boolean" could than be a second, separate step.
Just to e
On 12/08/2014 08:13 PM, Paul Bolle wrote:
On Mon, 2014-12-08 at 19:51 +0100, Paul Bolle wrote:
This doesn't apply on next-20141208. What tree did you base this on?
I got it to apply on next-20141208 by dropping the hunk for
arch/cris/arch-v32/drivers/Kconfig and by making (trivial) context
cha
On 12/04/2014 04:47 PM, Herbert Xu wrote:
On Thu, Dec 04, 2014 at 04:43:31PM +0100, Daniel Borkmann wrote:
Hm, I thought the kernel doc on arch_fast_hash() in include/linux/hash.h
would give enough of a hint ...
I think something more explicit like "do not use this in a hash
table unles
On 12/04/2014 04:39 PM, Thomas Graf wrote:
On 12/04/14 at 11:29pm, Herbert Xu wrote:
On Thu, Dec 04, 2014 at 03:26:37PM +, Thomas Graf wrote:
As Daniel pointed out, this work originated for the OVS edge use
case where security is of less concern and the rehashing is
sufficient. Identifying
On 12/04/2014 01:34 PM, Hannes Frederic Sowa wrote:
On Do, 2014-12-04 at 16:11 +0800, Herbert Xu wrote:
While working on rhashtable it came to me that this whole concept
of arch_fast_hash is flawed. CRCs are linear functions so it's
fairly easy for an attacker to identify collisions or at least
suggested by Daniel Borkmann
Signed-off-by: Julia Lawall
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
Why? There's no dependancy on anything in the cryptodev tree,
memzero_explicit is in Linus's tree now.
Sorry, I guess this was n
On 12/01/2014 08:17 PM, Robert Święcki wrote:
Not sure, but I run it inside a pid/ipc/uts/etc/user-namespaces where
it operates with a full set of capabilities, so most of the SOCK_RAW
and tunnel-like-creating calls succeed, so maybe..
Ok thanks, can you post your .config?
http://alt.swiecki
On 12/01/2014 08:00 PM, Robert Święcki wrote:
2014-12-01 19:08 GMT+01:00 Daniel Borkmann :
Thanks for looking into it. I can try with your patch, but no
guarantees that the fuzzer will hit the same condition in some
reasonable time-frame. Will get back in some time with results.
Ok, thanks
ate a repro (userland code) which
can trigger this, I can give it a try.
Did by accident trinity create tunnels? It looks that upper layer
protocols (except SCTP) all allocate and reserve MAX_HEADER to
accommodate enough head room in worst case for possible tunnels.
2014-12-01 18:36 GMT+01:00 D
On 12/01/2014 05:49 PM, Robert Święcki wrote:
I don't have much more, cause my kernel is kASLRNized and gdb cannot
handle that, but pasting output from kdb. Maybe somebody will be able
to see something obvious.
<0>[93699.703244] skbuff: skb_under_panic: text:83cff03e
len:104 put:56 hea
On 12/01/2014 12:38 PM, Dan Carpenter wrote:
On Mon, Dec 01, 2014 at 02:29:57PM +0300, Dan Carpenter wrote:
On Mon, Dec 01, 2014 at 12:04:57PM +0100, Daniel Borkmann wrote:
Well, BSD has helpers such as bzero_explicit() for such cases to work
around this, which memzero_explicit() similarly
On 12/01/2014 12:29 PM, Dan Carpenter wrote:
On Mon, Dec 01, 2014 at 12:04:57PM +0100, Daniel Borkmann wrote:
Well, BSD has helpers such as bzero_explicit() for such cases to work
around this, which memzero_explicit() similarly does; see also [1].
[1] https://gcc.gnu.org/ml/gcc-help/2014-10
On 12/01/2014 11:27 AM, Dan Carpenter wrote:
On Mon, Aug 25, 2014 at 10:01:39PM +0200, Daniel Borkmann wrote:
zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being
On 11/28/2014 06:55 AM, Alexei Starovoitov wrote:
On Thu, Nov 27, 2014 at 1:52 AM, Daniel Borkmann wrote:
On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
classic BPF has a restriction that last insn is always BPF_RET.
eBPF doesn't have BPF_RET instruction and this restriction.
I
On 11/27/2014 02:35 PM, Дениска-редиска wrote:
hello,
i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
Time to time the server where ipvs runs master IP (VIP) get general protection
fault. Switching master to another server make no difference - after some time
GPF come. So
On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
classic BPF has a restriction that last insn is always BPF_RET.
eBPF doesn't have BPF_RET instruction and this restriction.
It has BPF_EXIT insn which can appear anywhere in the program
one or more times and it doesn't have to be last insn.
Fix eB
On 11/26/2014 05:58 PM, Joe Perches wrote:
...
imo existing code is fine and I don't think the time spent
reviewing such changes is worth it when there is no
improvement in readability.
+1
Is there any value in reordering these tests for frequency
or maybe using | instead of || to avoid multi
On 11/20/2014 09:47 AM, Julia Lawall wrote:
On Wed, 19 Nov 2014, SF Markus Elfring wrote:
Marcus, what tree are you looking at?
I dared to base this update suggestion on the source files
for Linux 3.17.3. Are newer software developments relevant here?
You should always use linux-next. You
On 11/19/2014 07:49 PM, SF Markus Elfring wrote:
Marcus, what tree are you looking at?
I dared to base this update suggestion on the source files
for Linux 3.17.3. Are newer software developments relevant here?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/net/sched/
P
On 11/19/2014 05:47 PM, John Fastabend wrote:
On 11/18/2014 12:26 PM, SF Markus Elfring wrote:
From: Markus Elfring
...
if (fp_old)
bpf_prog_destroy(fp_old);
-if (bpf_old)
-kfree(bpf_old);
+kfree(bpf_old);
return 0;
Maybe I need some coffee but I can'
On 11/12/2014 06:46 PM, Stephan Mueller wrote:
...
* I unconditionally use the memset after memcpy as you indicated. Once
the cryptodev tree contains the memzero_explicit call, I will start
picking up that function.
Herbert merged it actually in this morning, so it's already part of
the cryptod
On 11/12/2014 05:54 PM, Stephan Mueller wrote:
Am Mittwoch, 12. November 2014, 17:15:52 schrieb Daniel Borkmann:
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data wi
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback han
Hi Stephan,
On 11/11/2014 05:37 AM, Stephan Mueller wrote:
Zeroize the buffer holding the message digest calculated for the
consumer before the buffer is released by the hash AF_ALG interface
handler.
Signed-off-by: Stephan Mueller
---
crypto/algif_hash.c | 2 ++
1 file changed, 2 insertion
On 11/11/2014 05:16 AM, Stephan Mueller wrote:
...
That is a good idea.
Herbert: I can prepare a patch that uses memzero_explicit. However, your
current tree does not yet implement that function as it was added to Linus'
tree after you pulled from it.
Yep, Ted took it [1] on top of the random
On 11/05/2014 12:04 AM, Alexei Starovoitov wrote:
On Tue, Nov 4, 2014 at 1:25 AM, Daniel Borkmann wrote:
On 11/04/2014 03:54 AM, Alexei Starovoitov wrote:
the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
either update existing map element or create a new one.
Initially the plan
On 11/04/2014 08:28 PM, Fabian Frederick wrote:
Signed-off-by: Fabian Frederick
---
net/ipv4/esp4.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 360b565..9dd66ee 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -392,8 +39
On 11/04/2014 03:54 AM, Alexei Starovoitov wrote:
add new map type BPF_MAP_TYPE_ARRAY and its implementation
- optimized for fastest possible lookup()
. in the future verifier/JIT may recognize lookup() with constant key
and optimize it into constant pointer. Can optimize non-constant
On 11/04/2014 03:54 AM, Alexei Starovoitov wrote:
expose bpf_map_lookup_elem(), bpf_map_update_elem(), bpf_map_delete_elem()
map accessors to eBPF programs
Signed-off-by: Alexei Starovoitov
...
+#include
+#include
+
+/* called from eBPF program under rcu lock
+ *
+ * if kernel subsystem is
On 11/04/2014 03:54 AM, Alexei Starovoitov wrote:
the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
either update existing map element or create a new one.
Initially the plan was to add a new command to handle the case of
'create new element if it didn't exist', but 'flags' style loo
hen? Same accounts
for def_bool and def_boolean ... it would help to avoid confusion
to just have a single term for each.
Anyway, the rest looks good to me, thanks.
I am totally fine of having it under EXPERT for now for the reasons
mentioned above. This can still be lifted later on.
Acked-by:
On 10/20/2014 03:58 PM, Andrey Ryabinin wrote:
On 10/20/2014 04:49 PM, Theodore Ts'o wrote:
On Mon, Oct 20, 2014 at 03:03:22PM +0400, Andrey Ryabinin wrote:
Hi, Theodore.
I've got this while booting kernel with ubsan:
[0.00]
==
On 10/14/2014 10:43 AM, Alexei Starovoitov wrote:
On Tue, Oct 14, 2014 at 12:34 AM, Daniel Borkmann wrote:
On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:
On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann
wrote:
On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
...
Ok, given you post the
On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:
On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann wrote:
On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
...
Ok, given you post the remaining two RFCs later on this window as
you indicate, I have no objections:
Acked-by: Daniel Borkmann
On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
...
Ok, given you post the remaining two RFCs later on this window as
you indicate, I have no objections:
Acked-by: Daniel Borkmann
Ping, Alexei, are you still sending the patch for bpf_common.h or
do you want me to take care of this?
Cheers
On 10/10/2014 04:08 PM, Lubomir Rintel wrote:
NetworkManager might want to know that it changed when the router advertisement
arrives.
Signed-off-by: Lubomir Rintel
Cc: Hannes Frederic Sowa
Cc: Daniel Borkmann
---
net/ipv6/addrconf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net
On 10/01/2014 05:29 PM, Fengguang Wu wrote:
Hi Willem,
FYI, we noticed the below LTP failures on commit
4ed2d765dfaccff5ebdac68e2064b59125033a3b ("net-timestamp: TCP timestamping")
I think it already was discussed here:
http://www.spinics.net/lists/netdev/msg297822.html
--
To unsubscribe f
On 09/22/2014 02:06 AM, Alexei Starovoitov wrote:
...
v13 -> v14:
- small change to 1st patch to ease 'new userspace with old kernel'
problem (done similar to perf_copy_attr()) (suggested by Daniel)
Thanks for taking care of it.
--
To unsubscribe from this list: send the line "unsubscribe li
On 09/18/2014 05:24 PM, Alexei Starovoitov wrote:
...
solve or not. If we decide to solve it, we need to have
a plan to solve it all the way. Partial fix for size of bpf_attr
is not a plan. It's something that is not addressing the problem
completely. Little bit of help is not useful for userspac
On 09/18/2014 04:34 PM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann wrote:
...
Sure, you will never get a full compatibility on that regard
while backwards compatibility needs to be guaranteed on the
other hand. I looked at perf_copy_attr() implementation and I
On 09/18/2014 01:45 AM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov wrote:
Hm, thinking out loudly ... perhaps this could be made a library problem.
Such that the library which wraps the syscall needs to be aware of a
marker where the initial version ends, a
On 09/17/2014 06:17 PM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 12:16 AM, Daniel Borkmann wrote:
That actually still doesn't answer my question why the test stub
cannot live in lib/test_bpf where we have our actual testing
framework for eBPF/BPF, also since you exactly only
On 09/17/2014 07:03 PM, Daniel Borkmann wrote:
On 09/17/2014 06:08 PM, Alexei Starovoitov wrote:
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann wrote:
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD licens
On 09/17/2014 06:08 PM, Alexei Starovoitov wrote:
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann wrote:
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD license
+#defineBPF_PROG_LOAD_LAST_FIELD log_buf
I was looking
On 09/10/2014 08:08 PM, Alexei Starovoitov wrote:
On Wed, Sep 10, 2014 at 4:35 AM, Daniel Borkmann wrote:
Since we already have an extensive BPF test suite, that is, lib/test_bpf.c,
which currently also does sanity checks for the classic BPF verifier, is
there a reason these verifier test
On 09/17/2014 02:39 AM, Alexei Starovoitov wrote:
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64
fferent allocator.
JIT tested on aarch64 with BPF test suite.
Reference:
http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html
Signed-off-by: Daniel Borkmann
Cc: Zi Shen Lim
Cc: Will Deacon
Cc: Catalin Marinas
Cc: David S. Miller
Cc: Alexei Starovoitov
-
On 09/15/2014 11:30 PM, Will Deacon wrote:
Hi Daniel,
One small comment than I forgot to mention before (see below).
On Mon, Sep 15, 2014 at 09:20:23PM +0100, Daniel Borkmann wrote:
This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
jit against spraying at
fferent allocator.
JIT tested on aarch64 with BPF test suite.
Reference:
http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html
Signed-off-by: Daniel Borkmann
Cc: Zi Shen Lim
Cc: Will Deacon
Cc: Catalin Marinas
Cc: David S. Miller
Cc: Alexei Starovoitov
On 09/13/2014 06:32 AM, Z Lim wrote:
On Fri, Sep 12, 2014 at 10:35 AM, Daniel Borkmann wrote:
This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
jit against spraying attacks").
Thanks to commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX
suppor
e() the vmalloc()ed memory, and leak the internal bpf_work_struct.
Signed-off-by: Sasha Levin
[ This patch is for net-next. ]
Acked-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
Mor
On 09/12/2014 07:21 PM, Catalin Marinas wrote:
...
We don't have a brk instruction for arm32 but we have guaranteed
undefined space. Have a look at the kgdb support for example (or grep
for register_undef_hook under arch/arm) to get an idea.
Will do, thanks!
Last but not least ;), if I would
g structure, but instead bpf_prog_unlock_free() through
a different allocator.
JIT tested on aarch64 with BPF test suite.
Reference:
http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html
Signed-off-by: Daniel Borkmann
Cc: Zi Shen Lim
Cc: Will Deacon
Cc: Cat
On 09/12/2014 06:46 PM, Catalin Marinas wrote:
On Fri, Sep 12, 2014 at 05:21:27PM +0100, Daniel Borkmann wrote:
On 09/12/2014 06:03 PM, Catalin Marinas wrote:
On Fri, Sep 12, 2014 at 08:11:37AM +0100, Daniel Borkmann wrote:
Will, Catalin, Dave, this is more or less a heads-up: when net
On 09/12/2014 06:03 PM, Catalin Marinas wrote:
Daniel,
On Fri, Sep 12, 2014 at 08:11:37AM +0100, Daniel Borkmann wrote:
Will, Catalin, Dave, this is more or less a heads-up: when net-next and
arm64-next tree will get both merged into Linus' tree, we will run into
a 'sil
g structure, but instead bpf_prog_unlock_free() through
a different allocator.
JIT tested on aarch64 with BPF test suite.
Reference:
http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html
Signed-off-by: Daniel Borkmann
Reviewed-by: Zi Shen Lim
Cc: Will Deacon
On 09/10/2014 10:21 PM, Alexei Starovoitov wrote:
...
char bpf_log_buf[LOG_BUF_SIZE];
What happens if the size isn't LOG_BUF_SIZE?
would do you mean?
LOG_BUF_SIZE is just a user defined macro.
Can be anything.
I believe, Andy means, what would happen if log_level > 0 but
the
On 09/10/2014 07:32 PM, Alexei Starovoitov wrote:
On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann wrote:
struct { /* anonymous struct used by BPF_PROG_LOAD command */
enum bpf_prog_typeprog_type;
__u32 insn_cnt
offsets, but not the actual
allocated target image where opcodes are being stored. Fix it by
calling module_free() on dismantle time in case of errors.
Signed-off-by: Daniel Borkmann
Cc: Zi Shen Lim
Cc: Alexei Starovoitov
Cc: Will Deacon
---
[ Compile-tested only. ]
arch/arm64/net
On 09/10/2014 08:16 PM, Alexei Starovoitov wrote:
On Wed, Sep 10, 2014 at 4:24 AM, Daniel Borkmann wrote:
On 09/10/2014 07:10 AM, Alexei Starovoitov wrote:
move instruction macros (like BPF_MOV64_REG or BPF_ALU32_IMM)
from linux/filter.h into uapi/linux/bpf.h
so that userspace programs can
On 09/10/2014 06:50 PM, Randy Dunlap wrote:
On 09/10/14 01:59, Stephen Rothwell wrote:
Hi all,
Changes since 20140909:
When CONFIG_MODULES is not enabled: (seen on i386 and x86_64)
kernel/built-in.o: In function `bpf_jit_binary_alloc':
(.text+0x7689d): undefined reference to `module_alloc'
On 09/10/2014 03:23 PM, Markos Chandras wrote:
On 08/29/2014 04:33 PM, Daniel Borkmann wrote:
On 08/29/2014 04:23 PM, Markos Chandras wrote:
MIPS supports BPF JIT since v3.16-rc1
Cc: Randy Dunlap
Cc: "David S. Miller"
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
On 09/10/2014 07:10 AM, Alexei Starovoitov wrote:
1.
the library includes a trivial set of BPF syscall wrappers:
int bpf_create_map(int key_size, int value_size, int max_entries);
int bpf_update_elem(int fd, void *key, void *value);
int bpf_lookup_elem(int fd, void *key, void *value);
int bpf_del
On 09/10/2014 07:10 AM, Alexei Starovoitov wrote:
move instruction macros (like BPF_MOV64_REG or BPF_ALU32_IMM)
from linux/filter.h into uapi/linux/bpf.h
so that userspace programs can use them.
verifier testsuite (in later patches) will be using them.
Signed-off-by: Alexei Starovoitov
I don
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
BPF(2) Linux Programmer's ManualBPF(2)
...
union bpf_attr {
struct { /* anonymous struct used by BPF_MAP_CREATE command */
enum bpf_map_type map_type;
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
int map_fd;
void *key;
union {
void *value;
void *next_key;
};
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
As requested by Andy and others, here is the man page:
BPF(2) Linux Programmer's ManualBPF(2)
...
In the future maps can have different types: hash, array, bloom filter,
radix-tree, bu
On 09/10/2014 07:10 AM, Alexei Starovoitov wrote:
eBPF programs are similar to kernel modules. They are loaded by the user
process and automatically unloaded when process exits. Each eBPF program is
a safe run-to-completion set of instructions. eBPF verifier statically
determines that the program
On 09/05/2014 07:21 PM, Alexei Starovoitov wrote:
...
imo it's cleaner to convert to bool unconditionally instead
of annotating things everywhere.
Will do, fine as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On 09/05/2014 07:13 PM, Mikulas Patocka wrote:
On Fri, 5 Sep 2014, Daniel Borkmann wrote:
On 09/05/2014 07:00 PM, Hannes Frederic Sowa wrote:
On Fr, 2014-09-05 at 18:20 +0200, Daniel Borkmann wrote:
Hi Mikulas,
On 09/05/2014 06:01 PM, Mikulas Patocka wrote:
This patch fixes false positive
On 09/05/2014 07:00 PM, Hannes Frederic Sowa wrote:
On Fr, 2014-09-05 at 18:20 +0200, Daniel Borkmann wrote:
Hi Mikulas,
On 09/05/2014 06:01 PM, Mikulas Patocka wrote:
This patch fixes false positive kmemcheck warning in bpf.
When we try to write the variable len, the compiler generates a
Hi Mikulas,
On 09/05/2014 06:01 PM, Mikulas Patocka wrote:
This patch fixes false positive kmemcheck warning in bpf.
When we try to write the variable len, the compiler generates a code that
reads the 32-bit word, modifies the bits belonging to "len" and writes the
32-bit word back. The reading
later on this window as
you indicate, I have no objections:
Acked-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 info at http://vger.kernel.org/majordomo-info.html
Pleas
On 09/02/2014 11:31 PM, Alexei Starovoitov wrote:
...
+#ifdef CONFIG_DEBUG_SET_MODULE_RONX
+static inline void bpf_prog_lock_ro(struct bpf_prog *fp)
+{
+ set_memory_ro((unsigned long)fp, fp->pages);
since ronx are ifdef checked together,
would probably make sense to set nx too?
In case
On 08/30/2014 01:01 AM, Alexei Starovoitov wrote:
...
imo it's a consistency issue. If main uapi header is ebpf.h then
corresponding kernel internal header should be ebpf.h as well
and kernel/ebpf/ directory and so on.
I don't think that has to be enforced, but fair enough, if you
feel that way
On 08/30/2014 01:01 AM, Alexei Starovoitov wrote:
...
btw, I've spent last two days writing syscall manpage :(
What is the best way to present it for review?
If I just attach it raw, it's unreadable... I can include a link
to html page, but man2html produces ugly pages comparing
to what 'man' com
On 08/29/2014 08:02 PM, Alexei Starovoitov wrote:
On Fri, Aug 29, 2014 at 10:39 AM, Daniel Borkmann wrote:
On 08/27/2014 10:37 PM, Alexei Starovoitov wrote:
allow user space to generate eBPF programs
uapi/linux/bpf.h: eBPF instruction set definition
linux/filter.h: the rest
Very sorry
On 08/27/2014 10:37 PM, Alexei Starovoitov wrote:
allow user space to generate eBPF programs
uapi/linux/bpf.h: eBPF instruction set definition
linux/filter.h: the rest
Very sorry for being late, but just a thought since we're touching user
space headers anyway ...
Wouldn't it be more consist
On 08/29/2014 04:23 PM, Markos Chandras wrote:
MIPS supports BPF JIT since v3.16-rc1
Cc: Randy Dunlap
Cc: "David S. Miller"
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Cc: linux-...@vger.kernel.org
Signed-off-by: Markos Chandras
Acked-by: Daniel Borkmann
--
To unsubscribe from
On 08/27/2014 09:18 PM, Stephen Hemminger wrote:
Something in man page format similar to FreeBSD man page:
http://www.freebsd.org/cgi/man.cgi?bpf(4)
would be more readable and reviewable.
I think at some point, we could perhaps do a section 7 page
with a general overview of the engine and wh
On 08/26/2014 09:46 AM, Ingo Molnar wrote:
* Alexei Starovoitov wrote:
On Mon, Aug 25, 2014 at 8:52 PM, Stephen Hemminger
wrote:
Per discussion at Kernel Summit. Every new syscall requires
a manual page and test programs. We have had too many new syscalls
that are DOA.
There is verifier tes
On 08/25/2014 10:35 PM, Alexey Dobriyan wrote:
On Mon, Aug 25, 2014 at 10:01:39PM +0200, Daniel Borkmann wrote:
+void memzero_explicit(void *s, size_t count)
+{
+ memset(s, 0, count);
+ OPTIMIZER_HIDE_VAR(s);
+}
BSD seems to name it explicit_bzero().
Sure, that's what I wro
-by: zatim...@hotmail.co.uk
Signed-off-by: Daniel Borkmann
Cc: Hannes Frederic Sowa
Cc: Alexey Dobriyan
---
drivers/char/random.c | 8
include/linux/string.h | 5 +++--
lib/string.c | 16
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/char/
On 08/25/2014 02:13 PM, Rasmus Villemoes wrote:
A 9+ years old comment in hash_64 says that gcc can't optimize
multiplication by GOLDEN_RATIO_PRIME_64. Well, compilers get smarter
and CPUs get faster all the time, so it is perhaps about time to
revisit that assumption.
Seems fine by me, but Cc'
ggested-by: Vlad Yasevich
Suggested-by: Michael Tuexen
Suggested-by: Daniel Borkmann
Signed-off-by: Zhu Yanjun
Looks a bit better, thanks!
Acked-by: Daniel Borkmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
On 08/19/2014 10:15 AM, Sitsofe Wheeler wrote:
After a variety of issues on Hyper-V (host is running Windows 2012 R2) I
updated to the latest kernel (3.17-rc1
7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9), turned on a bunch of kernel
validation options and booted which has resulted in a BUG being
tri
On 08/15/2014 11:27 AM, Zhu Yanjun wrote:
When a failed probe comes along UNCONFIRMED path, it is not necessary
to send SCTP_PEER_ADDR_CHANGE notification.
I do not find this in the RFC, but it seems reasonable - at least, I would
have liked to see a more elaborate commit message from you expla
On 08/13/2014 07:34 PM, Alexei Starovoitov wrote:
On Wed, Aug 13, 2014 at 2:17 AM, Daniel Borkmann wrote:
On 08/13/2014 09:57 AM, Alexei Starovoitov wrote:
add BPF_LD_IMM64 instruction to load 64-bit immediate value into register.
All previous instructions were 8-byte. This is first 16-byte
On 08/13/2014 09:57 AM, Alexei Starovoitov wrote:
add BPF_LD_IMM64 instruction to load 64-bit immediate value into register.
All previous instructions were 8-byte. This is first 16-byte instruction.
Two consecutive 'struct bpf_insn' blocks are interpreted as single instruction:
insn[0/1].code = B
On 08/12/2014 02:57 AM, Alexei Starovoitov wrote:
On Mon, Aug 11, 2014 at 3:00 PM, Benjamin Lee wrote:
I wanted to know what the current status of my patch is since my
internship will be ending this Friday and I want to know before then. if
there are any problems with it I can fix them before T
In prandom we have already reseeding mechanisms that trigger
periodically from a much better entropy source than just
feeding in jiffies through lpfc_mbx_cmpl_fcf_scan_read_fcf_rec()
[what a function name 8-)]. Therefore, just remove this.
Signed-off-by: Daniel Borkmann
Cc: James Bottomley
Cc
On 07/25/2014 01:54 PM, Pablo Neira Ayuso wrote:
On Fri, Jul 25, 2014 at 01:25:35PM +0200, Daniel Borkmann wrote:
[ also Cc'ing Willem, Pablo ]
On 07/25/2014 10:04 AM, Alexei Starovoitov wrote:
'sk_filter' name is used as 'struct sk_filter', function sk_filter() a
[ also Cc'ing Willem, Pablo ]
On 07/25/2014 10:04 AM, Alexei Starovoitov wrote:
'sk_filter' name is used as 'struct sk_filter', function sk_filter() and
as variable 'sk_filter', which makes code hard to read.
Also it's easily confused with 'struct sock_filter'
Rename 'struct sk_filter' to 'struc
On 07/25/2014 01:26 AM, Alexei Starovoitov wrote:
...
you mean to align last \ with other lines?
sure. good point.
Yeah, would be good. Otherwise looks good, of course.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
1001 - 1100 of 1280 matches
Mail list logo
