Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 22 Sep 2022 17:41:08 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Dave Chinner <david@fromorbit.com>,
        Jason Gunthorpe <jgg@nvidia.com>
CC:     Dan Williams <dan.j.williams@intel.com>,
        <akpm@linux-foundation.org>, Matthew Wilcox <willy@infradead.org>,
        Jan Kara <jack@suse.cz>, "Darrick J. Wong" <djwong@kernel.org>,
        Christoph Hellwig <hch@lst.de>,
        John Hubbard <jhubbard@nvidia.com>,
        <linux-fsdevel@vger.kernel.org>, <nvdimm@lists.linux.dev>,
        <linux-xfs@vger.kernel.org>, <linux-mm@kvack.org>,
        <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH v2 05/18] xfs: Add xfs_break_layouts() to the inode
 eviction path
Message-ID: <632d00a491d0d_4a67429488@dwillia2-xfh.jf.intel.com.notmuch>
References: <166329930818.2786261.6086109734008025807.stgit@dwillia2-xfh.jf.intel.com>
 <166329933874.2786261.18236541386474985669.stgit@dwillia2-xfh.jf.intel.com>
 <20220918225731.GG3600936@dread.disaster.area>
 <632894c4738d8_2a6ded294a@dwillia2-xfh.jf.intel.com.notmuch>
 <20220919212959.GL3600936@dread.disaster.area>
 <6329ee04c9272_2a6ded294bf@dwillia2-xfh.jf.intel.com.notmuch>
 <20220921221416.GT3600936@dread.disaster.area>
 <YyuQI08LManypG6u@nvidia.com>
 <20220923001846.GX3600936@dread.disaster.area>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220923001846.GX3600936@dread.disaster.area>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?8KJho5nTh6dtabWTn7bMg8ms0+FxM4pRWPlxz5vEf+3U0R3YRtJS7EGuHwYl?=
 =?us-ascii?Q?5f5SrC04lihJmq8pMTxD/Uj2GoXv6suYk326SLAJeRk4E2L1Fz92iaP83u0r?=
 =?us-ascii?Q?4P+nqJeidgwwKRZyP8a8n945s8FpslQN91v7UQ95WsPpSsvWcpkoqzcGWlB7?=
 =?us-ascii?Q?P4sh/1EqB5PNMWXThCoTR7dhleFNYBQGs2fUnEf2NmYKBbCCpkeR4sKb0tJR?=
 =?us-ascii?Q?O4TQW1V1cRUHFBRF0/LK0DcZfy074BNaknbnpSuKvajzG31QDSncJcOJP/tc?=
 =?us-ascii?Q?ASTDsGnUixyUQelK2i66rnXnM3vhwCsSTQwEF/HNltTs9lZ5akTtdSoGPUeP?=
 =?us-ascii?Q?7RN86mFdXuxTz8q6JFgmJ75yrBrexahXL3iK+QtAg5ZaeMCNPF+Ey+oYXS96?=
 =?us-ascii?Q?96+8qJZBy7dLgTOcHJInxMuBduKE9fuvrO/Jx9bkRg3yXM6XRjeFgE0Um65p?=
 =?us-ascii?Q?vcNPraT/uRdWkvVWMzFbuky5ZcL/lJZ6S4MEdyg+DXxJmoNJvufVaypldVNj?=
 =?us-ascii?Q?UiHaQ6LnVli/0fCId2UtSzc+D2P5aGTeJfq4hTWrJoqBxleEJDV8oIk2Kpw9?=
 =?us-ascii?Q?2nf6HVmjJNe8q6QoS4Mtx52ioAczBDvJaQK1nnbziEoRJ0AI+fZoWLQ8/dhh?=
 =?us-ascii?Q?aZ5ymrUtfXyrgXEnozGgjDUYWTLMWrO916b7QiCKgvb+SaBLNTy2FVdrbSHa?=
 =?us-ascii?Q?/VdOx9x9NrNYY8yT40+F78y/mR5UcMHPuTXdZkafEYYu1IVLfVXiE7WCJZ11?=
 =?us-ascii?Q?7iyTCBjDw79xwBNBhFEAdl8Kj7bJzO8ZSRiaJQcVYdixAOE7zrYSMmHkRD/w?=
 =?us-ascii?Q?HJbHULcV6/OCvR06sBslGYuEZ3phDZDsf7s3/MbHLOk5hUa/vRkgkiPrGX5e?=
 =?us-ascii?Q?23YrTOxxk6vIpdRSQx/Q+VZaKGFRPGEkO5ShFEhWf9llUN0wp3K38RS3TmG2?=
 =?us-ascii?Q?shOWjx1RQJuSVo92Qwy5f1LG09V55DgNNiCvwWbfCuMCi20eES0Tgoj/642x?=
 =?us-ascii?Q?0Uy6MeE6OYoUg0fFTKL4NUgAa2EvZRHCnc5eiNshTdAmhjdZv4LjKat1rnEU?=
 =?us-ascii?Q?3tPsbrloCCKcFun6zyA/UnYHdWRvOxF75RnVK1xrj8w21soREBUOdR6Y7Gj4?=
 =?us-ascii?Q?0I61U5vs0ipvXkXtBmwE0fYujXIRU8WUVtMLusAZFII48PYmex+7RQVxkNnr?=
 =?us-ascii?Q?ef37Ks6JarpPhE6gk3zB6ZQXlX3XZMYt2oD8mV1/UkCzKGeE8kohdjUadk2O?=
 =?us-ascii?Q?jkhgnQ5Nbpa3eufjOVF4u0Wig4a8jYqF66l0aJkNSdLA/l6kKnLdCSnna2cG?=
 =?us-ascii?Q?uM7WYaUtFau7imu//97IA6YdTgt7MdxlTGjNzMRDwBgsngGKRFQkCew1Bh82?=
 =?us-ascii?Q?pEJNYB6rIcoRRG7K10YBvU4hjFIk7kq8z79eXedIAJnRdEJASwUJdS9NV2xs?=
 =?us-ascii?Q?WdNHnr/9xj1uiK6F063MFKpZdeYyFiOI4i5wNR8yxYY1nOaN3ZcgRV5ND4nB?=
 =?us-ascii?Q?OZk1q1fSEsWSWXRCF4s9EwlChT5Cinxde/0GDTjXYI2JJpqLR2U4XEqT9ZRM?=
 =?us-ascii?Q?5BV0FStyle6wLDTlZYRdA4XIHKqME6Hu4vB2X00JtQAtOHjW+01VZIGZmtw2?=
 =?us-ascii?Q?jQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a3fbaecb-b50e-4f22-85f4-08da9cfc505d
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2022 00:41:12.2063
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: as8ido6b9zpye3yWOM1vHEkLAylK2NQG7fvmweuK+V0UiePHB0+rH33waX2ofEP/OS5KWppu+UbPKkjXsjBHLK/3GbRiy/kMGLwd0V2/vr4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB6472
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-ext4.vger.kernel.org>
X-Mailing-List: linux-ext4@vger.kernel.org

