lkml.org 
[lkml]   [2021]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v5 03/15] linkage: Add DECLARE_NOT_CALLED_FROM_C
    On Fri, Oct 15, 2021 at 10:57 AM Thomas Gleixner <tglx@linutronix.de> wrote:
    >
    > On Fri, Oct 15 2021 at 17:55, Thomas Gleixner wrote:
    > > On Thu, Oct 14 2021 at 19:51, Andy Lutomirski wrote:
    > >> On Wed, Oct 13, 2021, at 11:16 AM, Sami Tolvanen wrote:
    > > That still tells me:
    > >
    > > 1) This is a function
    > >
    > > 2) It has a regular argument which is expected to be in RDI
    > >
    > > which even allows to do analyis of e.g. the alternative call which
    > > invokes that function.
    > >
    > > DECLARE_NOT_CALLED_FROM_C(clear_page_erms);
    > >
    > > loses these properties and IMO it's a tasteless hack.
    >
    > Look:
    >
    > SYSCALL_DEFINE2(set_robust_list, struct robust_list_head __user *, head,
    > size_t, len)
    >
    > Not beautiful, but it gives the information which is needed and it tells
    > me clearly what this is about. While the above lumps everything together
    > whatever it is.

    Sure, that makes sense. Ignoring the macro for a moment, how do you
    feel about using incomplete structs for the non-C functions as Andy
    suggested?

    > Having __bikeshedme would allow to do:
    >
    > __hardware_call
    > __xenhv_call
    > __inline_asm_call
    >
    > or such, which clearly tells how the function should be used and it can
    > even be validated by tooling.

    Previously you suggested adding a built-in function to the compiler:

    https://lore.kernel.org/lkml/877dl0sc2m.ffs@nanos.tec.linutronix.de/

    I actually did implement this in Clang, but the feature wasn't
    necessary with opaque types, so I never moved forward with those
    patches. A built-in also won't make the code any cleaner, which was a
    concern last time.

    I do agree that a function attribute would look cleaner, but it won't
    stop anyone from mistakenly calling these functions from C code, which
    was something Andy wanted to address at the same time. Do you still
    prefer a function attribute over using an opaque type nevertheless?

    > You could to that with macros as well, but thats not what you offered.
    >
    > Seriously, if you want to sell me that stuff, then you really should
    > offer me something which has a value on its own and makes it palatable
    > to me. That's not something new. See:
    >
    > https://lore.kernel.org/lkml/alpine.LFD.2.00.1001251002430.3574@localhost.localdomain/
    >
    > That said, I still want to have a coherent technical explanation why the
    > compiler people cannot come up with a sensible annotation for these
    > things.

    I can only assume they didn't think about this specific use case.

    Sami

    \
     
     \ /
      Last update: 2021-10-15 20:43    [W:4.846 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site