From: Roshan Kumar <roshaen09@gmail.com>
To: netdev-bot+sashiko@kernel.org
Cc: netdev@vger.kernel.org, steffen.klassert@secunet.com,
herbert@gondor.apana.org.au, davem@davemloft.net,
chopps@labn.net, shubham@octane.security, robert@octane.security,
gio@octane.security, kuba@kernel.org
Subject: Re: [PATCH v2] xfrm: iptfs: hold a device reference while packets are queued
Date: Tue, 29 Sep 2026 04:03:28 +0000 [thread overview]
Message-ID: <179065460862.1915782.13934055353367749026@gmail.com> (raw)
In-Reply-To: <179023970333.2160803.2776986020964028023@kernel.org>
Thanks for the detailed review. The findings are valid. I have reworked the
next revision to keep the reassembly device reference through the nested
xfrm_input() processing. Reassembly and reorder window deadlines are now
tracked independently, so completing one does not strand the other or apply a
stale deadline to new state. The timer is also armed for reassembly created
from a runt.
The reference is released on every completion, timeout, abort, and teardown
path. The code uses netdev_hold() and netdev_put(), documents ownership, and
fixes the style issues. I replaced the mismatched pasted trace with a concise
description verified against the KASAN reproducer, which remains private. I
also removed the incorrect bounded lifetime claim and the self reporting
credit.
I have split the timer correction into a prerequisite patch. The resulting
series now passes the ten case KASAN and reference tracker lifecycle matrix on
both the regular kernel and the lockdep and RCU debug kernel. It also passes
the stale deadline overlap and runt created reassembly regressions. I will
coordinate the timer prerequisite before posting v3 as a new thread.
pw-bot: cr
prev parent reply other threads:[~2026-09-29 4:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 8:47 [PATCH v2] xfrm: iptfs: hold a device reference while packets are queued Roshan Kumar
2026-09-24 8:48 ` netdev-bot+sashiko
2026-09-29 4:03 ` Roshan Kumar [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=179065460862.1915782.13934055353367749026@gmail.com \
--to=roshaen09@gmail.com \
--cc=chopps@labn.net \
--cc=davem@davemloft.net \
--cc=gio@octane.security \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=robert@octane.security \
--cc=shubham@octane.security \
--cc=steffen.klassert@secunet.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox