Re: [PATCH RFC net 0/3] netfilter: nfnetlink_queue: handle packet ID reuse and large gaps

[Florian Westphal <fw@strlen.de>]

Alireza Asgari <alireza@asgari.net> wrote:
> Thanks for the review.
> 
> I understand that batch verdicts are intended to be used in strict sequence. The scenarios motivating this RFC did not establish a failure under that usage model, and the evidence presented does not justify the additional epoch and missing-boundary handling.
> 
> I’ll drop the current series. I also understand that the proposed collision disposition being reasonable does not by itself establish a need for the duplicate-ID guard. I would revisit that separately only if I can provide a concrete use case.
> 
> Thanks for taking the time to review it.

If you want to work on something else that is actually a problem, then
you could investigate the mem exhaustion issue.

The current limitation is queue length based, this is very old from
a time when GSO/TSO aggregate skbs did not exist.

Untested idea:

1. compute a memory size limit based off the old NFQA_CFG_QUEUE_MAXLEN:
   sizeof(sk_buff shell structure) + 2048 (half a 4k page).
2. store skb->truesize in the entry struct when queueing.
3. charge the truesize to the queue entry (and uncharge on reinject).
4. in addition to the queue length check, also check if the new
   skb->truesize would bring us over the limit, refuse queueing if thats
   the case.
5. Make sure NFQA_CFG_QUEUE_MAXLEN updates continue to work.

This leaves on major issue: userspace can request 64k queues, so these
limits don't help.

One possible solution:
1. For init netns, no changes.
2. For non-init netns:
   at queue creation time resp. when limit is altered, pre-charge
   the worst case occupancy to kmemcg.

Refuse queue creation if that fails.
Ideally this could be split into several patches to ease review.

Thanks.