All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julian Anastasov <ja@ssi.bg>
To: Zhiling Zou <zhilinz@nebusec.ai>
Cc: lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	horms@verge.net.au, pablo@netfilter.org, fw@strlen.de,
	phil@nwl.cc, vega@nebusec.ai
Subject: Re: [PATCH nf v2 0/1] ipvs: bound LBLCR and LBLC cache growth
Date: Mon, 17 Aug 2026 15:41:33 +0300 (EEST)	[thread overview]
Message-ID: <90ff9fd0-b46b-7eac-ade3-d0ebbb0ec06b@ssi.bg> (raw)
In-Reply-To: <cover.1786949472.git.zhilinz@nebusec.ai>


	Hello,

On Mon, 17 Aug 2026, Zhiling Zou wrote:

> Hi Linux kernel maintainers,
> 
> We found and validated an issue in net/netfilter/ipvs/ip_vs_lblcr.c.
> The bug is reachable by a non-root user through a new user and network
> namespace. The same cache growth bound is also missing from the sibling
> LBLC scheduler in net/netfilter/ipvs/ip_vs_lblc.c.

	Sashiko reports for a missing atomic_dec(&tbl->entries)
in ip_vs_lblc_new(), after the ip_vs_lblc_del(en) call:

https://sashiko.dev/#/patchset/17cbb1d0649f4e19aa2e407ab4b528d42b8edac4.1786949472.git.zhilinz%40nebusec.ai

	But it is not related to this patch. The GC
probably needs to be improved because with this patch
we should be freeing 16 entries in average from single
bucket but before that we are not caching new dests for
60 secs.

	While max_size works like a low threshold for
entries in cache, we do not define maximum to apply.
After checking the code again, we may need to provide more
bonus for the normal traffic to cache entries in the next
minute (eg. +50%) while we are freeing cached entries in
the background to free space for the new dests. Because
without caching we are not using the servers persistently.

	May be separate patch can rename max_size to
min_size and to add max_size = min_size * 3 / 2 as a
limit for allocations. For this patch we can use just
"max_size * 3 / 2".

Regards

--
Julian Anastasov <ja@ssi.bg>


      parent reply	other threads:[~2026-08-17 12:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17  7:14 [PATCH nf v2 0/1] ipvs: bound LBLCR and LBLC cache growth Zhiling Zou
2026-08-17  7:14 ` [PATCH nf v2 1/1] " Zhiling Zou
2026-08-17 12:41 ` Julian Anastasov [this message]

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=90ff9fd0-b46b-7eac-ade3-d0ebbb0ec06b@ssi.bg \
    --to=ja@ssi.bg \
    --cc=fw@strlen.de \
    --cc=horms@verge.net.au \
    --cc=lvs-devel@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=phil@nwl.cc \
    --cc=vega@nebusec.ai \
    --cc=zhilinz@nebusec.ai \
    /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.