On 11/21/22 20:41, Jakub Kicinski wrote:
On Mon, 21 Nov 2022 20:31:38 +0000 Dmitry Safonov wrote:
quoted
quoted
Maybe it wouldn't be
the worst move to provide a sk_rcu_dereference() or rcu_dereference_sk()
or some such wrapper.
More importantly tho - was the merging part for this patches discussed?
They don't apply to net-next.
They apply over linux-next as there's a change [1] in
linux-tip/locking/core on which the patches set based.
Could the way forward be through linux-tip tree, or that might create
net conflicts?
Dunno from memory, too much happens in these files :S
Could you cherry-pick [1] onto net-next and see if
git am --no-3way patches/*
goes thru cleanly? If so no objections for the patches to go via tip,
we're close enough to the merge window.
That did go cleanly for me on today's net-next/main.
quoted
I'll send v5 with the trivial change to rcu_dereference_protected()
mentioned above.
Thanks,
Dmitry