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 C1C8EC7EE2E for ; Fri, 9 Jun 2023 15:06:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2BDE6B0072; Fri, 9 Jun 2023 11:06:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB4AF6B0074; Fri, 9 Jun 2023 11:06:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C55A06B0075; Fri, 9 Jun 2023 11:06:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B4F826B0072 for ; Fri, 9 Jun 2023 11:06:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 22A59C01AC for ; Fri, 9 Jun 2023 15:06:29 +0000 (UTC) X-FDA: 80883535698.15.DB0601D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 9A63614014B for ; Fri, 9 Jun 2023 15:05:16 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IUxZfN5F; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686323116; a=rsa-sha256; cv=none; b=OdCGJjRyaEhnAyT8161d4pf7lQCfdvJbYjh2GEaH1U5tbaBM0jAT9sKFn4osg57vLclGqU e7EmumJ0ARJvPRkpzP/HVZA1fKXOnl1P9a8QzjfSgu+NOc6l33LN9yzh+HBu2lYJETQyE4 Vj/ZBMp49Z6/vxG1tVGgUdbtHeZwbCY= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IUxZfN5F; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686323116; 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=coXBP4uiCO1t+RzMycgDz8wHMOO+2BU24l9WVlszhmU=; b=SRQMEp6FsR0yD/DG7UWcXWExHmBNeH2bGPXpS10EwlFwD2qzywkaXBbS0H5Z7+ZPJ/6ce+ nVsoXxARSm1y/I3UmUhiLNy+H6XQUq4xYOpHBTczWH5IO1NZqPXB0yenZ5YJtqelgcudng ffSXvfyOs4QoE3IoE32RpQbjexcedK4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=coXBP4uiCO1t+RzMycgDz8wHMOO+2BU24l9WVlszhmU=; b=IUxZfN5FC1LT0jIoP/+NLUicEc /pud5dqcB2gCRR1QrRAMe3A8L6Gnl4STN4rJTDvsfxQoL+lMC7CFNghTexSUPXvMgenH0eBswBqcz p9PZo7KLHlJcUr/lRz21PVbCHgievGbtLp30vHD8mrPrm5jjzv7ujNoQetSrc0xu8kt+km9MEoA3z FQjHACnI/1q9TjbkmViLNlHzrDmzCDyKrTkmRxlUnB9hFBwHpKsG4uhXPEsKcgTkdpVAPdDq6BWde bQDH1/92Lq/SDT0ssqRgV8qNIdsQi0EOnSrSBnSZlhNxryba8njrnDQu+f2qQB8CRunapTSnO2XMg 8XxZ3ZIw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1q7de7-00GhRR-CC; Fri, 09 Jun 2023 15:03:23 +0000 Date: Fri, 9 Jun 2023 16:03:23 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, mhocko@suse.com, josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, michel@lespinasse.org, liam.howlett@oracle.com, jglisse@google.com, vbabka@suse.cz, minchan@google.com, dave@stgolabs.net, punit.agrawal@bytedance.com, lstoakes@gmail.com, hdanton@sina.com, apopple@nvidia.com, peterx@redhat.com, ying.huang@intel.com, david@redhat.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v2 5/6] mm: implement folio wait under VMA lock Message-ID: References: <20230609005158.2421285-1-surenb@google.com> <20230609005158.2421285-6-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230609005158.2421285-6-surenb@google.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9A63614014B X-Stat-Signature: y4ufujws9xnqnptr9sjhshumrodg3ghk X-HE-Tag: 1686323116-691399 X-HE-Meta: U2FsdGVkX18+dX7lQo7R0P7PeVBW0XvzjZoFyv8Mro1o3oGJzQImped+UoCdJzQBP4TQ7OTrIF/wWOGtaZrDNscK+36V9Ww2JTOL0A8aObWtwW9bQUc7rzBpxNxOZp+qMmi9VOKY4gKkW53as5rwPrYouyBiAcHHdClWYAzbW4GOjuolPhQ6zfOYhw1Z09sag5+wVmIaB3pWLZQyFefdzkAePxIhS1EWUjLaxZa+PiR+zu+4IQG9aRnAvlefdGJfeJWA4XLtVMoZZ7vnNpYiz3zpf78/+fhMlWSu/9TVzToLEmfvYSs782eUL8x38S19kIX9Cva6mvV5nzpSNRYKfuOoJZKcZcsm6WR3EQvxAIMQRae5wPI9L9PrEVme+ZDjoo5L48MX5QTuRbRHmPAi2FZIDWOGeJTQxIsybzfo+/sb7vZj39Yb52dnEPYrCLTLY3TsbGcDYabfnI3bR0SXm/5WeKswA3a2mOtk2oujg/gb2aJiE5qRDhys9a0Ii3+cWgnl776apSMQaBe/ALXWuoi8/vm/XZNkfiSSuqpi5WwJSVZOLXRICkJxSq0AWCaCfEi7P818tuXlxCZWeszypOBp2Fn2czajpT3u0YrIKkd1BnIt8QYrctISRQvzJis5IBWkOomxcoNBjEXxxPaMVsICs/pT+cqyg/XnTnBHYIRWiUeKqMJdKcqYD3RUNp7NjulJt7L3NiK59rAdJe57PJmKH6rSo9GesqkYA3fogAWUrE3G5CzRrHtKtZ3WMAhT6/rwllJa7E/wS6wPyX3OBT1AqHpBoxLkh2b3mv1CBNLkFa1ppTqNjxgNIWPEGluQRwbRgx9S8C3wJZ1zmaITC5zn/knG+JwfyM34BXjqBHnGqA6haF3xlDKMg3+ndoDB8zseYF2mW5UvwsXQMoQwyIjQipjNpSpi6KSSgucfbRnIFXzlZeHGUHPhEX0T4pi1U+NufAc5UOiKaCvKK5T tFoIFKyz xb/EwCGS1qaaiGT9Nsmm8KJaNs1WBqwHypXdExT3nzHiydKFCd9HA+Eab165EHlOkrM2fN2hdbwM2ZJnB+uPnrxcR0n/OJ8vUS/s1qOm5UQdN6IMGL2522Sw/zt936RMl8VqmEeBMYc0LDYM= 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, Jun 08, 2023 at 05:51:57PM -0700, Suren Baghdasaryan wrote: > static inline bool folio_lock_or_retry(struct folio *folio, > - struct mm_struct *mm, unsigned int flags) > + struct vm_area_struct *vma, unsigned int flags, > + bool *lock_dropped) I hate these double-return-value functions. How about this for an API: vm_fault_t folio_lock_fault(struct folio *folio, struct vm_fault *vmf) { might_sleep(); if (folio_trylock(folio)) return 0; return __folio_lock_fault(folio, vmf); } Then the users look like ... > @@ -3580,8 +3581,10 @@ static vm_fault_t remove_device_exclusive_entry(struct vm_fault *vmf) > if (!folio_try_get(folio)) > return 0; > > - if (!folio_lock_or_retry(folio, vma->vm_mm, vmf->flags)) { > + if (!folio_lock_or_retry(folio, vma, vmf->flags, &lock_dropped)) { > folio_put(folio); > + if (lock_dropped && vmf->flags & FAULT_FLAG_VMA_LOCK) > + return VM_FAULT_VMA_UNLOCKED | VM_FAULT_RETRY; > return VM_FAULT_RETRY; > } ret = folio_lock_fault(folio, vmf); if (ret) return ret; > @@ -3837,9 +3840,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > goto out_release; > } > > - locked = folio_lock_or_retry(folio, vma->vm_mm, vmf->flags); > - > - if (!locked) { > + if (!folio_lock_or_retry(folio, vma, vmf->flags, &lock_dropped)) { > + if (lock_dropped && vmf->flags & FAULT_FLAG_VMA_LOCK) > + ret |= VM_FAULT_VMA_UNLOCKED; > ret |= VM_FAULT_RETRY; > goto out_release; > } ret |= folio_lock_fault(folio, vmf); if (ret & VM_FAULT_RETRY) goto out_release; ie instead of trying to reconstruct what __folio_lock_fault() did from its outputs, we just let folio_lock_fault() tell us what it did.