On Wed, Apr 1, 2015, at 19:55, David Miller wrote:
> From: Roman Gushchin
> Date: Wed, 01 Apr 2015 12:58:50 +0300
>
> > 31.03.2015, 23:49, "David Miller" :
> >> From: Hannes Frederic Sowa
> >> Date: Tue, 31 Mar 2015 22:35:48 +0200
> >>>
On Wed, Apr 1, 2015, at 19:55, David Miller wrote:
From: Roman Gushchin kl...@yandex-team.ru
Date: Wed, 01 Apr 2015 12:58:50 +0300
31.03.2015, 23:49, David Miller da...@davemloft.net:
From: Hannes Frederic Sowa han...@stressinduktion.org
Date: Tue, 31 Mar 2015 22:35:48 +0200
Could
ly or via RA).
> >
> > Due to dynamic nature of RA, setting MTU for default route will require
> > userspace agent, that will monitor changes of default route
> > and (re)configure it. Not simple. The suggested sysctl solves this
> > problem.
> >
> > S
for default route will require
userspace agent, that will monitor changes of default route
and (re)configure it. Not simple. The suggested sysctl solves this
problem.
Signed-off-by: Roman Gushchin kl...@yandex-team.ru
Acked-by: Hannes Frederic Sowa han...@stressinduktion.org
I don't
ace agent, that will monitor changes of default route
> and (re)configure it. Not simple. The suggested sysctl solves this
> problem.
>
> Signed-off-by: Roman Gushchin
Acked-by: Hannes Frederic Sowa
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
and (re)configure it. Not simple. The suggested sysctl solves this
problem.
Signed-off-by: Roman Gushchin kl...@yandex-team.ru
Acked-by: Hannes Frederic Sowa han...@stressinduktion.org
Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Hi,
On Wed, Mar 25, 2015, at 17:33, Roman Gushchin wrote:
> 25.03.2015, 18:52, "Hannes Frederic Sowa" :
> > On Wed, Mar 25, 2015, at 12:07, Roman Gushchin wrote:
> >> --- a/net/ipv6/route.c
> >> +++ b/net/ipv6/route.c
> >> @@ -1714,6 +1714,1
On Wed, Mar 25, 2015, at 12:07, Roman Gushchin wrote:
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1714,6 +1714,14 @@ int ip6_route_add(struct fib6_config *cfg)
>
> rt->rt6i_flags = cfg->fc_flags;
>
> + if ((cfg->fc_flags & (RTF_ADDRCONF | RTF_DEFAULT | RTF_GATEWAY))
>
On Wed, Mar 25, 2015, at 12:07, Roman Gushchin wrote:
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1714,6 +1714,14 @@ int ip6_route_add(struct fib6_config *cfg)
rt-rt6i_flags = cfg-fc_flags;
+ if ((cfg-fc_flags (RTF_ADDRCONF | RTF_DEFAULT | RTF_GATEWAY))
==
+
Hi,
On Wed, Mar 25, 2015, at 17:33, Roman Gushchin wrote:
25.03.2015, 18:52, Hannes Frederic Sowa han...@stressinduktion.org:
On Wed, Mar 25, 2015, at 12:07, Roman Gushchin wrote:
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1714,6 +1714,14 @@ int ip6_route_add(struct fib6_config
On Wed, Mar 18, 2015, at 18:41, Theodore Ts'o wrote:
> Maybe we should add a kernel self-test that automatically checks
> whether or not memset_explicit() gets optimized away? Otherwise we
> might not notice when gcc or how we implement barrier() or whatever
> else we end up using ends up
On Wed, Mar 18, 2015, at 13:42, Daniel Borkmann wrote:
> On 03/18/2015 01:20 PM, Stephan Mueller wrote:
> > Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:
> >>>> My proposal would be to add a
> >>>>
> >>>> #de
On Wed, Mar 18, 2015, at 13:14, Stephan Mueller wrote:
> Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:
>
> Hi Hannes,
>
> >On Wed, Mar 18, 2015, at 12:09, Stephan Mueller wrote:
> >> Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
&
On Wed, Mar 18, 2015, at 12:09, Stephan Mueller wrote:
> Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
> >On 03/18/2015 11:50 AM, Hannes Frederic Sowa wrote:
> >> On Wed, Mar 18, 2015, at 10:53, mancha wrote:
> >>> Hi.
> >>>
> &
On Wed, Mar 18, 2015, at 10:53, mancha wrote:
> Hi.
>
> The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect
> memory cleansing against things like dead store optimization:
>
>void memzero_explicit(void *s, size_t count)
>{
>memset(s, 0, count);
>
On Wed, Mar 18, 2015, at 10:53, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect
memory cleansing against things like dead store optimization:
void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
On Wed, Mar 18, 2015, at 13:14, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:
Hi Hannes,
On Wed, Mar 18, 2015, at 12:09, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
On 03/18/2015 11:50 AM, Hannes
On Wed, Mar 18, 2015, at 12:09, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
On 03/18/2015 11:50 AM, Hannes Frederic Sowa wrote:
On Wed, Mar 18, 2015, at 10:53, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777
On Wed, Mar 18, 2015, at 13:42, Daniel Borkmann wrote:
On 03/18/2015 01:20 PM, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:
My proposal would be to add a
#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ( : :
m(
({ struct { u8 b
On Wed, Mar 18, 2015, at 18:41, Theodore Ts'o wrote:
Maybe we should add a kernel self-test that automatically checks
whether or not memset_explicit() gets optimized away? Otherwise we
might not notice when gcc or how we implement barrier() or whatever
else we end up using ends up changing.
On Di, 2015-01-13 at 09:53 +0530, Rahul Sharma wrote:
> On Mon, Jan 12, 2015 at 5:21 PM, Pablo Neira Ayuso
> wrote:
> > On Mon, Jan 12, 2015 at 04:38:16PM +0530, Rahul Sharma wrote:
> >> Hi Pablo, Hannes
> >>
> >> On Fri, Jan 9, 2015 at 9:20 PM, Hannes
On Di, 2015-01-13 at 09:53 +0530, Rahul Sharma wrote:
On Mon, Jan 12, 2015 at 5:21 PM, Pablo Neira Ayuso pa...@netfilter.org
wrote:
On Mon, Jan 12, 2015 at 04:38:16PM +0530, Rahul Sharma wrote:
Hi Pablo, Hannes
On Fri, Jan 9, 2015 at 9:20 PM, Hannes Frederic Sowa
han
On Fr, 2015-01-09 at 12:45 +0100, Pablo Neira Ayuso wrote:
> Hi Hannes,
>
> On Fri, Jan 09, 2015 at 12:34:15PM +0100, Hannes Frederic Sowa wrote:
> > On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
> > > Hi Pablo,
> > >
> > > On Fri, Jan 9, 2015
On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
> Hi Pablo,
>
> On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso
> wrote:
> > On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> >> Hi Pablo,
> >>
> >> On Thu, Jan 8, 2015,
On Fr, 2015-01-09 at 12:45 +0100, Pablo Neira Ayuso wrote:
Hi Hannes,
On Fri, Jan 09, 2015 at 12:34:15PM +0100, Hannes Frederic Sowa wrote:
On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
Hi Pablo,
On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso pa...@netfilter.org
wrote
On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
Hi Pablo,
On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso pa...@netfilter.org
wrote:
On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
Hi Pablo,
On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
I'm
Hi Pablo,
On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> ipv6_find_hdr() function is designed to return the transport protocol.
> After the proposed change, it will return extension header numbers.
> This will break
On Do, 2015-01-08 at 02:18 +0530, Rahul Sharma wrote:
> Hi Hannes,
>
> On Wed, Jan 7, 2015 at 4:13 PM, Hannes Frederic Sowa
> wrote:
> > Hi,
> >
> > On Mi, 2015-01-07 at 11:11 +0530, Rahul Sharma wrote:
> >> On Wed, Jan 7, 2015 at 4:17 AM, Pablo Neira Ay
Hi Pablo,
On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
ipv6_find_hdr() function is designed to return the transport protocol.
After the proposed change, it will return extension header numbers.
This will break
On Do, 2015-01-08 at 02:18 +0530, Rahul Sharma wrote:
Hi Hannes,
On Wed, Jan 7, 2015 at 4:13 PM, Hannes Frederic Sowa
han...@stressinduktion.org wrote:
Hi,
On Mi, 2015-01-07 at 11:11 +0530, Rahul Sharma wrote:
On Wed, Jan 7, 2015 at 4:17 AM, Pablo Neira Ayuso pa...@netfilter.org
Hi,
On Mi, 2015-01-07 at 11:11 +0530, Rahul Sharma wrote:
> On Wed, Jan 7, 2015 at 4:17 AM, Pablo Neira Ayuso wrote:
> > On Wed, Jan 07, 2015 at 03:03:20AM +0530, Rahul Sharma wrote:
> >> ipv6_find_hdr() currently assumes that the next-header field in the
> >> fragment header of the non-first
Hi,
On Mi, 2015-01-07 at 11:11 +0530, Rahul Sharma wrote:
On Wed, Jan 7, 2015 at 4:17 AM, Pablo Neira Ayuso pa...@netfilter.org wrote:
On Wed, Jan 07, 2015 at 03:03:20AM +0530, Rahul Sharma wrote:
ipv6_find_hdr() currently assumes that the next-header field in the
fragment header of the
On Tue, Dec 16, 2014, at 22:47, Eric Dumazet wrote:
> On Tue, 2014-12-16 at 16:19 -0500, Sasha Levin wrote:
> > Hi Eric,
> >
> > While fuzzing with trinity on a -next kernel with the undefined behaviour
> > sanitizer path, I've observed the following warning in code which was
> > introduced in
On Tue, Dec 16, 2014, at 22:47, Eric Dumazet wrote:
On Tue, 2014-12-16 at 16:19 -0500, Sasha Levin wrote:
Hi Eric,
While fuzzing with trinity on a -next kernel with the undefined behaviour
sanitizer path, I've observed the following warning in code which was
introduced in 04ca6973f7
On Mon, Dec 8, 2014, at 17:19, George Spelvin wrote:
> >>> In case of openvswitch it shows a performance improvment. The seed
> >>> parameter could be used as an initial biasing of the crc32 function, but
> >>> in case of openvswitch it is only set to 0.
>
> >> NACK. [...]
>
> > Sorry for
Hi,
On Sun, Dec 7, 2014, at 22:33, George Spelvin wrote:
> On Sun, 2014-12-07 at 15:06 +0100, Hannes Frederic Sowa wrote:
> > In case of openvswitch it shows a performance improvment. The seed
> > parameter could be used as an initial biasing of the crc32 function, but
> > i
Hi,
On Sun, Dec 7, 2014, at 22:33, George Spelvin wrote:
On Sun, 2014-12-07 at 15:06 +0100, Hannes Frederic Sowa wrote:
In case of openvswitch it shows a performance improvment. The seed
parameter could be used as an initial biasing of the crc32 function, but
in case of openvswitch
On Mon, Dec 8, 2014, at 17:19, George Spelvin wrote:
In case of openvswitch it shows a performance improvment. The seed
parameter could be used as an initial biasing of the crc32 function, but
in case of openvswitch it is only set to 0.
NACK. [...]
Sorry for being unclear, I
On So, 2014-12-07 at 08:23 -0500, George Spelvin wrote:
> So there are plenty of hash tables in Linux that you don't dare use this
> with. In fact, so many that, as you rightly point out, it's not clear
> if it's worth providing this special optimization for the few remaining.
In case of
On So, 2014-12-07 at 14:41 +0100, Hannes Frederic Sowa wrote:
> On So, 2014-12-07 at 08:30 -0500, George Spelvin wrote:
> > Thanks for the encouragement!
> >
> > > Please consider xfs, too.
> > > AFAIK xfs doesn't seed their hashing so far and the hashing f
On So, 2014-12-07 at 08:30 -0500, George Spelvin wrote:
> Thanks for the encouragement!
>
> > Please consider xfs, too.
> > AFAIK xfs doesn't seed their hashing so far and the hashing function is
> > pretty weak. One example:
> > http://marc.info/?l=linux-xfs=139590613002926=2
>
> Is that
Hi,
On So, 2014-12-07 at 00:20 -0500, George Spelvin wrote:
> If you want DoS-resistant hash tables, I'm working on adding SipHash
> to the kernel.
>
> This is a keyed pseudo-random function designed specifically for that
> application. I am starting with ext4 directory hashes, and then
Hi,
On So, 2014-12-07 at 00:20 -0500, George Spelvin wrote:
If you want DoS-resistant hash tables, I'm working on adding SipHash
to the kernel.
This is a keyed pseudo-random function designed specifically for that
application. I am starting with ext4 directory hashes, and then intended
to
On So, 2014-12-07 at 08:30 -0500, George Spelvin wrote:
Thanks for the encouragement!
Please consider xfs, too.
AFAIK xfs doesn't seed their hashing so far and the hashing function is
pretty weak. One example:
http://marc.info/?l=linux-xfsm=139590613002926w=2
Is that something that
On So, 2014-12-07 at 14:41 +0100, Hannes Frederic Sowa wrote:
On So, 2014-12-07 at 08:30 -0500, George Spelvin wrote:
Thanks for the encouragement!
Please consider xfs, too.
AFAIK xfs doesn't seed their hashing so far and the hashing function is
pretty weak. One example:
http
On So, 2014-12-07 at 08:23 -0500, George Spelvin wrote:
So there are plenty of hash tables in Linux that you don't dare use this
with. In fact, so many that, as you rightly point out, it's not clear
if it's worth providing this special optimization for the few remaining.
In case of
On Do, 2014-12-04 at 23:56 +0800, Herbert Xu wrote:
> On Thu, Dec 04, 2014 at 02:08:50PM +0100, Hannes Frederic Sowa wrote:
> > By default the arch_fast_hash hashing function pointers are initialized
> > to jhash(2). If during boot-up a CPU with SSE4.2 is detected they get
> >
Hi Herbert,
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
> eliminate a large amount of
Hi Herbert,
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
eliminate a large amount of search
On Do, 2014-12-04 at 23:56 +0800, Herbert Xu wrote:
On Thu, Dec 04, 2014 at 02:08:50PM +0100, Hannes Frederic Sowa wrote:
By default the arch_fast_hash hashing function pointers are initialized
to jhash(2). If during boot-up a CPU with SSE4.2 is detected they get
updated to the CRC32 ones
On Fr, 2014-11-14 at 07:33 -0800, Alexei Starovoitov wrote:
> On Fri, Nov 14, 2014 at 4:11 AM, Hannes Frederic Sowa
> wrote:
> > On Do, 2014-11-13 at 17:36 -0800, Alexei Starovoitov wrote:
> >> the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
> >> eith
On Do, 2014-11-13 at 17:36 -0800, 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
On Do, 2014-11-13 at 17:36 -0800, 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
On Fr, 2014-11-14 at 07:33 -0800, Alexei Starovoitov wrote:
On Fri, Nov 14, 2014 at 4:11 AM, Hannes Frederic Sowa
han...@stressinduktion.org wrote:
On Do, 2014-11-13 at 17:36 -0800, Alexei Starovoitov wrote:
the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
either update
On Mi, 2014-11-12 at 15:33 -0700, Jim Davis wrote:
> Building with the attached random configuration file,
>
> ERROR: "reciprocal_value" [net/sched/sch_sfq.ko] undefined!
> ERROR: "reciprocal_value" [net/sched/sch_netem.ko] undefined!
Thanks for the report. I think moving reciproval_div.o from
On Mi, 2014-11-12 at 15:33 -0700, Jim Davis wrote:
Building with the attached random configuration file,
ERROR: reciprocal_value [net/sched/sch_sfq.ko] undefined!
ERROR: reciprocal_value [net/sched/sch_netem.ko] undefined!
Thanks for the report. I think moving reciproval_div.o from lib-y to
mization to verifier")
> Cc: Hannes Frederic Sowa
> Signed-off-by: Alexei Starovoitov
> ---
>
> while we were staring at the verifier code with Hannes during LPC
> something felt odd in this spot. Yes. It was a bug. Fix it.
>
> kernel/bpf/verifier.c |3 ++-
>
On Di, 2014-10-21 at 10:03 +0200, Thomas Petazzoni wrote:
> So, the question is: is this patch the correct solution (but then other
> usage of spin_lock in af_unix.c might also need fixing) ? Or is the
> network driver at fault?
It feels like a false positive. Do you see one core spinning tightly
On Di, 2014-10-21 at 10:03 +0200, Thomas Petazzoni wrote:
So, the question is: is this patch the correct solution (but then other
usage of spin_lock in af_unix.c might also need fixing) ? Or is the
network driver at fault?
It feels like a false positive. Do you see one core spinning tightly on
: Hannes Frederic Sowa han...@stressinduktion.org
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
---
while we were staring at the verifier code with Hannes during LPC
something felt odd in this spot. Yes. It was a bug. Fix it.
kernel/bpf/verifier.c |3 ++-
samples/bpf
On Mi, 2014-10-08 at 09:10 +, David Laight wrote:
> From: Hannes Frederic Sowa
> > I think David's concern was whether if 0 == false in all situations. It
> > is pretty clear that static memory is initialized to 0.
>
> I'm not 100% sure about that.
> static
On Mi, 2014-10-08 at 09:10 +, David Laight wrote:
From: Hannes Frederic Sowa
I think David's concern was whether if 0 == false in all situations. It
is pretty clear that static memory is initialized to 0.
I'm not 100% sure about that.
static pointers may be required to be initialised
On Di, 2014-10-07 at 22:49 +0200, Fabian Frederick wrote:
>
> > On 07 October 2014 at 22:33 Guenter Roeck wrote:
> >
> >
> > On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> > > From: Fabian Frederick
> > > Date: Tue, 7 Oct 2014 22:16:36 +0200
> > >
> > > > static values are
On Di, 2014-10-07 at 16:18 -0400, David Miller wrote:
> From: Fabian Frederick
> Date: Tue, 7 Oct 2014 22:16:36 +0200
>
> > static values are automatically initialized to NULL
> >
> > Signed-off-by: Fabian Frederick
>
> Isn't there some implementation room given to compilers
> as to the
On Di, 2014-10-07 at 16:18 -0400, David Miller wrote:
From: Fabian Frederick f...@skynet.be
Date: Tue, 7 Oct 2014 22:16:36 +0200
static values are automatically initialized to NULL
Signed-off-by: Fabian Frederick f...@skynet.be
Isn't there some implementation room given to compilers
On Di, 2014-10-07 at 22:49 +0200, Fabian Frederick wrote:
On 07 October 2014 at 22:33 Guenter Roeck li...@roeck-us.net wrote:
On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
From: Fabian Frederick f...@skynet.be
Date: Tue, 7 Oct 2014 22:16:36 +0200
static
On Di, 2014-09-30 at 11:18 +, David Laight wrote:
> From: Hannes Frederic
> > On Di, 2014-09-30 at 08:20 +, David Laight wrote:
> > > From: Hannes Frederic
> > > > On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
> > > > > On Mon, Sep 29, 2014 at 4:04 AM, David Laight
> > > > > wrote:
On Di, 2014-09-30 at 08:20 +, David Laight wrote:
> From: Hannes Frederic
> > On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
> > > On Mon, Sep 29, 2014 at 4:04 AM, David Laight
> > > wrote:
> > > > From: Kees Cook
> > > >> This makes the size argument a const, since it is always
On Di, 2014-09-30 at 08:20 +, David Laight wrote:
From: Hannes Frederic
On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
On Mon, Sep 29, 2014 at 4:04 AM, David Laight david.lai...@aculab.com
wrote:
From: Kees Cook
This makes the size argument a const, since it is always
On Di, 2014-09-30 at 11:18 +, David Laight wrote:
From: Hannes Frederic
On Di, 2014-09-30 at 08:20 +, David Laight wrote:
From: Hannes Frederic
On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
On Mon, Sep 29, 2014 at 4:04 AM, David Laight
david.lai...@aculab.com
On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
> On Mon, Sep 29, 2014 at 4:04 AM, David Laight wrote:
> > From: Kees Cook
> >> This makes the size argument a const, since it is always populated by
> >> the caller.
> >
> > There is almost no point making parameters 'const.
> > ('const foo *'
On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
On Mon, Sep 29, 2014 at 4:04 AM, David Laight david.lai...@aculab.com wrote:
From: Kees Cook
This makes the size argument a const, since it is always populated by
the caller.
There is almost no point making parameters 'const.
('const
On Sa, 2014-09-13 at 01:27 -0700, Shakil A Khan wrote:
> Signed-off-by: Shakil A Khan
> ---
> net/core/dst.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/dst.c b/net/core/dst.c
> index a028409..6a848b0 100644
> --- a/net/core/dst.c
> +++ b/net/core/dst.c
easily trigger), we'd
> kfree() the vmalloc()ed memory, and leak the internal bpf_work_struct.
>
> Signed-off-by: Sasha Levin
Yeah, thanks, we missed that somehow.
Acked-by: Hannes Frederic Sowa
Bye,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
() the vmalloc()ed memory, and leak the internal bpf_work_struct.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
Yeah, thanks, we missed that somehow.
Acked-by: Hannes Frederic Sowa han...@stressinduktion.org
Bye,
Hannes
--
To unsubscribe from this list: send the line unsubscribe linux
On Sa, 2014-09-13 at 01:27 -0700, Shakil A Khan wrote:
Signed-off-by: Shakil A Khan shakilk1...@gmail.com
---
net/core/dst.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index a028409..6a848b0 100644
--- a/net/core/dst.c
+++
On Fr, 2014-09-05 at 14:09 -0700, Joe Perches wrote:
> On Fri, 2014-09-05 at 22:39 +0200, Hannes Frederic Sowa wrote:
> > As announced in [1] gcc will increase its major number yearly but we don't
> > need to include gcc version specific quirks for every version normally.
>
Frederic Sowa
---
include/linux/{compiler-gcc.h => compiler-gcc/gcc.h} | 12 ++--
include/linux/{compiler-gcc3.h => compiler-gcc/gcc3.h} | 0
include/linux/{compiler-gcc4.h => compiler-gcc/gcc4.h} | 0
include/linux/compiler.h | 2 +-
4 files ch
On Fr, 2014-09-05 at 11:58 -0700, Cong Wang wrote:
> On Fri, Sep 5, 2014 at 11:53 AM, David Miller wrote:
> > From: Sabrina Dubroca
> > Date: Tue, 2 Sep 2014 10:29:29 +0200
> >
> >> Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
> >> triggers the assertion in
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 code that
> > reads the 32-bit word,
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 code that
reads the 32-bit word, modifies the
On Fr, 2014-09-05 at 11:58 -0700, Cong Wang wrote:
On Fri, Sep 5, 2014 at 11:53 AM, David Miller da...@davemloft.net wrote:
From: Sabrina Dubroca s...@queasysnail.net
Date: Tue, 2 Sep 2014 10:29:29 +0200
Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
triggers the
Perches j...@perches.com
Cc: Richard Weinberger richard.weinber...@gmail.com
Signed-off-by: Hannes Frederic Sowa han...@stressinduktion.org
---
include/linux/{compiler-gcc.h = compiler-gcc/gcc.h} | 12 ++--
include/linux/{compiler-gcc3.h = compiler-gcc/gcc3.h} | 0
include/linux
On Fr, 2014-09-05 at 14:09 -0700, Joe Perches wrote:
On Fri, 2014-09-05 at 22:39 +0200, Hannes Frederic Sowa wrote:
As announced in [1] gcc will increase its major number yearly but we don't
need to include gcc version specific quirks for every version normally.
This patch allows
On Do, 2014-09-04 at 23:37 -0400, Sasha Levin wrote:
> On 09/04/2014 07:47 PM, Joe Perches wrote:
> > On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
> >> > Most statements are already depending on GCC_VERSION, maybe we can just
> >> > unify all g
Hello,
On Thu, Sep 4, 2014, at 23:25, Aaro Koskinen wrote:
> On Thu, Sep 04, 2014 at 11:37:19AM -0400, Sasha Levin wrote:
> > We're missing include/linux/compiler-gcc5.h which is required now
> > because gcc branched off to v5 in trunk.
> >
> > Just copy the relevant bits out of
Hello,
On Thu, Sep 4, 2014, at 23:25, Aaro Koskinen wrote:
On Thu, Sep 04, 2014 at 11:37:19AM -0400, Sasha Levin wrote:
We're missing include/linux/compiler-gcc5.h which is required now
because gcc branched off to v5 in trunk.
Just copy the relevant bits out of
On Do, 2014-09-04 at 23:37 -0400, Sasha Levin wrote:
On 09/04/2014 07:47 PM, Joe Perches wrote:
On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
Most statements are already depending on GCC_VERSION, maybe we can just
unify all gcc specific headers to one, still trying
On Tue, Sep 2, 2014, at 23:40, Eric Dumazet wrote:
> On Tue, 2014-09-02 at 14:31 -0700, Alexei Starovoitov wrote:
>
> > > +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
> > > +{
> > > + set_memory_rw((unsigned long)fp, fp->pages);
> >
> > why rw is needed?
> > since fp is
On Tue, Sep 2, 2014, at 23:31, Alexei Starovoitov wrote:
> On Tue, Sep 2, 2014 at 1:53 PM, Hannes Frederic Sowa
> wrote:
> > From: Daniel Borkmann
> >
> > With eBPF getting more extended and exposure to user space is on it's way,
> > hardening the memory range the
inspection of kernel_page_tables. Brad Spengler proposed the same idea
via Twitter during development of this patch.
Joint work with Hannes Frederic Sowa.
Suggested-by: Brad Spengler
Signed-off-by: Daniel Borkmann
Signed-off-by: Hannes Frederic Sowa
Cc: Alexei Starovoitov
Cc: Kees Cook
---
ame idea
via Twitter during development of this patch.
Joint work with Hannes Frederic Sowa.
Suggested-by: Brad Spengler
Signed-off-by: Daniel Borkmann
Signed-off-by: Hannes Frederic Sowa
Cc: Alexei Starovoitov
Cc: Kees Cook
---
arch/arm/net/bpf_jit_32.c | 3 +-
arch/mips/net/bpf_jit.c
On Di, 2014-09-02 at 11:40 -0700, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 11:18 AM, Hannes Frederic Sowa
> wrote:
> > Those ASSERT_RTNLs were misplaced and only caught the callers mostly
> > from addrconf.c. I don't mind getting reports from stable kernel users
> &g
On Tue, Sep 2, 2014, at 20:04, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
> wrote:
> > Hi Cong,
> >
> > On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
> >> On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
> >
Hi Cong,
On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
> On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
> wrote:
> >
> > Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
> > to change dev_get_by_flags, but as this is the only user it s
abrina Dubroca
> Reported-by: Tommi Rantala
> ---
> As was said earlier, this should go in stable.
>
> v2:
> - based on net
> - keep dev_get_by_flags_rcu and RCU in ipv6_sock_ac_*
> - remove two ASSERT_RTNL() that are not necessary
>
> Thank you for your he
! ;)
Acked-by: Hannes Frederic Sowa han...@stressinduktion.org
--
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
Please read the FAQ at http://www.tux.org
Hi Cong,
On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
han...@stressinduktion.org wrote:
Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
to change dev_get_by_flags, but as this is the only user it sure
On Tue, Sep 2, 2014, at 20:04, Cong Wang wrote:
On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
han...@stressinduktion.org wrote:
Hi Cong,
On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
han...@stressinduktion.org wrote
On Di, 2014-09-02 at 11:40 -0700, Cong Wang wrote:
On Tue, Sep 2, 2014 at 11:18 AM, Hannes Frederic Sowa
han...@stressinduktion.org wrote:
Those ASSERT_RTNLs were misplaced and only caught the callers mostly
from addrconf.c. I don't mind getting reports from stable kernel users
and fixing
401 - 500 of 916 matches
Mail list logo
