netdev - Re: [PATCH v3 bpf-next 03/10] bpf: introduce per-cpu cgroup local storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 28 Sep 2018 14:03:29 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Roman Gushchin <guro@...com>
Cc:     netdev@...r.kernel.org, Song Liu <songliubraving@...com>,
        linux-kernel@...r.kernel.org, kernel-team@...com,
        Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH v3 bpf-next 03/10] bpf: introduce per-cpu cgroup local
 storage

On 09/28/2018 12:25 PM, Alexei Starovoitov wrote:
> On Fri, Sep 28, 2018 at 11:03:03AM +0100, Roman Gushchin wrote:
>>>> +
>>>> +	if (unlikely(map_flags & BPF_EXIST))
>>>> +		return -EINVAL;
>>>
>>> that should have been BPF_NOEXIST ?
>>
>> Yeah, or maybe even better s/&/!= ?
>> It's probably better to require BPF_EXIST flag to update a cgroup storage?
>> Agree? If so, let me fix this for both shared and per-cpu versions in
>> a follow-up patch.
> 
> I think BPF_ANY is technically valid too.
> If we were to require strict BPF_EXIST only, we'd need to fix stable too.
> I'm fine with both (BPF_EXIST only and BPF_ANY|BPF_EXIST).
> Daniel, what do you think?

I'm okay with either option, both seem plausible.