On Tue, Dec 21, 2021 at 12:21 PM Jakub Kicinski [off-list ref] wrote:

On Tue, 21 Dec 2021 10:00:13 +0100 Magnus Karlsson wrote:

quoted

On Tue, Dec 21, 2021 at 9:32 AM Loftus, Ciara [off-list ref] wrote:

quoted

quoted

Thank you for this fix Ciara! Though I do think the Fixes tag should
be the one above: 199d983bc015 ("xsk: Fix crash on double free in
buffer pool"). Before that commit, there was no test for an empty list
in the xp_free path. The entry was unconditionally put on the list and
"initialized" in that way, so that code will work without this patch.
What do you think?

Agree - that makes sense.
Can the fixes tag be updated when pulled into the tree with:
Fixes: 199d983bc015 ("xsk: Fix crash on double free in buffer pool")

On the other hand, this was a fix for 2b43470add8c ("xsk: Introduce
AF_XDP buffer allocation API"), the original tag you have in your
patch. What should the Fixes tag point to in this case? Need some
advice please.

My $0.02 would be that if all relevant commits form a chain of fixes
it doesn't matter much which one you put in the tag. To me your
suggestion of going with 199d983bc015 makes most sense since from a
cursory look the direct issue doesn't really exist without that commit.

Plus we probably don't want 199d983bc015 to be backported until we
apply this fix, so it'd be good if "Fixes: 199d983bc015" appeared in
linux-next.

You can always put multiple Fixes tags on the commit, if you're unsure.

It sounds that the fix should get into net and linus tree asap?
In such a case mabe take it into net directly?