From: Steffen Klassert <steffen.klassert@secunet.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
<netdev@vger.kernel.org>
Subject: Re: Some clarifications on the upstreaming process
Date: Wed, 9 Sep 2026 12:44:08 +0200 [thread overview]
Message-ID: <aqE4eK2cqpvxqCQJ@secunet.com> (raw)
In-Reply-To: <83dd4915-e7a3-4c7e-91dd-adbea16450b3@redhat.com>
On Wed, Sep 09, 2026 at 12:34:42PM +0200, Paolo Abeni wrote:
> On 9/9/26 12:23 PM, Steffen Klassert wrote:
> > On Wed, Sep 09, 2026 at 11:23:56AM +0200, Paolo Abeni wrote:
> >> On 9/9/26 8:38 AM, Steffen Klassert wrote:
> >>> I need some clarifications on how to handle future ipsec patches.
> >>> Since we have the AI-generated patches and patch reviews things
> >>> changed quite a bit and I have problems to upstream ipsec fixes.
> >>>
> >>> I have the following problematic situations:
> >>>
> >>> 1) Sashiko found nothing in the original patch submisstion,
> >>> but found an issue when I resent the patch with the pull
> >>> request. I think this can be solved by asking the author
> >>> to send an incremental fix on top of the ipsec tree if
> >>> it does not happen too often.
> >>
> >> This is usually the correct approach, with some exceptions i.e. the
> >> newly found issue is impactful (the new code is exploitable).
> >
> > Are you willing to pull this as is, or should I resend the pull
> > request with the incremental fix? The latter leads to problem
> > 4.1 (patch does not apply to net).
> Due to time schedule I can't look into the series detail before tomorrow
> my time. Since Jakub forwarded the AI report and left the series in PW I
> assume he is looking for your replies to the AI comments - which is
> pretty much would I'll do.
It was a general question, not directly related to this pull request.
There were several issues reported, it will take a bit of time
to review the AI comments.
next prev parent reply other threads:[~2026-09-09 10:44 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 9:29 [PATCH 0/12] pull request (net): ipsec 2026-09-07 Steffen Klassert
2026-09-07 9:29 ` [PATCH 01/12] xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk() Steffen Klassert
2026-09-08 22:48 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 02/12] xfrm: serialize state GC with device state flush Steffen Klassert
2026-09-08 22:48 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 03/12] xfrm: add missing RCU read lock in xfrm_send_migrate_state() Steffen Klassert
2026-09-07 9:29 ` [PATCH 04/12] xfrm: iptfs: fix runt reassembly panic from short inner tot_len Steffen Klassert
2026-09-08 22:48 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 05/12] ipv6: xfrm: use full sockets in local error paths Steffen Klassert
2026-09-08 22:48 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 06/12] xfrm: fix compat ALLOCSPI request use-after-free Steffen Klassert
2026-09-07 9:29 ` [PATCH 07/12] xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() Steffen Klassert
2026-09-08 22:48 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 08/12] xfrm: use hlist_del_init_rcu for state_cache and state_cache_input Steffen Klassert
2026-09-08 22:48 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 09/12] esp: downgrade zerocopy managed frags before mutating skb frags Steffen Klassert
2026-09-08 22:49 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 10/12] xfrm: hold net_device reference under RCU in bundle creation Steffen Klassert
2026-09-08 22:49 ` Jakub Kicinski
2026-09-07 9:29 ` [PATCH 11/12] xfrm: save input state data before secpath resets Steffen Klassert
2026-09-07 9:29 ` [PATCH 12/12] net: xfrm: reject unrepresentable espintcp transport headers Steffen Klassert
2026-09-08 22:49 ` Jakub Kicinski
2026-09-09 6:38 ` Some clarifications on the upstreaming process (was: [PATCH 0/12] pull request (net): ipsec 2026-09-07) Steffen Klassert
2026-09-09 9:23 ` Some clarifications on the upstreaming process Paolo Abeni
2026-09-09 10:22 ` Matthieu Baerts
2026-09-10 8:17 ` Steffen Klassert
2026-09-10 8:35 ` Matthieu Baerts
2026-09-10 9:28 ` Steffen Klassert
2026-09-09 10:23 ` Steffen Klassert
2026-09-09 10:34 ` Paolo Abeni
2026-09-09 10:44 ` Steffen Klassert [this message]
2026-09-09 18:57 ` Jakub Kicinski
2026-09-10 8:29 ` Matthieu Baerts
2026-09-10 9:02 ` Steffen Klassert
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=aqE4eK2cqpvxqCQJ@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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