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 C476FC2BD09 for ; Fri, 28 Jun 2024 21:19:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36CAB6B0085; Fri, 28 Jun 2024 17:19:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31B8C6B00AB; Fri, 28 Jun 2024 17:19:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E42B6B009F; Fri, 28 Jun 2024 17:19:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 01AA36B00AF for ; Fri, 28 Jun 2024 17:19:41 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A076C120639 for ; Fri, 28 Jun 2024 21:19:41 +0000 (UTC) X-FDA: 82281564162.28.84BD532 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf07.hostedemail.com (Postfix) with ESMTP id CBB714000E for ; Fri, 28 Jun 2024 21:19:39 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FlKfLAtu; spf=pass (imf07.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719609562; 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=Lkns5Z1/d3gxpOrvGYjA3SyIaI/uRmg5Eshm3X9NN5s=; b=IZx2SusZ13AMEPUQW62nhT1FZ8+NLb7GjpMBgTqcovkpVvL+zS4TbvdK5aY/VAYxSbD6Gw 5ewWqmrAZ1BmtLLTZYdrWvB7Zi8Ab3hcpXgXfF9VZvhSQYCjOrpBdfdMb1h+loIdC75PrE 79YWtKmavzJHLJQGUQziqXlZBIylY/Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719609562; a=rsa-sha256; cv=none; b=t+CQYWTd8SutPJEfrFXD7QqBQ1jvXyxwkvJingytc9XmDXw4Q4XNm4SdgpjReQWRH5bXco KJX9LLRjOqU6nxTaEowEzXBFOf7RXIF7ZHuUJt7tgu4/4kJbZjCDaf0hhdJQ9xgHsLvXzh G9gIbDDac6zDjhPdeXYo9puXAeZtFN0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FlKfLAtu; spf=pass (imf07.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-a724a8097deso128166166b.1 for ; Fri, 28 Jun 2024 14:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719609578; x=1720214378; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Lkns5Z1/d3gxpOrvGYjA3SyIaI/uRmg5Eshm3X9NN5s=; b=FlKfLAtuRVDjKhw8CjUEaxD3xtn+WZGc5jvCARQD5jCGnQx2DeBqN7YbZODL6HSlNG Lj5vblk8XrHp3eR8lMta6n4i5E40wxj0sB2hXdZuHisWqf5c0wNLhoCrfDWgGd/ugUMA ow7p2BnyNNJheF364iBYQAH7M9DEFn5D0unNngG1FWfv1WMiEF7E8p0rDRr8luT+dR6D ZmusQ3hmo/+Iqgm0m3pzJgiSELK84tZpzME7/Zfw5WXK4N7Hlw4vcPKC3JkmInqVRqun nsCksiLJvBDUSAH4zMgpcUQCDUp/Xa++DkXbAqdVkDh9ndsQWGvt2EXbWSG1WIJubfSr bzKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719609578; x=1720214378; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Lkns5Z1/d3gxpOrvGYjA3SyIaI/uRmg5Eshm3X9NN5s=; b=G4jaXxyKx8s2A7ZsyrAt9YHtnmiUR14E6BJJaSKiD0Li5x9etUccEZRphlUq+riNUT 05HhONAlFT138ZQc0ELmYOfAOUspE5mLrMsU7RhK1Td+s0LAA+mti1etN2wLuOvy410V A0V2mIGTyyLXnmzkkC43U22BuVl7nky5Ug/l76n0P1Udv3WWfjSGceoiFNKW3NnP2SG9 oM0Dfn4gD5hWh2oWoeGIfftPQ5nYPbn4xPC1tYGJktcthg6aXU61gWLAwoydZMrLf4Ky T+7nGdYgL2goMqV8GXxotBkd4bo0bSqu67TZi3WXKQMuU4KlZd/7vwq7DNPkS6QnX2P6 NQIA== X-Forwarded-Encrypted: i=1; AJvYcCW1GYL5jRB1qBCk34pzKPeDLGCaFu4zRb+3yW79eMg4sFENAWOx0qCnuKkT/ClUeXlJiqdwIt4kfXsjPIkTBeYqxt8= X-Gm-Message-State: AOJu0YwnN5Euri6xo14jp40zKbQIo9L+IbT3O77R/q3g+4psM4zDlxVf k+v/wMoAuLzKnDehQiykkGkrhEwTKNxsqmfBW7fUk1m3RUYplzv3PfSDoG6HWGTcxio2Lzv7EHp 4eyuid9Mk3d3BWOjVBGQghM/DiwY= X-Google-Smtp-Source: AGHT+IFdEwhmzc8q8/7nPHfFlvJYTH2iFU7NzObsErmjGjm4GARuSggLZBbexnoILH9XnrCHqojmAnIyT2nviCcu+9Y= X-Received: by 2002:a17:906:c40a:b0:a71:afc3:5c94 with SMTP id a640c23a62f3a-a7242e146b3mr1094639066b.74.1719609577981; Fri, 28 Jun 2024 14:19:37 -0700 (PDT) MIME-Version: 1.0 References: <1719554518-11006-1-git-send-email-yangge1116@126.com> <20240628134241.53c5f68f936efe0aa8f0b789@linux-foundation.org> In-Reply-To: <20240628134241.53c5f68f936efe0aa8f0b789@linux-foundation.org> From: Yang Shi Date: Fri, 28 Jun 2024 14:19:25 -0700 Message-ID: Subject: Re: [PATCH V2] mm/gup: Fix longterm pin on slow gup regression To: Andrew Morton Cc: yangge1116@126.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, peterx@redhat.com, yang@os.amperecomputing.com, baolin.wang@linux.alibaba.com, liuzixing@hygon.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CBB714000E X-Stat-Signature: n1wprujdjdwrqfxew6xg5z6sc39otyq1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1719609579-124494 X-HE-Meta: U2FsdGVkX18ZqbGg1oZAUcRncoFkPd/Ika7G5rBPYA8K/XPXHpxCG0DvRoMYJILCyLrJLuxLLIn7Bhn9cBm6CE7u6jIYiaFqEA+yu61+vPy9884r3TJo6bwHK0cdqS0o4NCLBnn/DNtm9D91wG/aa53zh6r6nXcUXVx5EBWdkovu2tOFdOqkmKBvLxYulJbryXvtlAZSaCgnk9ADXaUgXasgXrbNAN6sjtWyEaDlkfvui8M3+bGb33kloanMaKwpWVCj13aTIXKciaK0wQ57/gxsO7RHLX6kpG3+rAnMGXyASwuUwWr52pmOkuCgHmIw7XyXQDC8Ea3SJ0FA3QB0ftZ3qg4xCvqM+GBIMtfitgNCpw3Nipg3o20hPvv1w0x4uUjQ+C+A3GSN/UgDkeyJJXvWwO1SvdExkkKQoly6dhf3nt1BeAE872/0nQZWCUMk+x8nHaJfJrL3Zq3vDdyXD9dcJJsHCRh/U2P7GkQjOw/BCheFgbc2sA33pEDuQXyeU/JEIczHupdyZp6rxzXFiTqEQuGWWE2+ma5GnjVxfdZIMR+8rslsCkeUMUeU6U8qs+dHuR3MLcRNhRjUMffIz/hEQC4cthp3iiRYkncgk7wdBYteyh9a3ueFK0iPmhgQkJio2UdSLbx4kzBVzU6vyBucsRfmM35ZAWw2oqZZUGiPtkjp0nRL0/UP8ql13Nvpuo8svSZv+12iP54u/uHdgonNaQDNNnZkyg8UocB68NKP7/yg6V4sNA9mRZ4rUzh7Do+jqjrDPmr3RBQQDDJRmdNFa5SdUDqJOVrJV2a+plGv/JcZ2sczIpHrOp64vWFRMVVgiLdpAjcFfMb6GBzSo/TOL+wzDwA+ZTbJTuH06mljaWdP5hzcvxHZtS9KkJSXdCI0ZYy61MhF2jWo9cnmChUCnKLhLr/lekTe561Lj6gkSuWRGDy4SevWVXtIOCP2xG5pwqFuHc1Sgqvh0rT Cb20N1fb dkspNMzACtUxoTlnUWu7MgK2pgPIVt509LaEWE9npw0weqtDIrELdhi88D0wKrGW0gaK0BUMeWf6JPGbAjMwm4MMDJvboCO4cWz7xbm0jFBN6UtWKvFBY/U+7wecGAgQu5HSOutAN7TbhfkB/Q5IkksFqH5cgtiH/WbFplr32s0oE8d7QvaDST9mkUQnZIMj/Yxqg8oShOSDm6EqlNpxsBaJ1gmcOJHf5+A6MWdQpiLuAqlobgwF8ZVU3btGUkK9jXweQ078AGBkY8socLfllFxGKJ+taN1oLiEPvPQlKIgeDD5RDJui0CsSp+VZh3Fgv/sv5FNkjqAYF/j+rmWdNnnb9prTh3Iifudbeu9PD5xpXXUjUnvASGAxrlgN9mSlTQEzAWIBK7Nm/LA8J/WWtLn7rJeY+A4Sz8pad3UJBB46LyFSG9WOzw9Yjv5AOXpOy0x/rbyKJ8bzemVA3rLZCoi5gscLm+tOVCdEi0YY6EHHjtO7qkmYt2Mmr3Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.003407, 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 Fri, Jun 28, 2024 at 1:42=E2=80=AFPM Andrew Morton wrote: > > On Fri, 28 Jun 2024 14:01:58 +0800 yangge1116@126.com wrote: > > > From: yangge > > > > If a large number of CMA memory are configured in system (for > > example, the CMA memory accounts for 50% of the system memory), > > starting a SEV virtual machine will fail. During starting the SEV > > virtual machine, it will call pin_user_pages_fast(..., FOLL_LONGTERM, > > ...) to pin memory. Normally if a page is present and in CMA area, > > pin_user_pages_fast() will first call __get_user_pages_locked() to > > pin the page in CMA area, and then call > > check_and_migrate_movable_pages() to migrate the page from CMA area > > to non-CMA area. But the current code calling __get_user_pages_locked() > > will fail, because it call try_grab_folio() to pin page in gup slow > > path. > > > > The commit 57edfcfd3419 ("mm/gup: accelerate thp gup even for "pages > > !=3D NULL"") uses try_grab_folio() in gup slow path, which seems to be > > problematic because try_grap_folio() will check if the page can be > > longterm pinned. This check may fail and cause __get_user_pages_lock() > > to fail. However, these checks are not required in gup slow path, > > seems we can use try_grab_page() instead of try_grab_folio(). In > > addition, in the current code, try_grab_page() can only add 1 to the > > page's refcount. We extend this function so that the page's refcount > > can be increased according to the parameters passed in. > > > > The following log reveals it: > > > > [ 464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_p= ages+0x423/0x520 > > [ 464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not taint= ed 6.6.33+ #6 > > [ 464.325477] RIP: 0010:__get_user_pages+0x423/0x520 > > [ 464.325515] Call Trace: > > [ 464.325520] > > [ 464.325523] ? __get_user_pages+0x423/0x520 > > [ 464.325528] ? __warn+0x81/0x130 > > [ 464.325536] ? __get_user_pages+0x423/0x520 > > [ 464.325541] ? report_bug+0x171/0x1a0 > > [ 464.325549] ? handle_bug+0x3c/0x70 > > [ 464.325554] ? exc_invalid_op+0x17/0x70 > > [ 464.325558] ? asm_exc_invalid_op+0x1a/0x20 > > [ 464.325567] ? __get_user_pages+0x423/0x520 > > [ 464.325575] __gup_longterm_locked+0x212/0x7a0 > > [ 464.325583] internal_get_user_pages_fast+0xfb/0x190 > > [ 464.325590] pin_user_pages_fast+0x47/0x60 > > [ 464.325598] sev_pin_memory+0xca/0x170 [kvm_amd] > > [ 464.325616] sev_mem_enc_register_region+0x81/0x130 [kvm_amd] > > > > Well, we also have Yang Shi's patch > (https://lkml.kernel.org/r/20240627231601.1713119-1-yang@os.amperecomputi= ng.com) > which takes a significantly different approach. Which way should we > go? IMO, my patch is more complete, it should be sent to the mainline. This patch can be considered if it is hard to backport my patch to the stable tree. >