linux-kernel - Re: [PATCH v2 bpf-next 1/3] perf: enable branch record for software events

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: <106E85E3-D30C-48BC-8EB6-8DFEEECF2022@fb.com>
Date:   Mon, 30 Aug 2021 16:36:44 +0000
From:   Song Liu <songliubraving@...com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     "open list:BPF (Safe dynamic programs and tools)" 
        <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        kajoljain <kjain@...ux.ibm.com>, Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next 1/3] perf: enable branch record for software
 events



> On Aug 30, 2021, at 9:06 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> 
> On Mon, Aug 30, 2021 at 03:25:44PM +0000, Song Liu wrote:
>> Thanks for these information! I did get confused these macros for quite a 
>> while. Let me try with the _RET0 version.
> 
> Does you kernel have:
> 
>  9ae6ab27f44e ("static_call: Update API documentation")
> 
> ?
> 
> With that included, the comment at the top of static_call.h reads like
> the below. Please let me know where you think this can be improved.

Aha, my kernel has the code for _RET0 part, but not the documentation. 

> 
> /*
> * Static call support
> *
> * Static calls use code patching to hard-code function pointers into direct
> * branch instructions. They give the flexibility of function pointers, but
> * with improved performance. This is especially important for cases where
> * retpolines would otherwise be used, as retpolines can significantly impact
> * performance.
> *

[...]

> *
> * Notes on NULL function pointers:
> *
> *   Static_call()s support NULL functions, with many of the caveats that
> *   regular function pointers have.
> *
> *   Clearly calling a NULL function pointer is 'BAD', so too for
> *   static_call()s (although when HAVE_STATIC_CALL it might not be immediately
> *   fatal). A NULL static_call can be the result of:
> *

Probably add:

 *     /* for function that returns NULL */
> *     DECLARE_STATIC_CALL_NULL(my_static_call, void (*)(int));


 *   or 
 *     /* for function that returns int */
 *     DECLARE_STATIC_CALL_RET0(my_static_call, int (*)(int));
 * 

So it is clear that we need two different macros. IIUC, the number and 
type of arguments doesn't matter? 

Also, the default return int function has to return 0, right? Can we let 
it return -EOPNOSUPP? 


> *
> *   which is equivalent to declaring a NULL function pointer with just a
> *   typename:
> *
> *     void (*my_func_ptr)(int arg1) = NULL;
> *

[...]

> *   which will include the required value tests to avoid NULL-pointer
> *   dereferences.
> *


> *   To query which function is currently set to be called, use:
> *
> *   func = static_call_query(name);

Maybe move above two lines to "Usage example:" section? 

Thanks,
Song