Hi, Stephen Hemminger,
Thanks for your reviews.
I'll replace all strtok with strtok_r, and Cc to stable only the
necessary ones.
Best regards,
Jie Hai
On 2024/10/29 10:51, Stephen Hemminger wrote:
On Tue, 29 Oct 2024 08:56:20 +0800
fengchengwen <fengcheng...@huawei.com> wrote:
This doesn't need to go to stable. parse_params is always single threaded.
I recommend replacing all, based on:
1\ almost at no cost.
2\ reduce analysis costs, if don't we have to analyze the callers of strtok
when you encounter it.
Yes but. The replacement should not go to stable.
One of the rules of stable is that changes should be minimized, and fixes should
not be accepted for things that can not ever happen with current code.
Hope more opinion from TB members.
My assumption is that DPDK operates under similar rules as the Linux kernel.
Linux kernel rules are:
Rules on what kind of patches are accepted, and which ones are not, into the
“-stable” tree:
• It or an equivalent fix must already exist in Linux mainline (upstream).
• It must be obviously correct and tested.
• It cannot be bigger than 100 lines, with context.
• It must follow the Documentation/process/submitting-patches.rst rules.
• It must either fix a real bug that bothers people or just add a device
ID. To elaborate on the former:
◦ It fixes a problem like an oops, a hang, data corruption, a real
security issue, a hardware quirk, a build error (but not for things marked
CONFIG_BROKEN), or some “oh, that’s not good” issue.
◦ Serious issues as reported by a user of a distribution kernel may
also be considered if they fix a notable performance or interactivity issue. As
these fixes are not as obvious and have a higher risk of a subtle regression
they should only be submitted by a distribution kernel maintainer and include
an addendum linking to a bugzilla entry if it exists and additional information
on the user-visible impact.
◦ No “This could be a problem...” type of things like a “theoretical
race condition”, unless an explanation of how the bug can be exploited is also
provided.
◦ No “trivial” fixes without benefit for users (spelling changes,
whitespace cleanups, etc).
.
