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 5CCEB45BA3; Tue, 22 Oct 2024 17:26:02 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4D33F40654; Tue, 22 Oct 2024 17:26:02 +0200 (CEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by mails.dpdk.org (Postfix) with ESMTP id 1A97940651 for ; Tue, 22 Oct 2024 17:26:01 +0200 (CEST) Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-656d8b346d2so3804491a12.2 for ; Tue, 22 Oct 2024 08:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1729610760; x=1730215560; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=/jX+iKOubadomv9mErFjygwqxLutNR05X3AUUVcwEbo=; b=mYGSECZMkH8PLFMtvcG7ZVAu5a+DoZNInfAwZUDONW8/kDhPMtD/TiSJs0Ygke1MKP o+smiAcxTvziIrm7Gs7lam1Pdv2YLMCGUZRMzbIB8B7NuZKv4JhdcqlKjufbU1hUG8k9 YIkG7+eDLm/ikMGMrS2/Vmtwly+vNS1xGepi577Njs9P/81oRlUvQplGbpw4MYSfmRhI 2Hxo9IkblorykUym134oN0/ckWNb66r8cA2DWdEWBP4M+tPgYxmTJ9El1RNXlJw9wBbg qPR0xfyMgYldyB19N8WgmlpUU57VQ5CMTGYtDJWDmAcA1uMd2CL8cHNR7L69HVKMIibn twSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729610760; x=1730215560; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/jX+iKOubadomv9mErFjygwqxLutNR05X3AUUVcwEbo=; b=s9rzZQbiq31ZrNv29NkRQG8nUU1JOg8BohtlKTK+H/2+EaleUg6K28LWR+eWrnBh24 xNg3LDIhM1BnEx3PRkdCoBFNPfPgHTj5X+ypyUEq7MNGtg0rqTHcjO5MLcqcrPgTrzYv eUtHs2BCB7xMK3OM2o4dG80u2IMiInPgPjsbpMAaHEjn1c5Vy0v+qutZsW0i0ZOmnYA6 YChVE4PlphuMI99uVt/eo77exJdZ30XhZl1qd2gvG/MCmEO8O29v+MJW9J/ED0655Gjo E/WLbBMqoG21r/HLiV/NsPmuQQxzEG97naabjKSMRV/b+a2nowaCXoZtoaiNoMpYclRi Ocnw== X-Forwarded-Encrypted: i=1; AJvYcCXEcsN5Ka4cy7xTrMfcJKa50fjQgNBA2sQUuztOm5sbLenCgrV3xP9dDBMN8QW1eadubao=@dpdk.org X-Gm-Message-State: AOJu0YzU6L6eWuYlyUfOS8D72C0A2TlrVEr0IzRnlc3PTt+yMIF4hgN/ HVBUuRsN0zfN9ltJnOLsAcSJwmOH1dWsvVyft5j2ApW6aJirVnNAFHBv7mU1JS0= X-Google-Smtp-Source: AGHT+IHjkt1/42+wqM02dLffPml/0wWWFTtrJGdXA3ppITGzBjQVp9Vj6Du0RGt2hIWhlHVygvv6TQ== X-Received: by 2002:a17:90a:740a:b0:2c8:65cf:e820 with SMTP id 98e67ed59e1d1-2e5616c4202mr18227520a91.2.1729610760209; Tue, 22 Oct 2024 08:26:00 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e5ad4ed73fsm6337777a91.44.2024.10.22.08.25.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2024 08:26:00 -0700 (PDT) Date: Tue, 22 Oct 2024 08:25:58 -0700 From: Stephen Hemminger To: fengchengwen Cc: Isaac Boukris , Thomas Monjalon , , "haijie1@huawei.com >> Jie Hai" , Subject: Re: Use of strtok() in dpdk code Message-ID: <20241022082558.4d126664@hermes.local> In-Reply-To: <282a31cf-7ccd-4de3-99b9-687287b20e24@huawei.com> References: <20241021180820.48c7bffd@hermes.local> <282a31cf-7ccd-4de3-99b9-687287b20e24@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 22 Oct 2024 14:51:39 +0800 fengchengwen wrote: > On 2024/10/22 9:08, Stephen Hemminger wrote: > > On Mon, 21 Oct 2024 21:30:02 +0300 > > Isaac Boukris wrote: > > > >> Hello, > >> > >> I was debugging a crash resulting from strtok() returning NULL > >> unexpectedly (string still had tokens and delimiters), and the only > >> explanation I could come up with was that strtok is thread-unsafe and > >> another thread could have been calling it at the same time, and so I > >> changed it to use strtok_r(). > >> > >> That said, the only other possible use of strtok() that I could find > >> was in the dpdk code (telemetry), which brings me to my question, > >> should we consider changing all occurrences to strtok_r() or am I > >> missing something? there seem to be quite some in non-initialization > >> code. > >> > >> Thanks! > > > > > > Most of the uses are in tests and other single threaded code. > > In general, simpler just to use strtok_r everywhere and not worry about it. > > Similar to not using sprintf() and instead using snprintf(). > > I'm afraid I can't agree. > > DPDK is just a SDK, it's not an application (although DPDK provided simple examples). > Many code will developped based on DPDK, we can't predict how it was implemented. > So there maybe a DPDK thread and a application thread both invoke strtok(). > > From this point of view, I hope that DPDK solves some of the reentrant problems of > such C functions (e.g. strtok()\strerror()). > > Actually, we've try to solve before, but unfortunately it wasn't merged. > 1\ strtok(): https://inbox.dpdk.org/dev/20231114110006.91148-1-haijie1@huawei.com/T/#u > 2\ strerror(): https://inbox.dpdk.org/dev/20231114123552.398072-1-huangdengdui@huawei.com/T/#u > > > > > Some code scanners like codeql also flag this. > The usages of strtok() and strerror() in init code are fine. Stuff only called from eal_init() like devargs should be safe, but fixing it makes sense. Perhaps a coccinelle script could help here.