RE: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-14 Thread David Laight
From: Daniel Borkmann > Sent: 11 August 2017 17:47 > On 08/09/2017 10:34 PM, Daniel Borkmann wrote: > > On 08/09/2017 09:39 AM, James Hogan wrote: > > [...] > >> time (but please consider looking at the other patch which is certainly > >> a more real issue). > > > > Sorry for the delay, started loo

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-14 Thread James Hogan
On Fri, Aug 11, 2017 at 06:47:04PM +0200, Daniel Borkmann wrote: > Hi James, > > On 08/09/2017 10:34 PM, Daniel Borkmann wrote: > > On 08/09/2017 09:39 AM, James Hogan wrote: > > [...] > >> time (but please consider looking at the other patch which is certainly > >> a more real issue). > > > > Sor

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-11 Thread Daniel Borkmann
Hi James, On 08/09/2017 10:34 PM, Daniel Borkmann wrote: On 08/09/2017 09:39 AM, James Hogan wrote: [...] time (but please consider looking at the other patch which is certainly a more real issue). Sorry for the delay, started looking into that and whether we have some other options, I'll get

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-09 Thread Daniel Borkmann
On 08/09/2017 09:39 AM, James Hogan wrote: [...] time (but please consider looking at the other patch which is certainly a more real issue). Sorry for the delay, started looking into that and whether we have some other options, I'll get back to you on this. Thanks, Daniel

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-09 Thread James Hogan
On Tue, Aug 08, 2017 at 02:54:33PM -0700, David Miller wrote: > From: James Hogan > Date: Tue, 08 Aug 2017 22:20:05 +0100 > > > cool, i hadn't realised unmentioned elements in an initialiser are > > always zeroed, even when non-global/static, so had interpreted the > > whole array as uninitialise

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-08 Thread David Miller
From: James Hogan Date: Tue, 08 Aug 2017 22:20:05 +0100 > cool, i hadn't realised unmentioned elements in an initialiser are > always zeroed, even when non-global/static, so had interpreted the > whole array as uninitialised. learn something new every day :-) > sorry for the noise. You didn't ha

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-08 Thread James Hogan
On 8 August 2017 17:48:57 BST, David Miller wrote: >From: Daniel Borkmann >Date: Tue, 08 Aug 2017 10:46:52 +0200 > >> On 08/08/2017 12:25 AM, James Hogan wrote: >>> In bpf_trace_printk(), the elements in mod[] are left uninitialised, >>> but >>> they are then incremented to track the width of the

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-08 Thread David Miller
From: Daniel Borkmann Date: Tue, 08 Aug 2017 10:46:52 +0200 > On 08/08/2017 12:25 AM, James Hogan wrote: >> In bpf_trace_printk(), the elements in mod[] are left uninitialised, >> but >> they are then incremented to track the width of the formats. Zero >> initialise the array just in case the mem

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-08 Thread Daniel Borkmann
On 08/08/2017 12:25 AM, James Hogan wrote: In bpf_trace_printk(), the elements in mod[] are left uninitialised, but they are then incremented to track the width of the formats. Zero initialise the array just in case the memory contains non-zero values on entry. Fixes: 9c959c863f82 ("tracing: All

[RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

2017-08-07 Thread James Hogan
In bpf_trace_printk(), the elements in mod[] are left uninitialised, but they are then incremented to track the width of the formats. Zero initialise the array just in case the memory contains non-zero values on entry. Fixes: 9c959c863f82 ("tracing: Allow BPF programs to call bpf_trace_printk()")