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 7A607C54E60 for ; Fri, 15 Mar 2024 02:25:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90FB5800EF; Thu, 14 Mar 2024 22:25:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8BE2A800B4; Thu, 14 Mar 2024 22:25:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 785F5800EF; Thu, 14 Mar 2024 22:25:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 66373800B4 for ; Thu, 14 Mar 2024 22:25:49 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C5C61C0256 for ; Fri, 15 Mar 2024 02:25:48 +0000 (UTC) X-FDA: 81897682776.17.FC05EC9 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf15.hostedemail.com (Postfix) with ESMTP id A703BA000D for ; Fri, 15 Mar 2024 02:25:45 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fHfJmHPB; spf=pass (imf15.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710469546; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UYWo+uASOuXDh53bEqM9LRR7deedZF14peInEPZmXY0=; b=4zRMsWpae9jjjIlHr9xWoNTb07MWTZEdxW2pWnWDAjVTda2mwdduJh+U8Ai6aaXOd/YAab xrT9yxtRPoOAH4afg/0uwgeXVNRqHNeaInADRva5bj+Q1EaJtkUam6ROsRs+uTHgwBDPQV Sxje4ZxSDSSHLMX5LWawfhd4Jm9dcZM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710469546; a=rsa-sha256; cv=none; b=LmQ78/6FOechB4EbSBxgnjv+plWvJitPzXyMEjT5q6QsUO17JPcRJryA8xj4aj/OF4baGq iLw3qNRwg69DmcFUxyZQA9poer7/USKqO+MmgQMnfFIeBnEuJKSrk46yq1bxA8yYFkSmd3 Xqcas/Mm0vz2INOPilBmB/K+wztRdM4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fHfJmHPB; spf=pass (imf15.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id C382CCE1F3C; Fri, 15 Mar 2024 02:25:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07C15C433F1; Fri, 15 Mar 2024 02:25:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710469541; bh=g/yhIwX3XvlhVWvh9kFVm4R5Le/gPv0TUWKca6Jwjg4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fHfJmHPB3o7/qILSKnQc+WnzSMZV7uO0+2RHkjCoTkkOPCf7lJ6Xs8+s9mQqFQOXq Q9bsU3hHzrcgg8Pz0LC5eq7jHm45z4awbJ8Rft9uSYiydDzVshBpHFGBThJhdyCrU4 cmVXJ7lfClQBP7R6B0ii2DH7uGqhRLTlI62ROyic7LE/Cr9BEOUfVNxJjlzEca2Cn5 LlzOD9mlM5hIyDjKLwxv/5/Q5O4jb3Rd5RUzv46uaL0vYFB8AW1cyH9c5z+SJYh/X3 8Je0Bg93ytVSqel5I/KPQmBXOaRwenUBklQBdd2y7p7qSJmxmOtsmsethDdeEfuPXo peoQ2a3m0XQ7A== Date: Thu, 14 Mar 2024 19:25:40 -0700 From: "Darrick J. Wong" To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , John Hubbard , Jason Gunthorpe , Hugh Dickins Subject: Re: [PATCH v1 0/2] mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly Message-ID: <20240315022540.GD6226@frogsfrogsfrogs> References: <20240314161300.382526-1-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240314161300.382526-1-david@redhat.com> X-Rspamd-Queue-Id: A703BA000D X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: bs511fb3r5judwyi3f8ny4uue9pk5kw5 X-HE-Tag: 1710469545-925741 X-HE-Meta: U2FsdGVkX1+ax4viMbXGUJ+t65DiSB9NHt4Qpy/+CTk+Y3ngdj+CR8qAINXI3uwXG36dlt7UrbdesO0gfOwYpaPnnD6+yUquuxrYx0PBZdDKs8eFvsmiqWZwrZhNeTl3XAF1nsvOXVP2gRMLw/9NooebMOULVovNwr8KsOcvYH2mDThXaOqYHOGMfXcupB6vZBNQFRhylgpe+xl4OurL+x8Mcpgw5KmbXyDjt6AR6VBxAzI7HOFVZeYObHsUs0uFMKPbiWAPgtBJqnNT31vTRtBK/SetIoqsbZ6NyMoGh+lc85j43f+F0f+C/vQ5bE3r83kil4Eqr5IXa7TDSxBLT6fSm9Jbcua7qmCtXMDi3bbdFQlTU9bzCRqO6DrEiGUbRm4K0/Gir/ZqVHe7Oxmg67BVGAAxBaQBUz4e3Rf3BjGY4T6QeoCw+nTdzztumT5rUHZWQsaBmXk9B+B7tpnquulAeSWt2mN+m7JuChZOb6DSdPQWo3Y4+DB52KW+AQghOptKUy+rcxdBPQVQjKa4H4fhQIdFOpwc+DCTQygrnqa6MScelVpU70I6QNxZhqs//F0d/sQkmsuZ242X7GAGgcM14r9vUIwRJzZn3HzCZ5H3JK0RpPPJzmZAxX4EfTMWdZacSSpRA4LPLt/R4MKB/rkae92IDw3Qo1EcKp0UzABB7yqymBM6zg/RmalKcMDXg/IDszA1s9LajP5g1c0c4txuafYOIVe4CrrE316Iv9zhCPvaW+8ut6uj0RgxnBUCAUPjEffdpt5D0WpYSPFup3Ei/vj1EZTk2skzkXyXvzucaEu5Q7Ltwgb/nty272aukvkc5Q7rWywLZ0mxc4K32NUUr9cpy2D2NWkes6uNwTteYk/SJGRHe50XTuCI17ST7qcfexJF4st/iPNtMMtNDOHBKg/7rIfGFeCNITYZcY6cLcYXXqc+Vg== 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: List-Subscribe: List-Unsubscribe: On Thu, Mar 14, 2024 at 05:12:58PM +0100, David Hildenbrand wrote: > Derrick reports that in some cases where pread() would fail with -EIO and > mmap()+access would generate a SIGBUS signal, MADV_POPULATE_READ / > MADV_POPULATE_WRITE will keep retrying forever and not fail with -EFAULT. > > It all boils down to missing VM_FAULT_RETRY handling. Let's try to handle > that in a better way, similar to how ordinary GUP handles it. > > Details in patch #1. In short, move special MADV_POPULATE_(READ|WRITE) > VMA handling into __get_user_pages(), and make faultin_page_range() > call __get_user_pages_locked(), which handles VM_FAULT_RETRY. Further, > avoid the now-useless madvise VMA walk, because __get_user_pages() will > perform the VMA lookup either way. > > I briefly played with handling the FOLL_MADV_POPULATE checks in > __get_user_pages() a bit differently, integrating them with existing > handling, but it ended up looking worse. So I decided to keep it simple. > > Likely, we need better selftests, but the reproducer from Darrick might > be a bit hard to convert into a simple selftest. No worries, I can convert my reproducer into an fstest. I actually had no idea that there were so many madvise flags, it's tempting to wire up fsx and fsstress so that the long soak group tests will exercise them. > Note that using mlock() in Darricks reproducer results in a similar > endless retry. Likely, that is not what we want, and we should handle > VM_FAULT_RETRY in populate_vma_page_range() / __mm_populate() as well. > However, similarly using __get_user_pages_locked() might be more > complicated, because of the advanced VMA handling in > populate_vma_page_range(). > > Further, most populate_vma_page_range() callers simply ignore the return > values, so it's unclear in which cases we expect to just silently fail, or > where we'd want to retry+fail or endlessly retry instead. With this patchset applied, my reproducer no longer gets stuck in an infinite loop. I'll throw this at fstests overnight and see if anything else falls out. Thank you! --D > Cc: Andrew Morton > Cc: Darrick J. Wong > Cc: John Hubbard > Cc: Jason Gunthorpe > Cc: Hugh Dickins > > David Hildenbrand (2): > mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY > properly > mm/madvise: don't perform madvise VMA walk for > MADV_POPULATE_(READ|WRITE) > > mm/gup.c | 54 ++++++++++++++++++++++++++++++--------------------- > mm/internal.h | 10 ++++++---- > mm/madvise.c | 43 +++++++++++++--------------------------- > 3 files changed, 52 insertions(+), 55 deletions(-) > > > base-commit: f48159f866f422371bb1aad10eb4d05b29ca4d8c > -- > 2.43.2 >