[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:23:27 +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=xIvYTYf4ZZUtA8PeomYaaxZ3wiW64APXTpJB+YGmRRg=; b=P1yZ9Fe0k5va8RYeGX3bBwAmiG3wF2o53EsiDhd8PCVV1xxfcRiyUHLoaiTssMcPvYxVn/N7V7E4G5QkS1XA3MuzI8K8mfR5vEP2tBOzdb9RyTKCG2RC9kw0PFEWDfa+K0LGWo29btbuOWtBaGs2lqn1bTgzKxobCF/1/iSCrXel/ILxRofZ1ToXbqmepZHEJaEiOfw+FHaLG5KIkhpddBSlJgOneBiXJRT2TiU/e2Wpi0Pe58JIDrPXhzdB/bGalie1bCkHnBYig3VyHi4tDsP2nb62DYH/JkLGsBIe14wo1Y/H7EKR39yawZkFsrXRLAhbCK4VayvyL1lr3dClHw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c566m8QQrLEe67WmQ5apK+U0G4CLLwFLwf197nkMF3FofR7/2YRRUXt/mROlNj/Xe/OChVLXQO51EUHAvL0aPBznn+1Bio83c5CJM29EX+gNFoHtNbc/RLRaVb/qXCAK9abz/MrXSGEPIJCAhIRt3j9NXgAvZNNLLkMOvYvfsSSz4j+WMufPx2+GuYzBZ4M3Ic0/SgxwESCdcGdhzk6Qa33ML7+JhMkoIjVKhJpSsdTbyce112CyJltY80ivGkzMw+W4Ear542CPibqO+CFoT0fAucNFr1NzFMXqiJ70ClwX4cCj6CjysW3nsEAfizx2yckZQbu7Fy8zP1NdPCbdyw==
  • Cc: Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>
  • Delivery-date: Thu, 07 Mar 2024 12:23:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Juergen,

On 3/7/2024 6:51 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>

Maybe add a "Fixes:" tag referencing Jan's patch?

Yes, will do.

And I would expand on the reason why you are using strerror() instead of just
checking the strerror_r() result. Something like:

  Using strerror_r() without special casing different build
  environments is impossible due to the different return types
  (int vs char *) depending on the environment. As p9_error()
  is not on a performance critical path, using strerror() with a
  mutex ought to be fine.

Thanks! Will add in commit message.

---
  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;

I wouldn't use RING_IDX for the type, but unsigned int.

Ok, I just mainly wanted to keep some consistency, but yeah unsigned int is definitely ok. Will follow your suggestion.

Kind regards,
Henry




 


Rackspace

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