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 589EDC433F5 for ; Wed, 11 May 2022 15:47:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBA086B0073; Wed, 11 May 2022 11:47:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B66C86B0075; Wed, 11 May 2022 11:47:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A07F06B0078; Wed, 11 May 2022 11:47:03 -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 8E1796B0073 for ; Wed, 11 May 2022 11:47:03 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 659AB22314 for ; Wed, 11 May 2022 15:47:03 +0000 (UTC) X-FDA: 79453890726.24.F487978 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf11.hostedemail.com (Postfix) with ESMTP id E12D7400A9 for ; Wed, 11 May 2022 15:46:57 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id l20-20020a17090a409400b001dd2a9d555bso2474517pjg.0 for ; Wed, 11 May 2022 08:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zoGgk2kWCSBtnI2kB77KiBaGWej6XbWC5/VEwo6RBHk=; b=UqYYm4C2fW4mDDQmf6XLxKC/brLgrS9dhVDWviBXTaq7FGn78m3bKsJeMNJHx2wk3+ rULMOiRS+P0ZWx8dLnN2gYJeg71wDglfQFgm5wJHMj2qg5/Je0FPLtro+JJ6iV9Lob+J IfdmTH9vDGh3EOK9znhgho9UvGmGaFbGdjwMUbVl29Q5hQzDGDMzzgme//fpmJKfSdEI SgE4NoSwVXXKTDiY9+FrBKb4FfRMkGv3/Z2uTE8/r0rYGZMyexdZWg0vAeis9xPQ/jRV 7K3vxdq6GuFpZBRpOMVOPe+7txqriPUqd25KBoLnRqz1lSlh2qUpWn2idi6g4DJR4Bsb UR7w== 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=zoGgk2kWCSBtnI2kB77KiBaGWej6XbWC5/VEwo6RBHk=; b=PBf2uinT8rfUi564T5FTRYoBQ/Nkd4guN5BI28cNvFCuAX7R7AOatd0I5IPJXfy9CQ Vy736XsRf46+F515uCnNCBg4mVqo14w+pVgXmgWiZ9tfe26iM0u9aLpu0fkMBeprCQAX bWxfrAcCfTypdUteLPkLXVZHZ7naVoDXeeHglY334lBE3jrHrR83khCr8ps63GsWm4ST yDnbfVcALEAUvTF7CXuEBON/rwzAvzkFMaagSaY4AQ7b4W9tKVH4hvt4YyD98lBaq2Pi loTHCekjqBJZJaM5IQ4alQmkVg01+ujkOF8iRbert+EHdQksfJE9T55xuV+S/UBEgUlc fICg== X-Gm-Message-State: AOAM530mobGyTSlPlhy37ERsylKZzG+Xty+zBAk81r8o8aZ7UDiOsole Sl3OHSpCEge1hpjds0KWci7k0soGac9trlVKn64uCw== X-Google-Smtp-Source: ABdhPJzb8nRTew8x8xkS/1yBjApTvNis41Up/0XXYEsHQ3BPsgO0HbXOB1SZHhshqbsoueRXOJsPthjQCb9zCs/wlcY= X-Received: by 2002:a17:90b:4c85:b0:1dc:5778:5344 with SMTP id my5-20020a17090b4c8500b001dc57785344mr6055143pjb.8.1652284021808; Wed, 11 May 2022 08:47:01 -0700 (PDT) MIME-Version: 1.0 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> <20220511151955.GC27212@magnolia> In-Reply-To: <20220511151955.GC27212@magnolia> From: Dan Williams Date: Wed, 11 May 2022 08:46:50 -0700 Message-ID: Subject: Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink To: "Darrick J. Wong" Cc: Andrew Morton , Dave Chinner , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E12D7400A9 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=UqYYm4C2; spf=none (imf11.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.216.49) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Rspam-User: X-Stat-Signature: 4qrff4aox8mooscffuog6tjp5qt1drmn X-HE-Tag: 1652284017-441851 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 Wed, May 11, 2022 at 8:21 AM Darrick J. Wong wrote: > > Oan 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? > > AFAICT, the new code falls back to the current (mf_generic_kill_procs) > failure code if the filesystem doesn't provide a ->memory_failure > function or if it returns -EOPNOSUPP. mf_generic_kill_procs can also > return -EOPNOTSUPP, but all the memory_failure() callers (madvise, etc.) > convert that to 0 before returning it to userspace. > > I suppose the weirder question is going to be what happens when madvise > starts returning filesystem errors like EIO or EFSCORRUPTED when pmem > loses half its brains and even the fs can't deal with it. Even then that notification is not in a system call context so it would still result in a SIGBUS notification not a EOPNOTSUPP return code. The only potential gap I see are what are the possible error codes that MADV_SOFT_OFFLINE might see? The man page is silent on soft offline failure codes. Shiyang, that's something to check / update if necessary.