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 6DCE8C2BBCA for ; Fri, 28 Jun 2024 06:09:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C99CE6B0092; Fri, 28 Jun 2024 02:09:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C49E16B0095; Fri, 28 Jun 2024 02:09:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1B586B0096; Fri, 28 Jun 2024 02:09:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9133F6B0092 for ; Fri, 28 Jun 2024 02:09:22 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 119311A031C for ; Fri, 28 Jun 2024 06:09:22 +0000 (UTC) X-FDA: 82279270164.05.9470EEF Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.9]) by imf07.hostedemail.com (Postfix) with ESMTP id DB19E4000E for ; Fri, 28 Jun 2024 06:09:18 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b="ZyHZqk/X"; spf=pass (imf07.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.9 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719554950; 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=9aswm6DR5ZbqBHIZa9TUwuJYXCs6Tm8kQTWEVNsvtH8=; b=ME7VG3Oy7q7OPwmok0e63iqbbDDQ+e9kQi2QEYK5gXJ+kZLMsjnduQJP4eik8Hdl0a8Jg8 P8OritXaYz2Sdq1zj/7AwLWyvyjzzyFk1s6x/cGOYyTMdGoA5oSedt26ChO/MRZkZozc0L q2RsjzpBZNyxrFghMJ2/0v/6+LlmVbI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b="ZyHZqk/X"; spf=pass (imf07.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.9 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719554950; a=rsa-sha256; cv=none; b=XhAVg0QKOy3RiQeqxIOiXuUp+3eRJtOOj4uCAqLT7CM5Xd57UOyf4h/216DaGI42zl9FtN dx/1MNPzpGoSUp2Kfg0OxOIQpJkx2SbdgbaHnwgLuKHmCdwGI+T9RybtJZ+1RIB+jstAtt 5icjZxytss2rj3ebX4uGcYj2HF9QKas= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:From: Content-Type; bh=9aswm6DR5ZbqBHIZa9TUwuJYXCs6Tm8kQTWEVNsvtH8=; b=ZyHZqk/Xz0Y139JAhp1FZTEmo5h+MvrhEpkMqvZAexx53VWQ+zkRm9V4KB7Vpw 5aiYCMZlybffIQuP+1kohv7DGK6/J9dV9Yx66+UZyqMs3g7+y9D8y35aUsZ00Zpd Au5CqSOcKDeHCpD6xWyh4PLghe1X2vVfuscRZ4NhWUkg4= Received: from [172.21.22.210] (unknown [118.242.3.34]) by gzga-smtp-mta-g0-0 (Coremail) with SMTP id _____wD3X+WJU35m7w_JAA--.17284S2; Fri, 28 Jun 2024 14:09:13 +0800 (CST) Message-ID: <3a2dee50-ca5d-423c-bbf0-5dae8fbb62e3@126.com> Date: Fri, 28 Jun 2024 14:09:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v2 PATCH] mm: gup: do not call try_grab_folio() in slow path To: Peter Xu , Andrew Morton Cc: Yang Shi , david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20240627221413.671680-1-yang@os.amperecomputing.com> <20240627163242.39b0a716bd950a895c032136@linux-foundation.org> From: Ge Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wD3X+WJU35m7w_JAA--.17284S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxZFW5CF48Cw13Ar48Gr1UGFg_yoW5Xr18pF y3Ka9xKFWkJr10kws7twn5ZFWFyrZ8JryUXws5Gr1fZa98ua4xWr48X34FkF98W348Ga10 vFW2y3srXa1DAa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jtSdkUUUUU= X-Originating-IP: [118.242.3.34] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbiWQwMG2VLbBlTrAAAsm X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: DB19E4000E X-Stat-Signature: jp6e699p9chymn1ccwkwc51t6ukjee8x X-Rspam-User: X-HE-Tag: 1719554958-13485 X-HE-Meta: U2FsdGVkX180+ytCz4gAhx6ykkWWSiEDPM5jH81uYljPwdjMLN18ZDZhel0odML8yZ2A7XFeNo7Q10s2Ll1gJsQdO5Lxp/dd+t0LFYFgIiYCCMosXD7mD4rF98J4VItXs+Sh6SNaDhSDsJvNvPgWVqhkctLxqTWGgToEGg8GTB5zwKZe7TErB53doZw0F3SMdyDnqYLxjrJ5RRb7GCffQgZFiCoWdTi5/nUzSgETzBg+xqGnYFqLCFIFCOeFvXC8chiqJjjU76xXPMhsySFTz1PHADY9sZyONjeEoPnUYDWH2b4THYvrXaYsAIjT386GC76Nx1J00wvmTahWPhti/CsNh67oBQLrHKnc3/3NDudDjibret864BxAE2RZ3xs7n9oJnMmFEsgLSr342qQnuOVBZjq74obqku2v/teNVIgUG7cgU1v5Z/pISeNo8KwF7Fr57bXkrerCC5Og3Kv/kJ4B6yuspHKd9FBAFY3CVb9/XyGw+UfvkG4zBI4J4W1edZuhFSbPbAA6Dkrac6sS5Y6GydnsgYv1vMyKX0zkixgeR325+5mJAaFZ50a0Zr2gJlxPa8ehiZXnF9fywRPWkendjFtOQPzc8DprQP32EvLrJhsutxW5QUBc2gMTGnaY0Ke4jLV/cX239a9lYsDVkVpGU3gIwbM7TxLxIB9lF2zeOsUyY+QpPvM9pVm3R/kseGwHTHuMTnkHLrFms2AcCmwt2VSldh3VQFrapSyFrG1jBZnhC32pMOXTLdaJtO3TMKji7cz2NRjepfRl2A5su1qtttsCr+xK4hfEYKGw1T30SaruNAYN/55kL0fm98G8KyX5tl3Zaa2uIHK2NGbf70zB8zkON28qhl0ldc5QM4i+4hnVlB9fNC57VfEKqljwdZ+GV6MsMmXbmcaJfJGy1MZqzS/oiaAxqf7QF5eabijI2Z/6CocHePh42Vl/a6g4ZoYo0BMUQH5PrD369iS riiKmAPc 8B3RRXljQoX0Np27mil0tGJM8dkRg5mIB/bXPZ+yUNttryzHxFH5zfYtk7Ee5sXVDFSKsYb1+Gd++P0nVpprKOXqQXqaA9CTO/mYaSgfPgxgaxc2wGZeH8efuUV/RGqclKMm6Fuy5f6s1Mf64DgBMK3B+54xhXrOofzjHsYDrh5NnrQgp56S9UpDMEYrp7v4ngyXo3Jg1nDBzpymUSlIvxemVJC+6Odzdn9vDpYfaxejEBnJoxc2M7nP334l17i/S3YqCAHYHAX8r2az0nZXDb57HpqfLs35sT4goZNiWmK0mGt4FK2p3DAfCVjE79M686+UICQiluSIJmcA+BoALghLRldwGG50qfd29zAfx4M5WhgsPCDODoCy9uxOdT+KG3yjN8ApZeLZjwy2UdtAGtbqjoBtbs7cH7A5dcLRXPLcA31wjNTRTuTuR6Ep1E1c4NVK9fQxaBuSU3LrtRyG1g3TigdZVFNG4sDGSSMjk8NY3JMDCLkwgEPnbqxZUfCucKzHOy6jIYwofIlydDXU7Occxom9IyJiev1OGWrPlWcxog1e+drIsAP0s5YCWq8sZR28XCDqp4wd0EHK5yF6YSoW97Gt/vvmPd4BBHAz8J4lsFmA= 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: 在 2024/6/28 7:43, Peter Xu 写道: > On Thu, Jun 27, 2024 at 04:32:42PM -0700, Andrew Morton wrote: >> On Thu, 27 Jun 2024 19:19:40 -0400 Peter Xu wrote: >> >>> Yang, >>> >>> On Thu, Jun 27, 2024 at 03:14:13PM -0700, Yang Shi wrote: >>>> The try_grab_folio() is supposed to be used in fast path and it elevates >>>> folio refcount by using add ref unless zero. We are guaranteed to have >>>> at least one stable reference in slow path, so the simple atomic add >>>> could be used. The performance difference should be trivial, but the >>>> misuse may be confusing and misleading. >>> >>> This first paragraph is IMHO misleading itself.. >>> >>> I think we should mention upfront the important bit, on the user impact. >>> >>> Here IMO the user impact should be: Linux may fail longterm pin in some >>> releavnt paths when applied over CMA reserved blocks. And if to extend a >>> bit, that include not only slow-gup but also the new memfd pinning, because >>> both of them used try_grab_folio() which used to be only for fast-gup. >> >> It's still unclear how users will be affected. What do the *users* >> see? If it's a slight slowdown, do we need to backport this at all? > > The user will see the pin fails, for gpu-slow it further triggers the WARN > right below that failure (as in the original report): > > folio = try_grab_folio(page, page_increm - 1, > foll_flags); > if (WARN_ON_ONCE(!folio)) { <------------------------ here > /* > * Release the 1st page ref if the > * folio is problematic, fail hard. > */ > gup_put_folio(page_folio(page), 1, > foll_flags); > ret = -EFAULT; > goto out; > } > > For memfd pin and hugepd paths, they should just observe GUP failure on > those longterm pins, and it'll be the caller context to decide what user > can see, I think. > >> >>> >>> The patch itself looks mostly ok to me. >>> >>> There's still some "cleanup" part mangled together, e.g., the real meat >>> should be avoiding the folio_is_longterm_pinnable() check in relevant >>> paths. The rest (e.g. switch slow-gup / memfd pin to use folio_ref_add() >>> not try_get_folio(), and renames) could be good cleanups. >>> >>> So a smaller fix might be doable, but again I don't have a strong opinion >>> here. >> >> The smaller the better for backporting, of course. > > I think a smaller version might be yangge's patch, plus Yang's hugepd > "fast" parameter for the hugepd stack, then hugepd can also use > try_grab_page(). memfd-pin change can be a separate small patch perhaps > squashed. Thanks, new version: https://lore.kernel.org/all/1719554518-11006-1-git-send-email-yangge1116@126.com/ > > I'll leave how to move on to Yang. > > Thanks, >