[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] tools/9pfsd: Fix build error caused by strerror_r()


  • To: Juergen Gross <jgross@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <xin.wang2@xxxxxxx>
  • Date: Thu, 7 Mar 2024 20:26:17 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5wOySSNZ3bdO+GZF+3nlrL9FW8KPKKFgpVKKiEZRwe0=; b=DyirWL8cewCRNE3GXpGi4WgFNO6tFZNhB0AQwtUhmO0vaYPaGrV4LVLX/5bKoHLbaH37veuxeS6jh6muukGRsNNSqn05LIv7zMQmTlAPVC1jkyLVAfG1b1NYhQxitIQ1wlqNWSC3czJONcXesojylG11Atk9K8GsatsSssYF8/lhFxZa+mDjNGik2lwFI+cU5YtaaodSnvt3LHKjIL0mZRskOfzYSoE3rsyQqbRAH8F/y1QyCzernTZcyxefGJ1zNmM7J4YD879wLQ4IcKLdTbEEl/hIjRiRSACrGnaRV2miAcHEmWIQjMfvxtXvQHpvglHI6ovBImz2+io7anQSGA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ELuAjBX5Iktx29iAdpILthbGM61whPuIDgZa1SLeTLafL3L4CAkD48bbNFLZ9qJLaQyqc7vz74FpxOsA9wwDJoulMynWvcGKmCOFGZ0Kije2X/FX+kxMY/YJnlrweXq/nITsBBX853w95usgZU2dnY/VnM1foPK3YzphKHxCWDn/aT6xBnn0IUne9Ku8cjswtIvBYGoyIvbqB5t9M3mvmzWtMevZhIzf5TxrJUGLII+HPp5KWrQqGhZoo/7A3mtk69G4yTbBeoWKV3zDvbKkAplSmNwKhXPVIr6lr599LDQ+mh2aXvuPBbh6//sK+oLR9YTHuAnM6KjL/g8e378Csg==
  • Cc: Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • Delivery-date: Thu, 07 Mar 2024 12:26:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Juergen,

On 3/7/2024 7:24 PM, Juergen Gross wrote:
On 07.03.24 11:38, Henry Wang wrote:
Below error can be seen when doing Yocto build of the toolstack:

| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
   with attribute 'warn_unused_result' [-Werror=unused-result]
|   684 |     strerror_r(err, ring->buffer, ring->ring_size);
|       |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| cc1: all warnings being treated as errors

Fix the build by using strerror() to replace strerror_r(). Since
strerror() is thread-unsafe, use a separate local mutex to protect
the action. The steps would then become: Acquire the mutex first,
invoke strerror(), copy the string from strerror() to the designated
buffer and then drop the mutex.

Signed-off-by: Henry Wang <xin.wang2@xxxxxxx>
---
  tools/9pfsd/io.c | 12 +++++++++++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c
index adb887c7d9..2b80c9528d 100644
--- a/tools/9pfsd/io.c
+++ b/tools/9pfsd/io.c
@@ -680,8 +680,18 @@ static bool name_ok(const char *str)
  static void p9_error(struct ring *ring, uint16_t tag, uint32_t err)
  {
      unsigned int erroff;
+    static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
+    char *strerror_str;
+    RING_IDX strerror_len = 0, copy_len = 0;
+
+    pthread_mutex_lock(&mutex);
+    strerror_str = strerror(err);
+    strerror_len = strlen(strerror_str) + 1;
+    copy_len = min(strerror_len, ring->ring_size);

Hmm, I think we even _need_ to cap the string earlier.

A string in the 9pfs protocol is a 2 byte length field plus the string.
In case of a ring larger than 65535 bytes this would mean the result of
strerror() could (in theory) overflow the string format of 9pfs.

Additionally the string should be a _short_ description of the error, so
I'd like to suggest to not use ring_size as the upper bound for the string
length, but a fixed value defined as a macro, e.g.:

#define MAX_ERRSTR_LEN 80

I can use a macro-defined value in v3, sure.

Kind regards,
Henry

Juergen




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.