Re: [PATCH v4 02/13] eal: replace strtok with reentrant version

[Jie Hai <haijie1@huawei.com>]

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 <fengchengwen@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).
> .