From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4445045CA9; Thu, 7 Nov 2024 13:29:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D7CDA402AC; Thu, 7 Nov 2024 13:29:18 +0100 (CET) Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by mails.dpdk.org (Postfix) with ESMTP id 0DFAF40280 for ; Thu, 7 Nov 2024 13:29:17 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4XkhGF2z96z2gL1Z; Thu, 7 Nov 2024 20:29:25 +0800 (CST) Received: from kwepemf500004.china.huawei.com (unknown [7.202.181.242]) by mail.maildlp.com (Postfix) with ESMTPS id 171A11401E9; Thu, 7 Nov 2024 20:29:15 +0800 (CST) Received: from [10.67.121.175] (10.67.121.175) by kwepemf500004.china.huawei.com (7.202.181.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 7 Nov 2024 20:29:14 +0800 Message-ID: Date: Thu, 7 Nov 2024 20:29:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v4 02/13] eal: replace strtok with reentrant version To: Stephen Hemminger , fengchengwen CC: Ferruh Yigit , Thomas Monjalon , , Anatoly Burakov , Tyler Retzlaff , Amit Prakash Shukla , , References: <20231113104550.2138654-1-haijie1@huawei.com> <20241026101451.29135-1-haijie1@huawei.com> <20241026101451.29135-3-haijie1@huawei.com> <20241026200028.44b83e1b@hermes.local> <20241028083112.25b96ae1@hermes.local> <74ae461a-de52-4ba4-916d-508d2d0a0746@huawei.com> <20241028195112.463f4a6b@hermes.local> From: Jie Hai In-Reply-To: <20241028195112.463f4a6b@hermes.local> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.175] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemf500004.china.huawei.com (7.202.181.242) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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). > .