linux-kernel - Re: [PATCH v4 bpf-next 2/7] bpf: use bytes instead of pages for bpf_jit_[charge|uncharge]

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <24FE334F-1867-46A0-BB21-F10551CB1772@fb.com>
Date:   Thu, 20 Jan 2022 04:45:21 +0000
From:   Song Liu <songliubraving@...com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     Song Liu <song@...nel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "andrii@...nel.org" <andrii@...nel.org>,
        Kernel Team <Kernel-team@...com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v4 bpf-next 2/7] bpf: use bytes instead of pages for
 bpf_jit_[charge|uncharge]_modmem



> On Jan 19, 2022, at 8:10 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> 
> On Wed, Jan 19, 2022 at 03:06:15PM -0800, Song Liu wrote:
>> From: Song Liu <songliubraving@...com>
>> 
>> This enables sub-page memory charge and allocation.
>> 
>> Signed-off-by: Song Liu <songliubraving@...com>
>> 
[...]
>> @@ -808,7 +808,7 @@ int bpf_jit_add_poke_descriptor(struct bpf_prog *prog,
>> 	return slot;
>> }
>> 
>> -static atomic_long_t bpf_jit_current;
>> +static atomic64_t bpf_jit_current;
> 
> I don't understand the motivation for this change.
> bpf_jit_limit is type "long" and it's counting in bytes.
> So why change jit_current to atomic64?
> atomic_long will be fine even on 32-bit arch.
> What did I miss?

Hmm.. I think you are right. I guess I missed the fact that we use
long bpf_jit_limit. Will remove this change in the next version. 

Thanks,
Song