BPF List
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, yhs@fb.com,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, bpf@vger.kernel.org
Subject: Re: [RFC dwarves] syscall functions in BTF
Date: Fri, 10 Mar 2023 18:34:13 +0000	[thread overview]
Message-ID: <e1a5bf01-4afc-1b8c-466a-b6ed073ddfa3@oracle.com> (raw)
In-Reply-To: <ZAtGsuSO6Jx2ZLBy@kernel.org>

On 10/03/2023 15:03, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 10, 2023 at 12:43:31PM +0000, Alan Maguire escreveu:
>> On 10/03/2023 10:07, Jiri Olsa wrote:
>>> hi,
>>> with latest pahole fixes we get rid of some syscall functions (with
>>> __x64_sys_ prefix) and it seems to fall down to 2 cases:
>>>
>>> - weak syscall functions generated in kernel/sys_ni.c prevent these syscalls
>>>   to be generated in BTF. The reason is the __COND_SYSCALL macro uses
>>>   '__unused' for regs argument:
>>>
>>>         #define __COND_SYSCALL(abi, name)                                      \
>>>                __weak long __##abi##_##name(const struct pt_regs *__unused);   \
>>>                __weak long __##abi##_##name(const struct pt_regs *__unused)    \
>>>                {                                                               \
>>>                        return sys_ni_syscall();                                \
>>>                }
>>>
>>>   and having weak function with different argument name will rule out the
>>>   syscall from BTF functions
>>>
>>>   the patch below workarounds this by using the same argument name,
>>>   but I guess the real fix would be to check the whole type not just
>>>   the argument name.. or ignore weak function if there's non weak one
>>>
>>>   I guess there will be more cases like this in kernel
>>>
>>>
>  
>> Thanks for the report Jiri! I'm working on reusing the dwarves_fprintf.c
>> code to use string comparisons of function prototypes (minus parameter names!)
>> instead as a more robust comparison.  Hope to have something working soon..
> 
> Humm, that could be an option, a simple strcmp after snprintf'ing the
> function prototype, but there is also the type__compare_members_types()
> approach, used to order types in pahole, the same could be done for
> function prototypes?
> 
> I.e. to compare a function prototype for functions with the same name we
> would check its return value type, the number of arguments and then each
> of the arguments, continuing to consider the names as an heuristic that
> functions with all being so far equal having different argument names
> may indicate different functions, but if there is no name in both
> functions, look at its type instead, where we then would use
> type__compare_members_types() for structs/unions?
> 

We could do that too alright; the thing I like about stringifying the
prototype is we get a clear description when we hit a mismatch
(in verbose mode):

function mismatch for 'alloc_buffer'('alloc_buffer'): 'struct debug_buffer * ()(struct usb_bus *, ssize_t (*)(struct debug_buffer *))' != 'struct debug_buffer * ()(struct ohci_hcd *, ssize_t (*)(struct debug_buffer *))'

...and we can re-use the existing support for function display, which works great!
Luckily we don't have to do this very often; I counted 2113 prototype comparisons,
of which only 49 mismatches were detected. Thanks!

Alan

> - Arnaldo
>   
>>> - we also do not get any syscall with no arguments, because they are
>>>   generated as aliases to __do_<syscall> function:
>>>
>>>         $ nm ./vmlinux | grep _sys_fork
>>>         ffffffff81174890 t __do_sys_fork
>>>         ffffffff81174890 T __ia32_sys_fork
>>>         ffffffff81174880 T __pfx___x64_sys_fork
>>>         ffffffff81174890 T __x64_sys_fork
>>>
>>>   with:
>>>         #define __SYS_STUB0(abi, name)                                          \
>>>                 long __##abi##_##name(const struct pt_regs *regs);              \
>>>                 ALLOW_ERROR_INJECTION(__##abi##_##name, ERRNO);                 \
>>>                 long __##abi##_##name(const struct pt_regs *regs)               \
>>>                         __alias(__do_##name);
>>>
>>>   the problem seems to be that there's no DWARF data for aliased symbol,
>>>   so pahole won't see any __x64_sys_fork record
>>>   I'm not sure how to fix this one
>>>
>>
>> Is this one a new issue, or did you just spot it when looking at the other case?
>>
>> Thanks!
>>
>> Alan
>>
>>>   technically we can always connect to __do_sys_fork, but we'd need to
>>>   have special cases for such syscalls.. would be great to have all with
>>>   '__x64_sys_' prefix
>>>
>>>
>>> thoughts?
>>>
>>> thanks,
>>> jirka
>>>
>>>
>>> ---
>>> diff --git a/arch/x86/include/asm/syscall_wrapper.h b/arch/x86/include/asm/syscall_wrapper.h
>>> index fd2669b1cb2d..e02dab630577 100644
>>> --- a/arch/x86/include/asm/syscall_wrapper.h
>>> +++ b/arch/x86/include/asm/syscall_wrapper.h
>>> @@ -80,8 +80,8 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
>>>  	}
>>>  
>>>  #define __COND_SYSCALL(abi, name)					\
>>> -	__weak long __##abi##_##name(const struct pt_regs *__unused);	\
>>> -	__weak long __##abi##_##name(const struct pt_regs *__unused)	\
>>> +	__weak long __##abi##_##name(const struct pt_regs *regs);	\
>>> +	__weak long __##abi##_##name(const struct pt_regs *regs)	\
>>>  	{								\
>>>  		return sys_ni_syscall();				\
>>>  	}
>>>
> 

  parent reply	other threads:[~2023-03-10 18:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 10:07 [RFC dwarves] syscall functions in BTF Jiri Olsa
2023-03-10 12:43 ` Alan Maguire
2023-03-10 15:03   ` Arnaldo Carvalho de Melo
2023-03-10 15:10     ` Arnaldo Carvalho de Melo
2023-03-10 18:34     ` Alan Maguire [this message]
2023-03-10 15:09   ` Jiri Olsa
2023-03-10 18:11     ` Alan Maguire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1a5bf01-4afc-1b8c-466a-b6ed073ddfa3@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=acme@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=olsajiri@gmail.com \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox