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 96443C54EED for ; Thu, 26 Jan 2023 15:39:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE48A6B0072; Thu, 26 Jan 2023 10:39:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B94398E0002; Thu, 26 Jan 2023 10:39:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A349D8E0001; Thu, 26 Jan 2023 10:39:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 92B526B0072 for ; Thu, 26 Jan 2023 10:39:28 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 54B9B405B7 for ; Thu, 26 Jan 2023 15:39:28 +0000 (UTC) X-FDA: 80397359616.11.EFC2F25 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf07.hostedemail.com (Postfix) with ESMTP id BF09D40014 for ; Thu, 26 Jan 2023 15:39:24 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=i6ecjq4S; spf=pass (imf07.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=imbrenda@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674747565; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MziNJv7xMqAQguX1mEsCfA3Ab0sKckrLrjtmoh0kxHc=; b=adIcxH6RkdL1ubDeh/nUlu0h0ftF8mgCxJoZexiUIEk5p0BSuP9lamzIsFw9oGTp4XAZeg 6fTk3vloziM/V5+3E7zlE6bKchE13gom7XlEC5J9IGhMqH1DwTYqc1O5iohWJID6q2MWmG X5LYPugy7ILtvaPI/BKAzIuSGHIhjfA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=i6ecjq4S; spf=pass (imf07.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=imbrenda@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674747565; a=rsa-sha256; cv=none; b=cvWwNcdvu7fd+U2PAiKwxC7JqykTUtLp97FidhwD+GTEAuT51giis6Vo4KMgXYp1q1RFDd +OWgPgluNKYJrL8PJmrG+qKJP1kEqhzW2NDj01cCvYhyLiZ6yT8oVa2FW7aYRPppd271Hr o01YcTfTQGff+VZ+HkIwLt2Wd1XAcvk= Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30QFEevA029150; Thu, 26 Jan 2023 15:39:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=MziNJv7xMqAQguX1mEsCfA3Ab0sKckrLrjtmoh0kxHc=; b=i6ecjq4SqZCdldBodOIO7L5cvpz/DRoSf4L+SWeUUnQqHMhgSwQV2spKKhfBxc7uC6hb XjavNMVs7ConMpgS9jkUdnLrpWsqNyK0clkyjDb+4inIttPHTJ8NtETkN3FtambTJ+T0 P322oWnMoepa7Tqq0YOT8Uyma3xPyUPLSGJ9+//gDCoaf94o9Svn1qdmoTu6gZnKN/y/ tHtVcGCoY9BzsSNzdsvS1aFAqUflyCXMRi9DpFILzRZ2VlOmziUDWXezx2aG8Tu2CU3H nNQIe7JJKlm3xJQgCmjIgZy3KQbBmYU+Q99N6bVukLaNO9CpbIEe+aaAKS2D7vliNuXW yg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nbtnuatcf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Jan 2023 15:39:11 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30QFFQGQ002690; Thu, 26 Jan 2023 15:39:11 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nbtnuatbe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Jan 2023 15:39:10 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30QALOXE014941; Thu, 26 Jan 2023 15:39:09 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma06ams.nl.ibm.com (PPS) with ESMTPS id 3n87afehw0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Jan 2023 15:39:08 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30QFd4Pl29622546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Jan 2023 15:39:04 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A0E9920043; Thu, 26 Jan 2023 15:39:04 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 403D820040; Thu, 26 Jan 2023 15:39:04 +0000 (GMT) Received: from p-imbrenda (unknown [9.152.224.56]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 26 Jan 2023 15:39:04 +0000 (GMT) Date: Thu, 26 Jan 2023 16:39:02 +0100 From: Claudio Imbrenda To: Jason Gunthorpe Cc: David Hildenbrand , Alistair Popple , David Howells , Christoph Hellwig , John Hubbard , linux-mm@kvack.org, "Mike Rapoport (IBM)" , Christian Borntraeger , Janosch Frank Subject: Re: [PATCH v2 13/13] mm/gup: move private gup FOLL_ flags to internal.h Message-ID: <20230126163902.16898798@p-imbrenda> In-Reply-To: References: <13-v2-987e91b59705+36b-gup_tidy_jgg@nvidia.com> <20230126154148.2442e4cd@p-imbrenda> <7388b6a6-85f5-2e61-e3dc-54de531308d0@redhat.com> Organization: IBM X-Mailer: Claws Mail 4.1.1 (GTK 3.24.35; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: lfDO3WqwAGRIlXqDTmM4ewWZfW2JQ2BE X-Proofpoint-GUID: wZXyiPaPUOVr7_UFNFVHM872UHgHvM1E X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-26_07,2023-01-25_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 spamscore=0 mlxlogscore=896 priorityscore=1501 clxscore=1015 adultscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301260146 X-Stat-Signature: y8nzbusafde94weiacg3iwdhqc47c9xh X-Rspam-User: X-Rspamd-Queue-Id: BF09D40014 X-Rspamd-Server: rspam06 X-HE-Tag: 1674747564-223578 X-HE-Meta: U2FsdGVkX18xVo57qQKujKJ03CJJfztEYI5EK8KaoGh2XylG56OqNwFHj7RUJoSXAuTMSrWaT0mpTgFtkZHrsEapFAiOEhx+HBv6N7w50EoED2pE3yPi2/VZ7PD7XnGRwbawLD/Or6Xq5sIxOc+L8/iSCIsuqysvHWn88r6iUYvo9eZMB88HZtGK7mGLxROBVhA9fpZR8zaAOhdQ6lH2uTu8GtlfxcjNjuNJfLKbnFjGvroJRynOh3LFsi2LXSIM6J+1D08GDephYYRF3gpKgiIE1b582QsNVYQEmk/ynjkdsDAOJg+gHeCCB2IaSt0DZKAqd2Vi3U/JqECqE2nDSJoyja22ozYdxqOkZXDOSTthxOVIjKHq3IPEzzoLCH4dzlCu9iIFq0GprUZ+lcHx7EohkvIdCEWKW3gIimfjeu8w/So4WfF0q5TSLjJ7QhgPbcQhDmOSkD+GQt/xeG1q0JIEidDtLDkndkdze1CCJWK3B99hqpjhMiOF3/2T6z7RiFEum7Kfv0uQYKIVdm3wMK/utMXz5wjH+gNXfyTFjJutLSrg4a8FVOYJo+csUPXD5KN+SJL56NiCTWT9t3/LQTqG1VUVpAqq4w2fEpupkwlGjRN5snxhcpPxZlLaxYH6w8ms38tjGRk1M56kB+iOxYaj/kAmW+4pMygRd0CYu7oG3kqCr6c7XECGMczagsqviav6c8TSsZlWbF+Tsv7xzIEOk3yWcvdTVvOYJ7ennM/giHH3fLGwvB2t3VBxqoWQs/5poJNlg5Ftbj9ETuvVf4mwa3RVAqYMtLkLcbSh8+Q8q9EOlvsCxa5xEFxBzadD57llFMGfm1aMQU0C+LaCDxpbc4FEnVrVWMoA13aryqYR5C5YTTsT4p2aKXwX4ZCOiOeBTMktTdvRPuA4mewEFUqtgU4N413wKw6BbIw+yvx2jOVE8Sazm2EF+4NX82VefvIjLCogb8gyvp4/6ni 8JMb5H6r DIKp7My1UKEHi5S/ZY9gZB1uvHevouLjhxV+hTVH+E6ksYSYWatprY3U4qMlRUpPBokFjnMN1AoPj374jupxXMtHPsz0CS2+hFc4k84JM5AT71A0SFVlVav41UuCQgz1IvAp41jwoIcqXYGuZ4SVWdmHKXGEMhvGOf/azyoIqe9lQ+bukn07WTeqVonXkBCEQTBfkM3oU1rzUJ0Y5Fu6gBjRDdgsRwov/FZDvleDc1vKhatPtZ1Y35CD7Kc3+Pe9piqtu 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 Thu, 26 Jan 2023 11:05:27 -0400 Jason Gunthorpe wrote: > On Thu, Jan 26, 2023 at 03:46:09PM +0100, David Hildenbrand wrote: > > On 26.01.23 15:41, Claudio Imbrenda wrote: > > > On Thu, 26 Jan 2023 08:55:27 -0400 > > > Jason Gunthorpe wrote: > > > > > > > On Thu, Jan 26, 2023 at 01:48:46PM +0100, David Hildenbrand wrote: > > > > > On 24.01.23 21:34, Jason Gunthorpe wrote: > > > > > > Move the flags that should not/are not used outside gup.c and related into > > > > > > mm/internal.h to discourage driver abuse. > > > > > > > > > > > > To make this more maintainable going forward compact the two FOLL ranges > > > > > > with new bit numbers from 0 to 11 and 16 to 21, using shifts so it is > > > > > > explict. > > > > > > > > > > > > Switch to an enum so the whole thing is easier to read. > > > > > > > > > > Using a __bitwise type would be even better, but that requires quite some > > > > > adjustments ... > > > > > > > > > > The primary leftover for FOLL_GET seems to be follow_page(). IIRC, there is > > > > > only one caller that doesn't pass FOLL_GET (s390). We could either add a new > > > > > function to "probe" that anything is mapped (IIRC that's the use case), or > > > > > simply ref+unref. > > > > > > > > Is that code even safe as written? I don't really understand how it > > > > > > yes (surprisingly) it is > > > > > > > can safely call lock_page() on something it doesn't have a reference > > > > too ? > > > > > > the code between lock_page and unlock_page will behave "properly" and > > > do nothing or at worst cause a tiny performance issue in the rare case > > > something changes between the follow_page and the page_lock, i.e. if > > > things are done on the wrong page. > > > > What prevents the page from getting unmapped (MADV_DONTNEED), freed, > > reallocated as a larger folio and the unlock_page() would target the wrong > > bit? I think even while freeing a locked page we might run into trouble ... > > Yep. > > The issue is you can't call lock_page() on something you don't have a > ref to. so we have been doing this wrong the whole time? oops > > The worst case would be the memory got unmapped from the VMA and the > entire memory space was hot-unpluged eg it was DAX or something. Now > the page pointer will oops if you call lock_page. we do not have memory mapped devices or anything, so this scenario is highly unlikely (at last this) > > Why not just use the get_locked_pte() exclusively and do -EAGAIN or > -EBUSY if folio_try_lock fails, under the PTL? This already happens > for PageWriteback caes. I think I will need some time to process this sentence I can tell you that the original goal of that function is to make sure that there are no extra references. in particular, we want to prevent I/O of any kind to be ongoing while the page becomes secure. (the I/O will fail and, depending on which device it was, the whole system might end up in a rather unhappy state) transitioning from secure to non-secure instead is much easier > > Jason