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 EE91CC433F5 for ; Wed, 30 Mar 2022 15:13:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244124AbiC3POo (ORCPT ); Wed, 30 Mar 2022 11:14:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238687AbiC3POn (ORCPT ); Wed, 30 Mar 2022 11:14:43 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D7572AE30 for ; Wed, 30 Mar 2022 08:12:57 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id bh17so2689539ejb.8 for ; Wed, 30 Mar 2022 08:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Mt0iqI8NgPnqJpJSrxtTBJCkN35gtulZa2EkVMb+B8=; b=F0KpY7ampbS6+0GR68DRUxolDvrfZMD31WMsYfIlEK1B4n/bCu1qwlkgA8yO24qoM/ /JllMTabaLsLjUIIjxbGJqoyeCKm891uu8wLSEP/x6DWcWK+paB6NFV6N0cMALLYYe7A 7bmLtjAmLIB+Wr0VG/EiuSTP1sNwhzb3eNxW8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Mt0iqI8NgPnqJpJSrxtTBJCkN35gtulZa2EkVMb+B8=; b=xQAyTCGwMvSqdj7jIMpyU9EdSFW3tj2PQjeV9nQmKbTz8sLHbM28EdR8ldaA7N7Lc8 i+AecJjJGhkMAZdOUn8TKVVZYxGH40JqnfqJlLoR6gZheF7D86Poafe5hRyEEEALxh8O nRzqt7bRBwROPWPngHUMp7mKUXXoS7t5d+z0A5WEtfFYQ8Zb1K4WdlDXfcxlJjp9X6AB trP7r7+0EctxxaOfly7b63s7H51pw36tjdREwyk2fOnOBs97inLL/g+eoivqTAb6DS2I M8SEyYUZSSy3cCHGEcwR15p3PrntZu40Arp22w3MXzEM7YOJlLhCv5+2hk4IBVGXXd9r nV+A== X-Gm-Message-State: AOAM530GgRArvI4GAbYMOMTsoit22DQiIoJzIuG2BPkGsDDLLgb6ZBDb h7qhg/AzL8Uwa8GtzF7oU8uKU2oLLRwo/qj3V99cFA== X-Google-Smtp-Source: ABdhPJz0C6HCh/NY2asSqcmb+2OVCCHLTcb/4tij50j2EC7795RTwd191FjfuCiTn2KbfphD4goUXKd1yOfSVPmaqXE= X-Received: by 2002:a17:906:280b:b0:6ce:f3c7:688f with SMTP id r11-20020a170906280b00b006cef3c7688fmr39810484ejc.468.1648653175859; Wed, 30 Mar 2022 08:12:55 -0700 (PDT) MIME-Version: 1.0 References: <8145e724-d960-dd85-531e-16e564a02f05@kernel.dk> <115fc7d1-9b9c-712b-e75d-39b2041df437@kernel.dk> <89322bd1-5e6f-bcc6-7974-ffd22363a165@kernel.dk> <0c5745ab-5d3d-52c1-6a1d-e5e33d4078b5@kernel.dk> <52dca413-61b3-8ded-c4cc-dd6c8e8de1ed@kernel.dk> <23b62cca-8ec5-f250-e5a3-7e9ed983e190@kernel.dk> <77229971-72cd-7d78-d790-3ef4789acc9e@kernel.dk> In-Reply-To: <77229971-72cd-7d78-d790-3ef4789acc9e@kernel.dk> From: Miklos Szeredi Date: Wed, 30 Mar 2022 17:12:44 +0200 Message-ID: Subject: Re: io_uring_prep_openat_direct() and link/drain To: Jens Axboe Cc: io-uring@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Wed, 30 Mar 2022 at 17:05, Jens Axboe wrote: > > On 3/30/22 8:58 AM, Miklos Szeredi wrote: > > Next issue: seems like file slot reuse is not working correctly. > > Attached program compares reads using io_uring with plain reads of > > proc files. > > > > In the below example it is using two slots alternately but the number > > of slots does not seem to matter, read is apparently always using a > > stale file (the prior one to the most recent open on that slot). See > > how the sizes of the files lag by two lines: > > > > root@kvm:~# ./procreads > > procreads: /proc/1/stat: ok (313) > > procreads: /proc/2/stat: ok (149) > > procreads: /proc/3/stat: read size mismatch 313/150 > > procreads: /proc/4/stat: read size mismatch 149/154 > > procreads: /proc/5/stat: read size mismatch 150/161 > > procreads: /proc/6/stat: read size mismatch 154/171 > > ... > > > > Any ideas? > > Didn't look at your code yet, but with the current tree, this is the > behavior when a fixed file is used: > > At prep time, if the slot is valid it is used. If it isn't valid, > assignment is deferred until the request is issued. > > Which granted is a bit weird. It means that if you do: > > > > the read will read from fileA. But for: > > > > since slot 1 is already valid at prep time for the read, the read will > be from fileA again. > > Is this what you are seeing? It's definitely a bit confusing, and the > only reason why I didn't change it is because it could potentially break > applications. Don't think there's a high risk of that, however, so may > indeed be worth it to just bite the bullet and the assignment is > consistent (eg always done from the perspective of the previous > dependent request having completed). > > Is this what you are seeing? Right, this explains it. Then the only workaround would be to wait for the open to finish before submitting the read, but that would defeat the whole point of using io_uring for this purpose. Thanks, Miklos