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

[Yuan Tan <yuantan098@gmail.com>]

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.

>> We welcome any guidance and will improve our upcoming patches accordingly. To be honest, we are currently a bit uncertain about the exact workflow the community prefers, and we are eager to align our process with your expectations.
>>