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:   Fri, 23 Sep 2022 09:39:39 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Dave Chinner <david@fromorbit.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: <Yy2pC/upZNEkVmc5@nvidia.com>
References: <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>
 <632d00a491d0d_4a67429488@dwillia2-xfh.jf.intel.com.notmuch>
 <20220923021012.GZ3600936@dread.disaster.area>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220923021012.GZ3600936@dread.disaster.area>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?35fN8T/k5Y3o5sq7mvnk0dP1iGGnEhPPPWVB8/NMM+d/EFC4f5ZLgfcsy/U1?=
 =?us-ascii?Q?VtGuAgVyIvnDHjrxRWiNpPFr8S9FIxt0uPJhl51qAC2jzZvuvQ+Y7HSVaLAV?=
 =?us-ascii?Q?ypbJpFpU3GsHxNm8SZG6qtZY2jgbvAhYRhuCjTw3sOKkZfjw+Hpq043Woy7T?=
 =?us-ascii?Q?HRdqq/ooeG4zlgXsVqreVJmCeuH2+8OiM8ZtaeMNfxPdkCTVU300T8VKN40s?=
 =?us-ascii?Q?Wvr6NtbeDQLfU7mXW6L2gXM/lIq5b6a0obprb/59mq9ABN+BO9ezHlzXPPuc?=
 =?us-ascii?Q?8mG4JDRQU2k0rEMskeFKU8UFHmMFKpbhSAxFHe9kYXta8Sht/OeNWmsGoVtM?=
 =?us-ascii?Q?O+Oc6J/KRHaXN1j/hksRG66PpmT3SY/5c7RufA0YIsTuO8kLiDXdvVzWUHDD?=
 =?us-ascii?Q?YkiWeB0wNkprTxr0B8S+BTHQKwubweesvA2YDhlvbUmGYzZZCk1xAffRjjV8?=
 =?us-ascii?Q?HviDNH3hXYXvqznk+2y/aA6XsgxYeM4fiX1XskDOJ4edYPZq5jBtibcCF70C?=
 =?us-ascii?Q?SRDK1uCPh3/KSQa1ltkcUYVQFk9EImkZGOp/0XIzLuF5gVQ5ki9WLJNyRrYc?=
 =?us-ascii?Q?YUvQrwRNuj1w6QVDZXv9IetdDzbWaOQaBIx1PpZ+JSjAnqJsoazKUYDsCVre?=
 =?us-ascii?Q?RVbl0CpU34EmJ6Av5ZU0mHBAa1qr4xhMz+XLyFx8cvqgbm/priREpeGJ93IR?=
 =?us-ascii?Q?LLiI3p9kVtnJeEKCbYCStjk174IZ2p/NuyIX1Bj1ZhbodNWBACf96OxjYopk?=
 =?us-ascii?Q?gzfNUnER9/nXi/6L1HBSVZ9VyhiMPVb6G4J+yQyrWTo0vajtq3Ny0yjScgu7?=
 =?us-ascii?Q?pDNMyiIYWFFDcx0KkWbEG1w9I1HwOi76Iq3m1kDnxAvZpThQYdvUjIkDiuEK?=
 =?us-ascii?Q?w9xjBVWoVEz0Drg5lxNdFNK23+25GAE0bI1fUjjENibJ/WKkqEeTqZt4oetP?=
 =?us-ascii?Q?74xI/aLacHbDTmJ1dxt7TdoQzU0iuK6Nxrt8PJEb7bugK79iAZbv8LRJIrVu?=
 =?us-ascii?Q?+p8mJ1Y9cgYTV5Fep9RuldR7+tOyygxN7ogP+8YsFM9PQh/SsTnj6TBEOyj3?=
 =?us-ascii?Q?z8MwMXFC9ewNzNfcAWqxHd/x8+8wPqH/NB28Chnmmm1O1yb9CltjdlLP2Bdk?=
 =?us-ascii?Q?I/5eK22My6BAE2K2R71J9DdwIRjlKhhs3+ykASMSfhktPebyEYb5Km0AJ6xf?=
 =?us-ascii?Q?IBAlAJQTa5mIu5uIInVAGoO1lwXziJWwClflknLw2l+sBaa5J/6DG3/s0CMC?=
 =?us-ascii?Q?/AYHdRzRP0MI9k96BtRtC/CREJ3DD7RotPNqmHxofRji/iYM498KAAZOEbbs?=
 =?us-ascii?Q?BtVJfDlXPQHNa5IWEB5CexgJ1cqt0vbHxpoklrrWgtLUggutvO8DRwM4qfmx?=
 =?us-ascii?Q?fpsubyArVgZrMU43Dy5mg9JGk1hSm2O3ghAdR6g8yikUy3pLy99m4Y1Fu2Ox?=
 =?us-ascii?Q?5edbKbr6pmFBni8VbAnojIXppeIRnpSqJCncimgAhp11pOBFWxJCE2mJMApv?=
 =?us-ascii?Q?dAMOQmPUJ9qrI2FKzKgdTcHHbN09iOs9epwwKFOGJKk/C1EkkD3RRdMyK9ZC?=
 =?us-ascii?Q?2833AszuUro2NRGDqy/xPFnKqNedArIOntl20Yi1?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee6690a8-e45d-4ee6-67c7-08da9d60b279
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2022 12:39:46.5099
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 90q0ZUzVI3GS7GaB7BSUrqvZUR7OMJ0qqyEnsKp2DsX8oZ6Dqji3SnBZOzhH0fgm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7657
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no 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

On Fri, Sep 23, 2022 at 12:10:12PM +1000, Dave Chinner wrote:

> > 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.
> 
> And, ah, what production application does this and expects to be
> able to process the result of the read() operation without getting a
> SEGV?

The read() will do GUP and get a pined page, next the memunmap()/close
will release the inode the VMA was holding open. The read() FD is NOT
a DAX FD.

We are now UAFing the DAX storage. There is no SEGV.

It is not about sane applications, it is about kernel security against
hostile userspace.

> i.e. The underlying problem here is that memunmap() frees the VMA
> while there are still active task-based references to the pages in
> that VMA. IOWs, the VMA should not be torn down until the O_DIRECT
> read has released all the references to the pages mapped into the
> task address space.

This is Jan's suggestion, I think we are still far from being able to
do that for O_DIRECT paths.

Even if you fix the close() this way, doesn't truncate still have the
same problem?

At the end of the day the rule is a DAX page must not be re-used until
its refcount is 0. At some point the FS should wait for.

Jason