Jakub Kicinski writes:
> On Fri, 04 Dec 2020 10:38:06 +0100 Toke Høiland-Jørgensen wrote:
>> Jakub Kicinski writes:
>> > On Thu, 03 Dec 2020 22:35:18 +0100 Toke Høiland-Jørgensen wrote:
>> >> Since we offloaded and non-offloaded programs can co-exist there doesn't
>> >> really seem to be any r
On Fri, 04 Dec 2020 10:38:06 +0100 Toke Høiland-Jørgensen wrote:
> Jakub Kicinski writes:
> > On Thu, 03 Dec 2020 22:35:18 +0100 Toke Høiland-Jørgensen wrote:
> >> Since we offloaded and non-offloaded programs can co-exist there doesn't
> >> really seem to be any reason for the check anyway, and
Jakub Kicinski writes:
> On Thu, 03 Dec 2020 22:35:18 +0100 Toke Høiland-Jørgensen wrote:
>> Since we offloaded and non-offloaded programs can co-exist there doesn't
>> really seem to be any reason for the check anyway, and it's only used in
>> three drivers so let's just get rid of the callback
On Thu, 03 Dec 2020 22:35:18 +0100 Toke Høiland-Jørgensen wrote:
> Since we offloaded and non-offloaded programs can co-exist there doesn't
> really seem to be any reason for the check anyway, and it's only used in
> three drivers so let's just get rid of the callback entirely.
I don't remember ex
From: Toke Høiland-Jørgensen
Since commit 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF
programs in net_device"), the XDP program attachment info is now maintained
in the core code. This interacts badly with the xdp_attachment_flags_ok()
check that prevents unloading an XDP program w
