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 5593DC433F5 for ; Wed, 11 May 2022 06:21:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5C5F6B0073; Wed, 11 May 2022 02:21:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE5416B0075; Wed, 11 May 2022 02:21:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5F0B6B007D; Wed, 11 May 2022 02:21:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B3C836B0073 for ; Wed, 11 May 2022 02:21:26 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 8BC8E121BD2 for ; Wed, 11 May 2022 06:21:26 +0000 (UTC) X-FDA: 79452465372.06.7C50B71 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by imf14.hostedemail.com (Postfix) with ESMTP id 8D60110009F for ; Wed, 11 May 2022 06:21:23 +0000 (UTC) Received: from dread.disaster.area (pa49-181-2-147.pa.nsw.optusnet.com.au [49.181.2.147]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id D9E8B10E6B15; Wed, 11 May 2022 16:21:20 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1nofip-00AaTy-9h; Wed, 11 May 2022 16:21:19 +1000 Date: Wed, 11 May 2022 16:21:19 +1000 From: Dave Chinner To: Andrew Morton Cc: "Darrick J. Wong" , Dan Williams , Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , Christoph Hellwig , Jane Chu , Goldwyn Rodrigues , Al Viro , Matthew Wilcox , Naoya Horiguchi , linmiaohe@huawei.com Subject: Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink Message-ID: <20220511062119.GI1098723@dread.disaster.area> References: <20220508143620.1775214-1-ruansy.fnst@fujitsu.com> <20220511000352.GY27195@magnolia> <20220511014818.GE1098723@dread.disaster.area> <20220510192853.410ea7587f04694038cd01de@linux-foundation.org> <20220511024301.GD27195@magnolia> <20220510222428.0cc8a50bd007474c97b050b2@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220510222428.0cc8a50bd007474c97b050b2@linux-foundation.org> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=deDjYVbe c=1 sm=1 tr=0 ts=627b55e4 a=ivVLWpVy4j68lT4lJFbQgw==:117 a=ivVLWpVy4j68lT4lJFbQgw==:17 a=kj9zAlcOel0A:10 a=oZkIemNP1mAA:10 a=VwQbUJbxAAAA:8 a=QyXUC8HyAAAA:8 a=omOdbC7AAAAA:8 a=7-415B0cAAAA:8 a=37abNmnZhWSmtZz8jCkA:9 a=CjuIK1q_8ugA:10 a=AjGcO6oz07-iQ99wixmX:22 a=biEYGPWJfzWAr4FL6Ov7:22 X-Stat-Signature: ihy5rtqup8s4jprsju3jnubg3io4icmh X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8D60110009F X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=none; spf=none (imf14.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 211.29.132.249) smtp.mailfrom=david@fromorbit.com; dmarc=none X-HE-Tag: 1652250083-593391 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 Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote: > On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" wrote: > > > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams wrote: > > > > > > > > It'll need to be a stable branch somewhere, but I don't think it > > > > > really matters where al long as it's merged into the xfs for-next > > > > > tree so it gets filesystem test coverage... > > > > > > > > So how about let the notify_failure() bits go through -mm this cycle, > > > > if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 > > > > baseline to build from? > > > > > > What are we referring to here? I think a minimal thing would be the > > > memremap.h and memory-failure.c changes from > > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.fnst@fujitsu.com ? > > > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > > would probably be straining things to slip it into 5.19. > > > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > > right thing, but it's a networking errno. I suppose livable with if it > > > never escapes the kernel, but if it can get back to userspace then a > > > user would be justified in wondering how the heck a filesystem > > > operation generated a networking errno? > > > > most filesystems return EOPNOTSUPP rather enthusiastically when > > they don't know how to do something... > > Can it propagate back to userspace? Maybe not this one, but the point Darrick is making is that we really don't care if it does because we've been propagating it to userspace in documented filesystem APIs for at least 15 years now. e.g: $ man 2 fallocate ..... Errors ..... EOPNOTSUPP The filesystem containing the file referred to by fd does not support this operation; or the mode is not supported by the filesystem containing the file referred to by fd. ..... Other random examples: pwritev2(RWF_NOWAIT) can return -EOPNOTSUPP on buffered writes. Documented in the man page. FICLONERANGE on an filesystem that doesn't support reflink will return -EOPNOTSUPP. Documented in the man page. mmap(MAP_SYNC) returns -EOPNOTSUPP if the underlying filesystem and/or storage doesn't support DAX. Documented in the man page. I could go on, but I think I've made the point already... Cheers, Dave. -- Dave Chinner david@fromorbit.com