From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4038AEE49A6 for ; Sun, 20 Aug 2023 18:22:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231577AbjHTSWS (ORCPT ); Sun, 20 Aug 2023 14:22:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231579AbjHTSWR (ORCPT ); Sun, 20 Aug 2023 14:22:17 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAA8A3C00; Sun, 20 Aug 2023 11:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=uSgZ8XFQYbPRmErFBtSZC+ngAzMBC0yKooNBbIIROsU=; b=jqS035rW5NgiWOsFvi5uTxvZgZ F0I4SxnWln/gke8vnWakZmjwIzq4A8fvR6GiObG7eExSw6uU5f2Jo/S6vBu/P1YNT+Saeq9Siet6e el61osSHyWrkjThyIvRParzSwax5HLAT0UQBRWvHwfP6uOTV84U0Ew9Vgcvqs9A4ViSUpcB9gA47U ieMgx+PqGsLE6TjxUVKGNecVTAbzQUZIaZJyNX/vQJCDiBUWlB49gsEl5LHXHfSk7N6afnub/5RUr 6ciGuHdW+MtRn1ERM027mSNfNauFP77sjVhbg/B2czmBH32uhSuTJTkDKsZKTvC+UMnuOmk0iL18s NpsgMA2Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qXn0t-005WJH-6P; Sun, 20 Aug 2023 18:18:59 +0000 Date: Sun, 20 Aug 2023 19:18:59 +0100 From: Matthew Wilcox To: Jens Axboe Cc: Qu Wenruo , "linux-btrfs@vger.kernel.org" , Linux FS Devel , io-uring@vger.kernel.org Subject: Re: Possible io_uring related race leads to btrfs data csum mismatch Message-ID: References: <2b3d6880-59c7-4483-9e08-3b10ac936d04@gmx.com> <34e2030c-5247-4c1f-bd18-a0008a660746@gmx.com> <1726ad73-fabb-4c93-8e8c-6d2aab9a0bb0@gmx.com> <7526b413-6052-4c2d-9e5b-7d0e4abee1b7@gmx.com> <8efc73c1-3fdc-4fc3-9906-0129ff386f20@kernel.dk> <22e28af8-b11b-4d0f-954b-8f5504f8d9e4@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22e28af8-b11b-4d0f-954b-8f5504f8d9e4@kernel.dk> Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Sun, Aug 20, 2023 at 08:11:04AM -0600, Jens Axboe wrote: > +static int io_get_single_event(struct io_event *event) > +{ > + int ret; > + > + do { > + /* > + * We can get -EINTR if competing with io_uring using signal > + * based notifications. For that case, just retry the wait. > + */ > + ret = io_getevents(io_ctx, 1, 1, event, NULL); > + if (ret != -EINTR) > + break; > + } while (1); > + > + return ret; > +} Is there a reason to prefer this style over: do { ret = io_getevents(io_ctx, 1, 1, event, NULL); } while (ret == -1 && errno == EINTR); (we need to check errno, here, right? Or is io_getevents() special somehow?)