Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Ammar Faizi <ammarfaizi2@gnuweeb.org>
To:     Jens Axboe <axboe@kernel.dk>
Cc:     Ammar Faizi <ammarfaizi2@gnuweeb.org>,
        =?UTF-8?q?Barnab=C3=A1s=20P=C5=91cze?= <pobrn@protonmail.com>,
        Michael William Jonathan <moe@gnuweeb.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        io-uring Mailing List <io-uring@vger.kernel.org>,
        GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>
Subject: [PATCH liburing v1 0/2] 2 fixes for recv-msgall.c
Date:   Wed, 10 May 2023 21:39:25 +0700
Message-Id: <20230510143927.123170-1-ammarfaizi2@gnuweeb.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Jens,

This is the follow up patchset for the recent issue found in
recv-msgall.c. There are two patches in this series.

1. Fix undefined behavior in `recv_prep()`.
The lifetime of `struct msghdr msg;` must be long enough until the CQE
is generated because the recvmsg operation will write to that storage. I
found this test segfault when compiling with -O0 optimization. This is
undefined behavior and may behave randomly. Fix this by making the
lifetime of `struct msghdr msg;` long enough.

2. Fix invalid mutex usage.
Calling pthread_mutex_lock() twice with the same mutex in the same
thread without unlocking it first is invalid. The intention behind this
pattern was to wait for the recv_fn() thread to be ready. Use the
pthread barrier instead. It is more straightforward and correct.

Please apply!

Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org>
--- 

Ammar Faizi (2):
  recv-msgall: Fix undefined behavior in `recv_prep()`
  recv-msgall: Fix invalid mutex usage

 test/recv-msgall.c | 44 +++++++++++++++++++++-----------------------
 1 file changed, 21 insertions(+), 23 deletions(-)


base-commit: 4961ac480052089a94978e9f771d513551aff61b
-- 
Ammar Faizi