Message ID | 20230809144600.13721-1-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp2859048vqr; Wed, 9 Aug 2023 08:03:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHXMe+iQMEZMs6/EI9nu7xprppBQ63eDMCXjqJoECzJKb7BO9gybYh2/JELEmRsVI8b+e7U X-Received: by 2002:a2e:95c2:0:b0:2b6:fe3c:c3c1 with SMTP id y2-20020a2e95c2000000b002b6fe3cc3c1mr2007710ljh.4.1691593427299; Wed, 09 Aug 2023 08:03:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691593427; cv=none; d=google.com; s=arc-20160816; b=Ibr3488OXaeK6jKX0P9cQKnrHEMUIjq2TYNwzDAp+U3+Th8TiqdPkO5K4Ct2BIH+CK 8trxssaX15pWtuRSbOORpBLJM+EfocPJluaEboZ4jlgNttvHTh3BGQmXLAezdkfsRQTN EribPU1EirTVwFhFpHGzuQW5z5CK16R1kFt+eMcoaDjXWGA2/NviUwO0aJnBwPg+SDxv IgYjqKQPCP67IprckKUhXB45BtqbYP1+CuecxW94QQEkEaiv3RoargLg+4gIlKhW8k4s Y5vthf6MpFUUjoH1VJo2ONbmRURaElG62ComMx9PM9doyvfqO3cv17WhhzCP+tsocdvt /ImA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=nAOqbS5Qgl4SST4mVTxt2U0LC8XCkPEc99k44uCyOG0=; fh=nP2j7OaEzQjkloWkv3sT4avv8VlBd3KmGiPiz0r18M8=; b=ju6mQ67L29Fb6GNy8m9hJ+n29sk+D+AVvD09tLdpTRo4esjrZSuKRRn9VIu0I/tBV8 3bZ1jiXThJoBnLJo8g3tmHl3WwLd/bYXxmfnpo3TupjIQb2iJgbqcUH3OG8/QCPCd30S sGRgMYFbJseSIIuywgFA2G+ayy19W6olnkfsRB0JdgYew7vZm2vv4JhpCTzXRlxjGBAe Fp+cM9h0ptwCxC+Wk22FWJ5sq6uNJJ18dJbDdpe71DgLUBJaODr2L9wm6Vk2PUXlyQcp 7nfAar2d+/1xv8Os1oy1e4ItIt+2M/SI/TxjcW3GYFrqZkiTHQRClrz80UXCHHiCn1Hf qpdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=BBovHaA8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z20-20020a1709060f1400b00989a806b3fasi3390684eji.1031.2023.08.09.08.03.14; Wed, 09 Aug 2023 08:03:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=BBovHaA8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234063AbjHIOqW (ORCPT <rfc822;craechal@gmail.com> + 99 others); Wed, 9 Aug 2023 10:46:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233427AbjHIOqU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 9 Aug 2023 10:46:20 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00CBE2110; Wed, 9 Aug 2023 07:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691592378; x=1723128378; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=nat6JIpKlbNyaE2SmtvG1qRCszoGjlyVBGDav8zdJFs=; b=BBovHaA8b6u5OGs6B2AXPziLc9QFSB8FJ/iiT9pvhDj7h/gul2Ci2eHg UMAlYjAdULgGJJA4hblimEThnXofy/6hzGv0HL0iOQjTkXjHwd5FKm+14 SuYQCSWLuACCVwNXnj+Rm2FbloTXiXq537Qtr4HX2vqX3M3iyyjzObAF5 ZW4v4rbY1yCTsOarUzMv0FKH5LR3fnVXjc5hmZnwGYppDUcSPw9cLpWxJ xZBsJOCBtdRJXGZpA8klIvEoTqSxHX9rHc8a+fn10cPiSW15pxpEuCQ0O vh4mN04lnclRWPI664VooVKAMGewMaFUynudz7dHNfMWVKnVlGRtQcLy7 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10797"; a="371127925" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="371127925" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 07:46:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10797"; a="905676169" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="905676169" Received: from jmhendri-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.40.58]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 07:46:11 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 8E85310A257; Wed, 9 Aug 2023 17:46:07 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Linus Torvalds <torvalds@linux-foundation.org>, Andrew Morton <akpm@linux-foundation.org>, Dave Hansen <dave.hansen@linux.intel.com> Cc: Kostya Serebryany <kcc@google.com>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, Andrey Konovalov <andreyknvl@gmail.com>, Alexander Potapenko <glider@google.com>, Taras Madan <tarasmadan@google.com>, Dmitry Vyukov <dvyukov@google.com>, Rick Edgecombe <rick.p.edgecombe@intel.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Christina Schimpe <christina.schimpe@intel.com>, stable@vger.kernel.org Subject: [PATCH] mm: Fix access_remote_vm() regression on tagged addresses Date: Wed, 9 Aug 2023 17:46:00 +0300 Message-ID: <20230809144600.13721-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773764269316924166 X-GMAIL-MSGID: 1773764269316924166 |
Series |
mm: Fix access_remote_vm() regression on tagged addresses
|
|
Commit Message
Kirill A. Shutemov
Aug. 9, 2023, 2:46 p.m. UTC
GDB uses /proc/PID/mem to access memory of the target process. GDB
doesn't untag addresses manually, but relies on kernel to do the right
thing.
mem_rw() of procfs uses access_remote_vm() to get data from the target
process. It worked fine until recent changes in __access_remote_vm()
that now checks if there's VMA at target address using raw address.
Untag the address before looking up the VMA.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Christina Schimpe <christina.schimpe@intel.com>
Fixes: eee9c708cc89 ("gup: avoid stack expansion warning for known-good case")
Cc: stable@vger.kernel.org
---
mm/memory.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Wed, 9 Aug 2023 at 07:46, Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote: > > mem_rw() of procfs uses access_remote_vm() to get data from the target > process. It worked fine until recent changes in __access_remote_vm() > that now checks if there's VMA at target address using raw address. > > Untag the address before looking up the VMA. Interesting that it took this long to notice. Not surprising considering that LAM isn't actually available, but I'd have expected the arm people to notice more. Yes, I have (and test) my arm64 laptop, but I obviously don't do user space debugging on it. Apparently others don't either. Or maybe TBI is used a lot less than I thought. Anyway, obviously applied, Linus
> Interesting that it took this long to notice. > > Not surprising considering that LAM isn't actually available, but I'd have > expected the arm people to notice more. Yes, I have (and test) my > arm64 laptop, but I obviously don't do user space debugging on it. > Apparently others don't either. > > Or maybe TBI is used a lot less than I thought. Just for the record: We don't have any LAM support in GDB yet, we are just working on it. We currently rely on that feature, but could still change it. We don't necessarily require /proc/PID/mem to support tagged addresses. ARM's TBI support in GDB does not rely on /proc/PID/mem to support tagged addresses AFAIK. I also thought that the kernel does not support tagged addresses for /proc/PID/mem in case of ARM. This is at least reflected by their patches for TBI and the kernel docs https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt. Christina Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
On Thu, 10 Aug 2023 at 05:42, Schimpe, Christina <christina.schimpe@intel.com> wrote: > > We don't have any LAM support in GDB yet, we are just working on it. > We currently rely on that feature, but could still change it. We don't > necessarily require /proc/PID/mem to support tagged addresses. > > ARM's TBI support in GDB does not rely on /proc/PID/mem to support tagged > addresses AFAIK. Ahh. That would explain why nobody noticed. I do wonder if perhaps /proc/<pid>/mem should just match the real addresses (ie the ones you would see in /proc/<pid>/maps). The main reason GUP does the untagging is that obviously people will pass in their own virtual addresses when doing direct-IO etc. So /proc/<pid>/mem is a bit different. That said, untagging does make some things easier, so I think it's probably the right thing to do. Linus
diff --git a/mm/memory.c b/mm/memory.c index 01f39e8144ef..3be9db30db32 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5701,6 +5701,9 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf, if (mmap_read_lock_killable(mm)) return 0; + /* Untag the address before looking up the VMA */ + addr = untagged_addr_remote(mm, addr); + /* Avoid triggering the temporary warning in __get_user_pages */ if (!vma_lookup(mm, addr) && !expand_stack(mm, addr)) return 0;