Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

Eric Dumazet
2026-04-01T09:02:55Z

On Wed, Apr 1, 2026 at 12:05 AM Yuan Tan <yuantan098@gmail.com> wrote:
>
>
> On 3/31/2026 6:05 PM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 5:41 PM Yuan Tan <yuantan098@gmail.com> wrote:
> >>
> >> On 3/31/2026 1:52 AM, Eric Dumazet wrote:
> >>> On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
> >>>> From: Zhengchuan Liang <zcliangcn@gmail.com>
> >>>>
> >>>> `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file
> >>>> RCU read-side lock and prints `fl->opt->opt_nflen` when an option block
> >>>> is present.
> >>> Some points :
> >>>
> >>> Please do not CC security@ if you submit a public patch, there is
> >>> absolutely no reason for it.
> >>>
> >>> Please do not resend the same version within 24 hours; this creates noise.
> >>> Your patch wasn't lost; we have many patch reviews and similar bugs to address.
> >>>
> >>> Thank you.
> >> We sincerely apologize for the confusion caused by our previous email. Previously, when we sent reports and patches to the security list, we were advised that patches should be submitted to netdev@ for public review. To follow this, we are now sending the full vulnerability details to security@ while additionally submitting the patches to netdev@. Please let us know if this is the correct way to handle such cases.
> > When/If an issue and a patch is sent publicly, security@ involvement
> > ends. netdev maintainers take over.
> >
> > Thus there is no point CCing this list of security officers, which is
> > currently flooded by many LLM-based findings.
> > Please help them by keeping their inbox a bit saner.
> We would like to standardize our workflow to ensure it aligns with
> community expectations. We've checked the maillist and netdev docs for
> these details but found no clear answers. Could you please clarify which of
> the following is preferred?
>
> Option 1: Send the security report to security@ and submit the patches
> directly to the subsystem mailing list without CC security@.
>
> Option 2: Send both the report and the patches to security@ for an initial
> review. After approval, re-send the patches to the subsystem mailing list.
>
> For Option 1, I have hread that there are bots on the public lists to help
> with the review. The Option 2 feels slightly redundant and might cause
> confusion. We are open to any other workflow that the community prefers.
>
> We are wondering if it's better to send the PoC and detailed analysis
> directly to netdev@ for bugs we deem to have low exploitability, which
> would help minimize the burden on the security@ team. However, these bugs
> are still triggerable by unprivileged users, we are concerned that posting
> full PoC to a public mailing list might be inappropriate or risky.
> >> Regarding the CC list, could you provide further guidance on who we should include? Currently, we are CCing everyone suggested by get_maintainer.pl because we previously received feedback about missing relevant maintainers. For public mailing lists, we should only including netdev@. Should we be more selective?
> > Yes, folks that are interesting into following netdev changes are
> > subscribed to netdev@ mailing list.
> >
> > Unless a patch touches non-networking parts and requires approval from
> > other branch maintainers, there is no
> > point CCing other lists.
> Thank you for your advice. We will no longer CC individual maintainers on
> patches sent to netdev.
>
> Regarding security reports, however, we had previously been advised to CC
> more people to avoid manual forwarding.
>
> To be honest, we are a bit confused by the conflicting guidance we've
> received. We sincerely want to establish a standardized process for our
> future contributions to make everyone happy.
>
> >> Finally, regarding our tags, our team has a clear division of labor—some focus on finding vulnerabilities, others on fixing them, followed by an internal review and testing before a dedicated member handles community outreach.
> >>
> > You included 8 tags, this seems a bit too much for such a small patch.
> CC Greg here, as he knows a bit about our team's background.
>
> Our team has developed a tool that found hundreds of non-root bugs with
> PoCs. We want to ensure these are fixed properly and quickly rather than
> dumping reports onto the mailing list and hoping for others to find the
> time to fix. So we have organized a group of promising students. As some of
> them are new to kernel development, we have been providing hands-on
> mentorship to guide them through the process.
>
> Regarding credit attribution: Yuan, Yifan, Jufei, and Xin were all
> instrumental in the tool's design and implementation, so we listed them
> with Reported-by tags. Xin provided the funding and led the fixing team, so
> we included a Suggested-by tag for him (though this could be changed to
> Reported-by as well). Then after including the patch author, this naturally
> results in five tags.
>
>
> As for using a designated sender to submit these patches, it's because
> using Gmail with git send-email is difficult in China and the university
> email servers prohibit the use of the SMTP protocol. Therefore, we had to
> apply for a separate account specifically with SMTP permissions to submit
> patches.
>
> We fully respect the maintainers' discretion in this matter. If the current
> tags are still considered unacceptable, we will make the necessary internal
> adjustments.

Again, no need for all this, I already gave a 'Reviewed-by', I was not
saying it was unaccptable.

Oh well.