netdev - Re: [RFC PATCH 2/2] bpf: let bpf_warn_invalid_xdp

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8deb249146474aff37cc574e464615cf98adb32e.camel@redhat.com>
Date:   Thu, 18 Nov 2021 12:11:33 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     netdev@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, bpf@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] bpf: let bpf_warn_invalid_xdp_action() report
 more info

Hello,

On Wed, 2021-11-17 at 16:48 -0800, Alexei Starovoitov wrote:
> On Mon, Nov 15, 2021 at 06:09:28PM +0100, Toke Høiland-Jørgensen wrote:
> > Paolo Abeni <pabeni@...hat.com> writes:
> > 
> > > > > -	pr_warn_once("%s XDP return value %u, expect packet loss!\n",
> > > > > +	pr_warn_once("%s XDP return value %u on prog %d dev %s attach type %d, expect packet loss!\n",
> > > > >  		     act > act_max ? "Illegal" : "Driver unsupported",
> > > > > -		     act);
> > > > > +		     act, prog->aux->id, dev->name, prog->expected_attach_type);
> > > > 
> > > > This will only ever trigger once per reboot even if the message differs,
> > > > right? Which makes it less useful as a debugging aid; so I'm not sure if
> > > > it's really worth it with this intrusive change unless we also do
> > > > something to add a proper debugging aid (like a tracepoint)...
> > > 
> > > Yes, the idea would be to add a tracepoint there, if there is general
> > > agreement about this change.
> > > 
> > > I think this patch is needed because the WARN_ONCE splat gives
> > > implicitly information about the related driver and attach type.
> > > Replacing with a simple printk we lose them.
> > 
> > Ah, right, good point. Pointing that out in the commit message might be
> > a good idea; otherwise people may miss that ;)
> 
> Though it's quite a churn across the drivers I think extra verbosity here is justified.
> I'd only suggest to print stable things. Like prog->aux->id probably has
> little value for the person looking at the logs. That prog id is likely gone.
> If it was prog->aux->name it would be more helpful.
> Same with expected_attach_type. Why print it at all?
> tracepoint is probably good idea too.

Thanks for the feedback.

I tried to select the additional arguments to allow the user/admin
tracking down which program is causing the issue and why. I'm a
complete newbe wrt XDP, so likely my choice were naive.

I thought the id identifies the program in an unambiguous manner. I
understand the program could be unloaded meanwhile, but if that is not
the case the id should be quite useful. Perhaps we could dump both the
id and the name?

I included the attach type as different types support/allow different
actions: the same program could cause the warning or not depending on
it. If that is not useful I can drop the attach type from the next
iteration.

Thanks!

Paolo