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: <d8c514c6-15bf-c2fd-11f9-23519cdc9177@linux.dev>
Date:   Tue, 21 Feb 2023 11:03:52 -0800
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Stanislav Fomichev <sdf@...gle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     bpf@...r.kernel.org, netdev@...r.kernel.org, martin.lau@...nel.org,
        ast@...nel.org, daniel@...earbox.net, alexandr.lobakin@...el.com,
        larysa.zaremba@...el.com, xdp-hints@...-project.net
Subject: Re: [PATCH bpf-next V3] xdp: bpf_xdp_metadata use EOPNOTSUPP for no
 driver support

On 2/21/23 9:13 AM, Stanislav Fomichev wrote:
> On Sat, Feb 18, 2023 at 7:34 AM Jesper Dangaard Brouer
> <brouer@...hat.com> wrote:
>>
>> When driver doesn't implement a bpf_xdp_metadata kfunc the default
>> implementation returns EOPNOTSUPP, which indicate device driver doesn't
>> implement this kfunc.
>>
>> Currently many drivers also return EOPNOTSUPP when the hint isn't
>> available. Instead change drivers to return ENODATA in these cases.
>> There can be natural cases why a driver doesn't provide any hardware
>> info for a specific hint, even on a frame to frame basis (e.g. PTP).
>> Lets keep these cases as separate return codes.

> Long term probably still makes sense to export this info via xdp-features?
> Not sure how long we can 100% ensure EOPNOTSUPP vs ENODATA convention :-)

I am also not sure if it makes the xdp-hints adoption easier for other drivers 
by enforcing ENODATA or what other return values a driver should or should not 
return while EOPNOTSUPP is a more common errno to use. May be the driver experts 
can prove me wrong here.

iiuc, it is for debugging if the bpf prog has been patched with the driver's xdp 
kfunc. Others have suggested method like dumping the bpf prog insn. It could 
also trace the driver xdp kfunc and see if it is actually called. Why these 
won't work?

Beside, it is more like a load time decision which should not need a runtime 
return error value to decide. eg. With xdp-features, the bpf prog can check a 
global const which can be set based on the query result from xdp-features. It 
will then be dead code removed by verifier. This could also handle the older 
kernel that does not have xdp-metadata support (ie. missing 
bpf_xdp_metadata_rx_{timestamp,hash}).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