Message-ID: <c8b3ce57-41d2-4a75-8537-2f2128d67a85@fb.com>
Date:   Fri, 27 Aug 2021 22:05:30 -0400
From:   Dave Marchevsky <davemarchevsky@...com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Yonghong Song <yhs@...com>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 bpf-next 3/6] libbpf: Modify bpf_printk to choose
 helper based on arg count

On 8/25/21 9:01 PM, Alexei Starovoitov wrote:   
> On Wed, Aug 25, 2021 at 12:58 PM Dave Marchevsky <davemarchevsky@...com> wrote:
>>
>> Instead of being a thin wrapper which calls into bpf_trace_printk,
>> libbpf's bpf_printk convenience macro now chooses between
>> bpf_trace_printk and bpf_trace_vprintk. If the arg count (excluding
>> format string) is >3, use bpf_trace_vprintk, otherwise use the older
>> helper.
>>
>> The motivation behind this added complexity - instead of migrating
>> entirely to bpf_trace_vprintk - is to maintain good developer experience
>> for users compiling against new libbpf but running on older kernels.
>> Users who are passing <=3 args to bpf_printk will see no change in their
>> bytecode.
>>
>> __bpf_vprintk functions similarly to BPF_SEQ_PRINTF and BPF_SNPRINTF
>> macros elsewhere in the file - it allows use of bpf_trace_vprintk
>> without manual conversion of varargs to u64 array. Previous
>> implementation of bpf_printk macro is moved to __bpf_printk for use by
>> the new implementation.
>>
>> This does change behavior of bpf_printk calls with >3 args in the "new
>> libbpf, old kernels" scenario. On my system, using a clang built from
>> recent upstream sources (14.0.0 https://github.com/llvm/llvm-project.git
>> 50b62731452cb83979bbf3c06e828d26a4698dca), attempting to use 4 args to
>> __bpf_printk (old impl) results in a compile-time error:
>>
>>   progs/trace_printk.c:21:21: error: too many args to 0x6cdf4b8: i64 = Constant<6>
>>         trace_printk_ret = __bpf_printk("testing,testing %d %d %d %d\n",
> 
> and with a new bpf_printk it will compile to use bpf_trace_vprintk
> and gets rejected during load on old kernels, right?
> That will be the case for any clang.
> It's fine.
> Would be good to clarify the commit log.

Yep, I think we're on the same page here. Wanted to call out the 
changed behavior in case it felt more like 'breaking user expectations'.
Will simplify the commit message for this patch in v3.

>> I was able to replicate this behavior with an older clang as well. When
>> the format string has >3 format specifiers, there is no output to the
>> trace_pipe in either case.
> 
> I don't understand this paragraph. What are the cases?

This was me trying to enumerate behavior before/after this patch in
order to answer the 'does this break user expectations' question. I was
curious whether clang version affected error messages users would see
when doing things old bpf_printk didn't support (>3 args, >3 format
specifiers). Format specifier >3 case is intentional runtime behavior,
so in retrospect there was no reason to focus on clang version there.

Will remove from commit msg.

>> After this patch, using bpf_printk with 4 args would result in a
>> trace_vprintk helper call being emitted and a load-time failure on older
>> kernels.
> 
> right.
> 
>> +#define __bpf_printk(fmt, ...)                         \
>> +({                                                     \
>> +       char ____fmt[] = fmt;                           \
> 
> Andrii was suggesting to make it const while we're at it,
> but that could be done in a follow up.

This was intentionally left out of v2 as I wanted to get early feedback
on the macro stuff, will add a patch doing this to v3. 

Powered by blists - more mailing lists