Dave Chinner wrote:
> On Wed, Sep 21, 2022 at 07:28:51PM -0300, Jason Gunthorpe wrote:
> > On Thu, Sep 22, 2022 at 08:14:16AM +1000, Dave Chinner wrote:
> > 
> > > Where are these DAX page pins that don't require the pin holder to
> > > also hold active references to the filesystem objects coming from?
> > 
> > O_DIRECT and things like it.
> 
> O_DIRECT IO to a file holds a reference to a struct file which holds
> an active reference to the struct inode. Hence you can't reclaim an
> inode while an O_DIRECT IO is in progress to it. 
> 
> Similarly, file-backed pages pinned from user vmas have the inode
> pinned by the VMA having a reference to the struct file passed to
> them when they are instantiated. Hence anything using mmap() to pin
> file-backed pages (i.e. applications using FSDAX access from
> userspace) should also have a reference to the inode that prevents
> the inode from being reclaimed.
> 
> So I'm at a loss to understand what "things like it" might actually
> mean. Can you actually describe a situation where we actually permit
> (even temporarily) these use-after-free scenarios?

Jason mentioned a scenario here:

https://lore.kernel.org/all/YyuoE8BgImRXVkkO@nvidia.com/

Multi-thread process where thread1 does open(O_DIRECT)+mmap()+read() and
thread2 does memunmap()+close() while the read() is inflight.

Sounds plausible to me, but I have not tried to trigger it with a focus
test.