From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
anthony.l.nguyen@intel.com, fred@cloudflare.com,
magnus.karlsson@intel.com
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: allow hot-swapping XDP programs
Date: Wed, 14 Jun 2023 15:42:29 +0200 [thread overview]
Message-ID: <87v8fqjh2y.fsf@toke.dk> (raw)
In-Reply-To: <ZIm3lHaa3Rjl2xRe@boxer>
Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
> On Wed, Jun 14, 2023 at 02:40:07PM +0200, Alexander Lobakin wrote:
>> From: Toke Høiland-Jørgensen <toke@kernel.org>
>> Date: Tue, 13 Jun 2023 19:59:37 +0200
>>
>> > Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
>> >
>> >> On Tue, Jun 13, 2023 at 05:15:15PM +0200, Alexander Lobakin wrote:
>> >>> From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>> >>> Date: Tue, 13 Jun 2023 17:10:05 +0200
>>
>> [...]
>>
>> >> Since we removed rcu sections from driver sides and given an assumption
>> >> that local_bh_{dis,en}able() pair serves this purpose now i believe this
>> >> is safe. Are you aware of:
>> >>
>> >> https://lore.kernel.org/bpf/20210624160609.292325-1-toke@redhat.com/
>>
>> Why [0] then? Added in [1] precisely for the sake of safe XDP prog
>> access and wasn't removed :s I was relying on that one in my suggestions
>> and code :D
>>
>> >
>> > As the author of that series, I agree that it's not necessary to add
>> > additional RCU protection. ice_vsi_assign_bpf_prog() already uses xchg()
>> > and WRITE_ONCE() which should protect against tearing, and the xdp_prog
>> > pointer being passed to ice_run_xdp() is a copy residing on the stack,
>> > so it will only be read once per NAPI cycle anyway (which is in line
>> > with how most other drivers do it).
>>
>> What if a NAPI polling cycle is being run on one core while at the very
>> same moment I'm replacing the XDP prog on another core? Not in terms of
>> pointer tearing, I see now that this is handled correctly, but in terms
>> of refcounts? Can't bpf_prog_put() free it while the polling is still
>> active?
>
> Hmm you mean we should do bpf_prog_put() *after* we update bpf_prog on
> ice_rx_ring? I think this is a fair point as we don't bump the refcount
> per each Rx ring that holds the ptr to bpf_prog, we just rely on the main
> one from VSI.
Yes, that's true, the duplication of the pointer in all the ring
structures can lead to problems there (why is that done in the first
place?). I agree that swapping the order of the pointer assignments
should be enough to fix this.
>> > It *would* be nice to add an __rcu annotation to ice_vsi->xdp_prog and
>> > ice_rx_ring->xdp_prog (and move to using rcu_dereference(),
>> > rcu_assign_pointer() etc), but this is more a documentation/static
>> > checker thing than it's a "correctness of the generated code" thing :)
>
> Agree but I would rather address the rest of Intel drivers in the
> series.
That's fair :)
-Toke
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: netdev@vger.kernel.org, anthony.l.nguyen@intel.com,
intel-wired-lan@lists.osuosl.org, magnus.karlsson@intel.com,
fred@cloudflare.com
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: allow hot-swapping XDP programs
Date: Wed, 14 Jun 2023 15:42:29 +0200 [thread overview]
Message-ID: <87v8fqjh2y.fsf@toke.dk> (raw)
In-Reply-To: <ZIm3lHaa3Rjl2xRe@boxer>
Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
> On Wed, Jun 14, 2023 at 02:40:07PM +0200, Alexander Lobakin wrote:
>> From: Toke Høiland-Jørgensen <toke@kernel.org>
>> Date: Tue, 13 Jun 2023 19:59:37 +0200
>>
>> > Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
>> >
>> >> On Tue, Jun 13, 2023 at 05:15:15PM +0200, Alexander Lobakin wrote:
>> >>> From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>> >>> Date: Tue, 13 Jun 2023 17:10:05 +0200
>>
>> [...]
>>
>> >> Since we removed rcu sections from driver sides and given an assumption
>> >> that local_bh_{dis,en}able() pair serves this purpose now i believe this
>> >> is safe. Are you aware of:
>> >>
>> >> https://lore.kernel.org/bpf/20210624160609.292325-1-toke@redhat.com/
>>
>> Why [0] then? Added in [1] precisely for the sake of safe XDP prog
>> access and wasn't removed :s I was relying on that one in my suggestions
>> and code :D
>>
>> >
>> > As the author of that series, I agree that it's not necessary to add
>> > additional RCU protection. ice_vsi_assign_bpf_prog() already uses xchg()
>> > and WRITE_ONCE() which should protect against tearing, and the xdp_prog
>> > pointer being passed to ice_run_xdp() is a copy residing on the stack,
>> > so it will only be read once per NAPI cycle anyway (which is in line
>> > with how most other drivers do it).
>>
>> What if a NAPI polling cycle is being run on one core while at the very
>> same moment I'm replacing the XDP prog on another core? Not in terms of
>> pointer tearing, I see now that this is handled correctly, but in terms
>> of refcounts? Can't bpf_prog_put() free it while the polling is still
>> active?
>
> Hmm you mean we should do bpf_prog_put() *after* we update bpf_prog on
> ice_rx_ring? I think this is a fair point as we don't bump the refcount
> per each Rx ring that holds the ptr to bpf_prog, we just rely on the main
> one from VSI.
Yes, that's true, the duplication of the pointer in all the ring
structures can lead to problems there (why is that done in the first
place?). I agree that swapping the order of the pointer assignments
should be enough to fix this.
>> > It *would* be nice to add an __rcu annotation to ice_vsi->xdp_prog and
>> > ice_rx_ring->xdp_prog (and move to using rcu_dereference(),
>> > rcu_assign_pointer() etc), but this is more a documentation/static
>> > checker thing than it's a "correctness of the generated code" thing :)
>
> Agree but I would rather address the rest of Intel drivers in the
> series.
That's fair :)
-Toke
next prev parent reply other threads:[~2023-06-14 15:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 15:10 [Intel-wired-lan] [PATCH iwl-next] ice: allow hot-swapping XDP programs Maciej Fijalkowski
2023-06-13 15:10 ` Maciej Fijalkowski
2023-06-13 15:15 ` [Intel-wired-lan] " Alexander Lobakin
2023-06-13 15:15 ` Alexander Lobakin
2023-06-13 15:20 ` Maciej Fijalkowski
2023-06-13 15:20 ` Maciej Fijalkowski
2023-06-13 17:59 ` Toke Høiland-Jørgensen
2023-06-13 17:59 ` Toke Høiland-Jørgensen
2023-06-14 12:40 ` Alexander Lobakin
2023-06-14 12:40 ` Alexander Lobakin
2023-06-14 12:50 ` Maciej Fijalkowski
2023-06-14 12:50 ` Maciej Fijalkowski
2023-06-14 13:25 ` Alexander Lobakin
2023-06-14 13:25 ` Alexander Lobakin
2023-06-14 13:47 ` Toke Høiland-Jørgensen
2023-06-14 13:47 ` Toke Høiland-Jørgensen
2023-06-14 14:03 ` Alexander Lobakin
2023-06-14 14:03 ` Alexander Lobakin
2023-06-14 13:42 ` Toke Høiland-Jørgensen [this message]
2023-06-14 13:42 ` Toke Høiland-Jørgensen
2023-06-13 16:43 ` kernel test robot
2023-06-13 16:43 ` kernel test robot
2023-06-13 17:58 ` [Intel-wired-lan] " kernel test robot
2023-06-13 17:58 ` kernel test robot
2023-06-13 22:19 ` [Intel-wired-lan] " kernel test robot
2023-06-13 22:19 ` kernel test robot
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=87v8fqjh2y.fsf@toke.dk \
--to=toke@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=fred@cloudflare.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.