On Fri, Nov 13, 2020 at 12:57 PM Alexei Starovoitov
wrote:
>
> (a) is the only case.
Ok, good.
The (b) case is certainly valid in theory (and we might even
traditionaly have had something like that for things like ->comm[]
accesses, although I think we got rid of it).
But the (b) case is _so_
On Fri, Nov 13, 2020 at 12:10:57PM -0800, Linus Torvalds wrote:
> On Fri, Nov 13, 2020 at 11:17 AM Alexei Starovoitov
> wrote:
> >
> > The v4 approach preserves performance. It wasn't switching to
> > byte_at_a_time:
>
> That v4 looks better, but still pointless.
>
> But it might be
On Fri, Nov 13, 2020 at 11:17 AM Alexei Starovoitov
wrote:
>
> The v4 approach preserves performance. It wasn't switching to byte_at_a_time:
That v4 looks better, but still pointless.
But it might be acceptable, with that final
*out = (*out & ~mask) | (c & mask);
just replaced with
On Fri, Nov 13, 2020 at 11:17 AM Alexei Starovoitov
wrote:
>
> The destination buffer was already initialized with zeros before the call.
Side note: this is another example of you using the interface incorrectly.
You should *not* initialize the buffer with zeroes. That's just extra
work. One of
On Fri, Nov 13, 2020 at 11:17 AM Alexei Starovoitov
wrote:
>
> You misunderstood.
> BPF side does not depend on zero padding.
> The destination buffer was already initialized with zeros before the call.
> What BPF didn't expect is strncpy_from_user() copying extra garbage after NUL
> byte.
BPF
On Fri, Nov 13, 2020 at 10:08:02AM -0800, Linus Torvalds wrote:
> On Fri, Nov 13, 2020 at 9:03 AM Alexei Starovoitov
> wrote:
> >
> > Linus,
> > I think you might have an opinion about it.
> > Please see commit log for the reason we need this fix.
>
> Why is BPF doing this?
>
> The thing is, if
On Fri, Nov 13, 2020 at 9:03 AM Alexei Starovoitov
wrote:
>
> Linus,
> I think you might have an opinion about it.
> Please see commit log for the reason we need this fix.
Why is BPF doing this?
The thing is, if you care about the data after the strncpy, you should
be clearing it yourself.
The
On Wed, Nov 11, 2020 at 02:45:54PM -0800, Daniel Xu wrote:
> do_strncpy_from_user() may copy some extra bytes after the NUL
> terminator into the destination buffer. This usually does not matter for
> normal string operations. However, when BPF programs key BPF maps with
> strings, this matters a
do_strncpy_from_user() may copy some extra bytes after the NUL
terminator into the destination buffer. This usually does not matter for
normal string operations. However, when BPF programs key BPF maps with
strings, this matters a lot.
A BPF program may read strings from user memory by calling
On Wed, Nov 11, 2020 at 2:46 PM Daniel Xu wrote:
>
> do_strncpy_from_user() may copy some extra bytes after the NUL
> terminator into the destination buffer. This usually does not matter for
> normal string operations. However, when BPF programs key BPF maps with
> strings, this matters a lot.
>
10 matches
Mail list logo
