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 D9316C0015E for ; Tue, 1 Aug 2023 17:11:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 694EC940030; Tue, 1 Aug 2023 13:11:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6445F940010; Tue, 1 Aug 2023 13:11:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50D6D940030; Tue, 1 Aug 2023 13:11:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 40B5D940010 for ; Tue, 1 Aug 2023 13:11:39 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4B52B80599 for ; Tue, 1 Aug 2023 17:11:37 +0000 (UTC) X-FDA: 81076177434.15.C099183 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf13.hostedemail.com (Postfix) with ESMTP id 2939C26285 for ; Tue, 1 Aug 2023 16:22:07 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="JL8g5/y9"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690906930; 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=Fa14OZp7rZiZDIhBtcOm5m5ittGDpO+zhxFAVaHECE4=; b=egO8g4cs/x9eZkZaeOPTehVyo4BSDF9mssDawSYKuI7goNK7IctYVlxPwf0fFgCLwmAFYV rWmtjV/n0U3miejzrfzNyjZQC9mr3n/CR/h4g/JvVK56mQATnEjw2dhr3X6gA4rFy4QucN WVXrx5h10G77mTjh1bk0TJrTM/ihGQI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="JL8g5/y9"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690906930; a=rsa-sha256; cv=none; b=d5CKTp2rmTpr5kSu9aGrvpHNqbzl0Rt2vz2RJzH58TFcNZpNQ0BiKtA9ReFBk7OV0BaHr/ TCaShmEIF+HcCVY4yxpZ0uY/km8MXP1fEBGd/FeV2e2WvP7leTLtH7CWF69Kn/xbeYOX2p pDg8mQ8KFF2os/0P9YUL0WpNETiDJ/8= Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-4fe10f0f4d1so9667130e87.0 for ; Tue, 01 Aug 2023 09:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690906925; x=1691511725; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Fa14OZp7rZiZDIhBtcOm5m5ittGDpO+zhxFAVaHECE4=; b=JL8g5/y9I33/oNzkxg7EH5w+gbS8zuHQh0tFNNx68xix2ke0VZBiviLz24yO2LISHS VJaPE3Ce7aC2nhdVwj0TWo8q2fif2yqnasPgWLi7Wv+LO9Zh4mypaD8OdtsssIhd42fL FSDLd5wAfpN/i1tOfO9cDw/WQVgTiouUOT9snSH4FTT5f56amqH6hNKyv100D55k3MQN Ba3ugD3nTRX1T7zH1/HEOcUSFG2UQuYXD0QFw0SErirTMZ/jDSxQF+MSxwZevfYmlDdq kT/Lxqk7zZuOVSTcmE0VH95Y1p9kBOL5PqiuaFGHqNcpDD9OKBEHtiGx/CXAYJvgFDoB IMcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690906925; x=1691511725; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Fa14OZp7rZiZDIhBtcOm5m5ittGDpO+zhxFAVaHECE4=; b=bHvAhleAW8c636TRdYgvo+DCaGWjfxPfgnz8YG0nM5suwOq5UMvKjP8BixOmeLxBF0 y/N/7yVjh9pQEnt9qHpaZdHpmmOdwYQf7+uHWXEXZlQSstuey06a4p4A2I9r01N8uwk8 SKBHwXvxOd3Sd06Kv9BOX0HTJPkzf78EfoRFffNXB7qeHG1plzxK/Iox0lgEudiHtDbO 5dDFbOSllN7uv8EU1mNU35xw7TM/32j5Rmtxa5PmvRAP47ZbMrn8hNTqkyt5sYBbk6l0 E7HfGqHhtd04IxjY9BWn7NXfhugG509dG4HoxqolqaT1BAYe2JqijQgdMsTR0v4XEg9R EqTA== X-Gm-Message-State: ABy/qLaY//p/Mvypjy9jx5WUy4+UBmHBJNYKN7xuUwNtoAhDFrb/GtTd THElsSDsa264RCbMDXoivVY= X-Google-Smtp-Source: APBJJlGhQEO6/R7MPu1WrL22wHozLYu83ROCRFN57aZ+fXe/2xgLksa2WKA0jedgldf+ap2UYHbrpA== X-Received: by 2002:a05:6512:32a9:b0:4fd:d18e:be33 with SMTP id q9-20020a05651232a900b004fdd18ebe33mr2306477lfe.26.1690906924415; Tue, 01 Aug 2023 09:22:04 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id n5-20020a7bc5c5000000b003fbe4cecc3bsm17338279wmk.16.2023.08.01.09.22.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Aug 2023 09:22:03 -0700 (PDT) Date: Tue, 1 Aug 2023 17:22:03 +0100 From: Lorenzo Stoakes To: Baoquan He Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Uladzislau Rezki , linux-fsdevel@vger.kernel.org, Jiri Olsa , Will Deacon , Mike Galbraith , Mark Rutland , wangkefeng.wang@huawei.com, catalin.marinas@arm.com, ardb@kernel.org, David Hildenbrand , Linux regression tracking , regressions@lists.linux.dev, Matthew Wilcox , Liu Shixin , Jens Axboe , Alexander Viro , stable@vger.kernel.org Subject: Re: [PATCH] fs/proc/kcore: reinstate bounce buffer for KCORE_TEXT regions Message-ID: <786c095e-abca-4bbf-9d9b-684c40e17e1b@lucifer.local> References: <20230731215021.70911-1-lstoakes@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2939C26285 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 73ram8xw4mnxdz3wudzecyth5azzjwbb X-HE-Tag: 1690906927-960832 X-HE-Meta: U2FsdGVkX1963Dq8mJIdfggInyEGK2zk+WrqlMSh5so8BLF70NnchdVK4yvziOtbdyV0Ym0WpBwb4M/dlyt/S7z9Ovnicjs8B9ShTJOMZbrl2J+btK37r7CiZ1wYGHdoTK9s2r85jFppQw0JtJg4SUcTotyM5qSgnK712TzGEqOpQ6CNUVbfKF4j8NA936Xma8Ex3wWVSnFxfAQbWnKsnnmOfeBUEQTVKrwnmy+0g+FifUhH+XF9kj/5ZbmYpuwWERFSOZ3FdRp5fOAYvFuWbNT072ZcH4vpRtc//Yf2bYN3lsPGv9CrmejaoYfpiLaW9Z/RdIcffOOCFUMcMLRshor6q2QZF/0E9KyIWdwP1OsPaNuin47ohzSlF9iyJKsONC5bYW+JeynLphGapLCoupAfVCQt0WtbEuoSgPHc82j8xLdLTE8sAaw2h5NluthuunNUWR6PCImm9bW4hvUZEjx0Blis9IL7uMtO+fomr5d/MycWNcMcwTz/HPMrOf5ZUmJUwDQLTCjwzGahyYfDTjx9JPCwWUs3PIuzgvWqqiU/A7ac6dWFe85Bjic3I0I9mn943gQ1qUkrTPMAij6d1tT76iluhslIqGZsIdQ1Y4Ddq//aVEMJ/0tC4U/+iAWyvGkujhE5k/AffqgNwUpSzzkTvw2YyvLbTSwvfEzXHX70t9YvumZhfELyWjkWQjlYcE88icfJJbBp3aMJuUrvPB7Mh9np7DE+88kvXGfMvssOsaKcGkzbLCLCUYNZvsdx2RbOY+B22k04mMNqC55NJ3s9Mnma9/MpHPU3uqGFO/zoSoVjIlQ3/fL7/iA/tAmG+tbKZryWs2MKZsVNTpcJ8g2MCETFH8wjBgRRn0C9lQWr2NTjAjoaSuC5eENNnv8hLsYhdFW3zG5Y9P/aM072ctFhp7OJd7bHpgUQ275p94erWsvdEIebjxWMMqod7S77x3CeTI5hVTtZKj+kTsb QnP3hvph U+14UZa+EROrsFiELUi33OBDcKKgVeTa+q059Tw9lADRx2RNnuZ7AkVwX4aFsHWBPR0xrRMg+BIGQjEjJNTfE3TJl+t8H8mViReHPbBvMNRZ9D/k58P8D5ekrqIQOt1b47Oo1gA9MiSO7tXixjdrfh1zx9bqOPjz7imvKtZ4OoCbrAZuxa+5LINtaebA5KvNHCmhKo/5dBvgKzrVBRtl6FmupLPEVhlnQhPcVokUMUwN+voPHSianNQjPKmWfNq1OXCNORrh34haCorCfyWxmrotuem8D+cV7QGog4+oZZPng3LckRtCYQu4znHAbzIDaDxYxNIW1pZq4jlJQXUHb1asw8/gCEoLM0qlpZ1/mZsHztjxuLipmBamRQgyLvaLzvEH+nCG5HLqkWv+kXr0TFJEoAGn7g3gqeII23lF4A2b8rlvZRKFeLxBLtbdWQkF86jW+c/xlhsABqVwSEEBSGTExk2cyCDz7jDuvQYkbapzRfZaLqJ335oweySeFq/urlQFtivWXHprm8oE= 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 Wed, Aug 02, 2023 at 12:01:16AM +0800, Baoquan He wrote: > On 08/01/23 at 11:57pm, Baoquan He wrote: > > On 07/31/23 at 10:50pm, Lorenzo Stoakes wrote: > > > Some architectures do not populate the entire range categorised by > > > KCORE_TEXT, so we must ensure that the kernel address we read from is > > > valid. > > > > > > Unfortunately there is no solution currently available to do so with a > > > purely iterator solution so reinstate the bounce buffer in this instance so > > > we can use copy_from_kernel_nofault() in order to avoid page faults when > > > regions are unmapped. > > > > > > This change partly reverts commit 2e1c0170771e ("fs/proc/kcore: avoid > > > bounce buffer for ktext data"), reinstating the bounce buffer, but adapts > > > the code to continue to use an iterator. > > > > > > Fixes: 2e1c0170771e ("fs/proc/kcore: avoid bounce buffer for ktext data") > > > Reported-by: Jiri Olsa > > > Closes: https://lore.kernel.org/all/ZHc2fm+9daF6cgCE@krava > > > Cc: stable@vger.kernel.org > > > Signed-off-by: Lorenzo Stoakes > > > --- > > > fs/proc/kcore.c | 26 +++++++++++++++++++++++++- > > > 1 file changed, 25 insertions(+), 1 deletion(-) > > > > > > diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c > > > index 9cb32e1a78a0..3bc689038232 100644 > > > --- a/fs/proc/kcore.c > > > +++ b/fs/proc/kcore.c > > > @@ -309,6 +309,8 @@ static void append_kcore_note(char *notes, size_t *i, const char *name, > > > > > > static ssize_t read_kcore_iter(struct kiocb *iocb, struct iov_iter *iter) > > > { > > > + struct file *file = iocb->ki_filp; > > > + char *buf = file->private_data; > > > loff_t *fpos = &iocb->ki_pos; > > > size_t phdrs_offset, notes_offset, data_offset; > > > size_t page_offline_frozen = 1; > > > @@ -554,11 +556,22 @@ static ssize_t read_kcore_iter(struct kiocb *iocb, struct iov_iter *iter) > > > fallthrough; > > > case KCORE_VMEMMAP: > > > case KCORE_TEXT: > > > + /* > > > + * Sadly we must use a bounce buffer here to be able to > > > + * make use of copy_from_kernel_nofault(), as these > > > + * memory regions might not always be mapped on all > > > + * architectures. > > > + */ > > > + if (copy_from_kernel_nofault(buf, (void *)start, tsz)) { > > > + if (iov_iter_zero(tsz, iter) != tsz) { > > > + ret = -EFAULT; > > > + goto out; > > > + } > > > /* > > > * We use _copy_to_iter() to bypass usermode hardening > > > * which would otherwise prevent this operation. > > > */ > > > - if (_copy_to_iter((char *)start, tsz, iter) != tsz) { > > > + } else if (_copy_to_iter(buf, tsz, iter) != tsz) { > > > ret = -EFAULT; > > > goto out; > > > } > > > @@ -595,6 +608,10 @@ static int open_kcore(struct inode *inode, struct file *filp) > > > if (ret) > > > return ret; > > > > > > + filp->private_data = kmalloc(PAGE_SIZE, GFP_KERNEL); > > > + if (!filp->private_data) > > > + return -ENOMEM; > > > + > > > if (kcore_need_update) > > > kcore_update_ram(); > > > if (i_size_read(inode) != proc_root_kcore->size) { > > > @@ -605,9 +622,16 @@ static int open_kcore(struct inode *inode, struct file *filp) > > > return 0; > > > } > > > > > > +static int release_kcore(struct inode *inode, struct file *file) > > > +{ > > > + kfree(file->private_data); > > > + return 0; > > > +} > > > + > > > static const struct proc_ops kcore_proc_ops = { > > > .proc_read_iter = read_kcore_iter, > > > .proc_open = open_kcore, > > > + .proc_release = release_kcore, > > > .proc_lseek = default_llseek, > > > }; > > > > On 6.5-rc4, the failures can be reproduced stably on a arm64 machine. > > With patch applied, both makedumpfile and objdump test cases passed. > > > > And the code change looks good to me, thanks. > > > > Tested-by: Baoquan He > > Reviewed-by: Baoquan He Thanks! > > > > > > =============================================== > > [root@ ~]# makedumpfile --mem-usage /proc/kcore > > The kernel version is not supported. > > The makedumpfile operation may be incomplete. > > > > TYPE PAGES EXCLUDABLE DESCRIPTION > > ---------------------------------------------------------------------- > > ZERO 76234 yes Pages filled with zero > > NON_PRI_CACHE 147613 yes Cache pages without private flag > > PRI_CACHE 3847 yes Cache pages with private flag > > USER 15276 yes User process pages > > FREE 15809884 yes Free pages > > KERN_DATA 459950 no Dumpable kernel data > > > > page size: 4096 > > Total pages on system: 16512804 > > Total size on system: 67636445184 Byte > > > > [root@ ~]# objdump -d --start-address=0x^C > > [root@ ~]# cat /proc/kallsyms | grep ksys_read > > ffffab3be77229d8 T ksys_readahead > > ffffab3be782a700 T ksys_read > > [root@ ~]# objdump -d --start-address=0xffffab3be782a700 --stop-address=0xffffab3be782a710 /proc/kcore > > > > /proc/kcore: file format elf64-littleaarch64 > > > > > > Disassembly of section load1: > > > > ffffab3be782a700 : > > ffffab3be782a700: aa1e03e9 mov x9, x30 > > ffffab3be782a704: d503201f nop > > ffffab3be782a708: d503233f paciasp > > ffffab3be782a70c: a9bc7bfd stp x29, x30, [sp, #-64]! > > objdump: error: /proc/kcore(load2) is too large (0x7bff70000000 bytes) > > objdump: Reading section load2 failed because: memory exhausted > > By the way, I can still see the objdump error saying kcore is too large > as above, at the same time there's console printing as below. Haven't > checked it's objdump's issue or kernel's. > > [ 6631.575800] __vm_enough_memory: pid: 5321, comm: objdump, not enough memory for the allocation > [ 6631.584469] __vm_enough_memory: pid: 5321, comm: objdump, not enough memory for the allocation > Yeah this issue existed before this patch was applied on arm64, apparently an ancient objdump bug according to the other thread [0]. I confirmed it exists on v6.0 kernel for instance. [0]:https://lore.kernel.org/all/7b94619ad89c9e308c7aedef2cacfa10b8666e69.camel@gmx.de/