On Mon, Sep 21, 2026 at 2:50 PM Julian Anastasov <[email protected]> wrote: > > > Hello, > > On Mon, 21 Sep 2026, [email protected] wrote: > > > Thank you for your contribution! Sashiko AI review found 2 potential > > issue(s) to consider. > > > > Critical: 0 · High: 1 (1) · Medium: 0 · Low: 1 > > > > If you believe none of the issues are legitimate, please reply to each > > issue of Medium severity or higher and explain why the AI is wrong. > > If any of them are legitimate and you plan to respin, please let patchwork > > know by including "pw-bot: cr" as a separate line at the end of your reply > > (one such reply per series is enough). > > > > - [High] ipvs: use-after-free in ip_vs_conn_expire() due to timer re- > > arming race > > - [Low] ip_vs_conn_del_put() (net/netfilter/ipvs/ip_vs_conn.c:1333-1346) > > keeps its old comment "Try to delete connection while holding… > > > > Pre-existing issues: > > - [High] ip_vs_conn_del_put() (net/netfilter/ipvs/ip_vs_conn.c:1336-1341) > > cancels the controller's timer, drops the caller's only reference on… > > > > -- > > > > ipvs: avoid stack overflow from recursive connection expiration > > > > This changes ip_vs_conn_del_put() to return whether it managed to delete > > the controller's timer, and makes ip_vs_conn_expire() loop back with the > > controller instead of recursing into itself. The stated goal is to keep > > chain cleanup synchronous while using a single stack frame. > > > > v1 Link: https://lore.kernel.org/all/[email protected]/ > > Zihan, IPVS has conn refcounting which does not look > natural: the hash table has reference and the timer callback > has no reference. Let me try today to change the refcounting, > so that unhashing occurs after last reference is dropped, > the conn lookups already use inc_not_zero, so we will try > to consider the timer_delete as successful stealing of > the refcnt from the timer callback (yes, the callback should > hold refcnt, not the hashing). But first let me try if the > idea would be successful. As result, your change should > be small as before, we should be able to delete conns safely. > > Regards > > -- > Julian Anastasov <[email protected]>
Hello Julian, Thanks for looking into this. The Sashiko report was generated for v2. I have already sent v3: https://lore.kernel.org/all/[email protected]/ I'll wait for your refcounting changes and then rework the iterative expiration fix on top of them. Regards, Zihan
