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.wa...@amd.com>

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


Reply via email to