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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93760C43334 for ; Fri, 1 Jul 2022 14:19:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 003EA6B0071; Fri, 1 Jul 2022 10:19:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ECED16B0073; Fri, 1 Jul 2022 10:19:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D48AB6B0074; Fri, 1 Jul 2022 10:19:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C1F9B6B0071 for ; Fri, 1 Jul 2022 10:19:10 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 810E0EEF for ; Fri, 1 Jul 2022 14:19:10 +0000 (UTC) X-FDA: 79638738060.20.D9B9480 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf19.hostedemail.com (Postfix) with ESMTP id B592B1A0040 for ; Fri, 1 Jul 2022 14:19:09 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id n10so2560958plp.0 for ; Fri, 01 Jul 2022 07:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=rzOZ/i9oSJaRcIRoI1iWhltC/vefgetj7tSZBTo878o=; b=5HQrr8bsUEE61UmPmshuXLouerN7bDpQGL6uPBj0Z6oD+Z+BzfeXdXxfm+HPdIICP6 /xCJl1spZE4rJ97OF6puWsMJeHT9fvWxiRJbInko4k9KIJa9H4KxjwB5wo6cnUvHyRFj 3sa5jGx+4i/PgAp+XuwaejZ9X4yU18bWxPPbSJ0UKI9Z/6uHpbhVEcuSij4DdWW05JlZ rCM4EpDrWg0Cx81bPnObzhqxBdnMW586nX+S86OWrQyBaK4GXuBJJfPgVpsJaUqMJBNT j26E0dFwkFVt/aYyW3ZaB1RbYsySGLK4uO5JiaNKqgQcAS22gmYw9jOHmKP7CkOyB0aw FYNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=rzOZ/i9oSJaRcIRoI1iWhltC/vefgetj7tSZBTo878o=; b=CN8P3g9WY8GYza/C7MovTeoz+pkl41g+59ZO5hWFTjAOfMbyEybWFfThWsoHvq2/Gl bCRTlO8vdouLTuvDHdnokUDzTcCB+q7uk3SLGkJi6l3KB1Zr8CvE7tn/AeMCLUQQNhHt gw4/2e/bmcs/fOrrTBD1xHns014OxBy+ZlENEombbpUXS+wHZD4nsDu6oo8MnhGzMj4+ MVgMFWMdvTygXSLejpjsHAK45VQ2cgBbZJisKYuwdSFdXVSA1FxpR386k/m7MlhZm5tG iSawpZ3PDEB7D+0a+/Sq5YiT+ymfgWhxRe/4UUzV7/pxXv8KD/kMt/ERvESvhAO9jM1Y kr9Q== X-Gm-Message-State: AJIora93Gcd+H6OHHEy7S7mAfo00E3t4Z5k/6piqRO/k8zwsd01OU7k6 mnr4Q7zo/J2ZTSVjn7auzYLsdQ== X-Google-Smtp-Source: AGRyM1v0RzZrxH3XgsAPTjbzNfvNy9O3MwTKLMrckgh2iet5mvp0kq7mJYZDwHlDICGwRoI1VcItsw== X-Received: by 2002:a17:90b:17c3:b0:1ed:157:b9f1 with SMTP id me3-20020a17090b17c300b001ed0157b9f1mr17066106pjb.205.1656685148583; Fri, 01 Jul 2022 07:19:08 -0700 (PDT) Received: from [192.168.1.100] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id g8-20020a62e308000000b005251ff30dccsm15615879pfh.160.2022.07.01.07.19.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jul 2022 07:19:07 -0700 (PDT) Message-ID: <0a75a0c4-e2e5-b403-27bc-e43872fecdc1@kernel.dk> Date: Fri, 1 Jul 2022 08:19:06 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v7 15/15] xfs: Add async buffered write support Content-Language: en-US To: Al Viro , Stefan Roesch Cc: io-uring@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, david@fromorbit.com, jack@suse.cz, hch@infradead.org, Christoph Hellwig References: <20220601210141.3773402-1-shr@fb.com> <20220601210141.3773402-16-shr@fb.com> From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656685150; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rzOZ/i9oSJaRcIRoI1iWhltC/vefgetj7tSZBTo878o=; b=SzG6TUCpPNcH2qKJRs/ETOH5h9mVXRZPWTLKRVVBcN3TBTr1b1w2U1yRrDmUwXh6BMofky Pr430yFMOBca2kPvq2h7YWP0tdvDu8gPnY1qZkVk7VwX3+MEn0XrX8CFO1Xl4HpPY8oSkV iQx/PD2tSMVXB6siTOGuThDYzAUGAjs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656685150; a=rsa-sha256; cv=none; b=rl9viX794s8EsU4vdDkhERV7/cuAB+jJQBqwguG2iVi75ruaL/JEJfOfPJ3TYkKJNYtD/C bNooCmg6y0k+3AIlBXt76GXVsxyYkt6qEm9K4DdoayaxGCQ/Xnn064Dd13/qS8k0M3Aa1J gm11/LTPca9fShuLk9DYH8hYFSKyhfc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=5HQrr8bs; dmarc=none; spf=pass (imf19.hostedemail.com: domain of axboe@kernel.dk designates 209.85.214.172 as permitted sender) smtp.mailfrom=axboe@kernel.dk X-Stat-Signature: 7djinpgfaxptfbcwkpoyjd7bm5embiaj X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=5HQrr8bs; dmarc=none; spf=pass (imf19.hostedemail.com: domain of axboe@kernel.dk designates 209.85.214.172 as permitted sender) smtp.mailfrom=axboe@kernel.dk X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B592B1A0040 X-HE-Tag: 1656685149-446920 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/30/22 10:39 PM, Al Viro wrote: > On Wed, Jun 01, 2022 at 02:01:41PM -0700, Stefan Roesch wrote: >> This adds the async buffered write support to XFS. For async buffered >> write requests, the request will return -EAGAIN if the ilock cannot be >> obtained immediately. > > breaks generic/471... That test case is odd, because it makes some weird assumptions about what RWF_NOWAIT means. Most notably that it makes it mean if we should instantiate blocks or not. Where did those assumed semantics come from? On the read side, we have clearly documented that it should "not wait for data which is not immediately available". Now it is possible that we're returning a spurious -EAGAIN here when we should not be. And that would be a bug imho. I'll dig in and see what's going on. -- Jens Axboe