Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp5976269rwb; Tue, 1 Aug 2023 10:22:53 -0700 (PDT) X-Google-Smtp-Source: APBJJlE/jRpyjnUbVgZb02rNxpiH44w2fTMNrfMh+DF2HiC6Oo1zPcqD1l06Gw0B9gYrhVus44oF X-Received: by 2002:a05:6870:568e:b0:1bb:b172:4bd5 with SMTP id p14-20020a056870568e00b001bbb1724bd5mr13614094oao.18.1690910572832; Tue, 01 Aug 2023 10:22:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690910572; cv=none; d=google.com; s=arc-20160816; b=iz71z3s5jWnjYwoKGVlC/T56idbqkxDLkeq4/5NW58Z01qyqVKOgiPN3Ob/tMdBOi1 SSv26RENQOdRWq8ZFGv7ahe7RbivZvk/Jdi6M7DDh3FHEHgehEjr5FWSN0Ude+H/HNd2 x8i5sDlx54h+2upQBi9YpgbkJp9LLgcvsz/X2zKsqfKYnofaYiS0c2WVJUZataW36mXT VYqQ4G3XRv4hmkvBWHYldegjF+1cinpq+0UhbdoFvn+SrjrJD7eZ0h57P4v6UnxBDWh2 ukaLE1000j8doeOHj9bl81oE0rS4/Ca6iWnctA8yE3hYjFpdcBmh/CJJcWGsIGkrm9JS 6Djg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=v1Xszfz9uEDrPkkvCMGSkEQEMthpp9oBlq/CbCyVYks=; fh=mTD6YU05egoDR+wv/1RI5GJjgHJ0JxYeopBYA6liSTg=; b=LbGZe0JQs9EQi94N5iwbSid8Xqmu/trhRueE01S0wR6EviRERTTDM0b1tWoP/1Nq+u Qz7AFEaFefYnsfxGuZOlrIo53AOF5pX9NSCvr5dFK4z65xHZaeQCz2melzdzzPAEF4yS TtmqlubgDfYu3ZGFW5sctvxcAeCEgA/TYMTCtNE813Yx+3LJskmxSDG6VUKM93a6aoOI uv9TUP3hv+7XdqDwQw+EzWocv2LTR3AqpjJbkXpDKlvbGFiENFFVmyfp1RL3cAnaLmVl puHWW2Nk3ZM/GhpHLlaqHIrsbTYIH6pm+GQ1wakJBFTjJ9tEYy1Ei5zMsSf8VeKm/cb/ N75A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=i7KMon5Q; 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=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h70-20020a638349000000b0055117ae3878si9314552pge.324.2023.08.01.10.22.40; Tue, 01 Aug 2023 10:22:52 -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=@redhat.com header.s=mimecast20190719 header.b=i7KMon5Q; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234144AbjHAP7N (ORCPT + 99 others); Tue, 1 Aug 2023 11:59:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233865AbjHAP7I (ORCPT ); Tue, 1 Aug 2023 11:59:08 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41164268E for ; Tue, 1 Aug 2023 08:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690905497; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v1Xszfz9uEDrPkkvCMGSkEQEMthpp9oBlq/CbCyVYks=; b=i7KMon5QB9WWZiFZidfpaG6DhicU00itLoLqA8zPtLfKA8DBkwON9SXLxdoVEiAXcevdYg JkaW85sTnRGh3yyXqMBw7AsGlfILkyeGUnbu4us8n8Yx0IlQ9Xa57RT6SGDQVarSBt0ezt W5yjIQOr/RGS7m126Tc+17U0cDD0HHY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-445-x24qKZ6FPHuvf70ETQoxQA-1; Tue, 01 Aug 2023 11:58:12 -0400 X-MC-Unique: x24qKZ6FPHuvf70ETQoxQA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 319E4185A791; Tue, 1 Aug 2023 15:58:11 +0000 (UTC) Received: from localhost (unknown [10.72.112.107]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 993E42166B25; Tue, 1 Aug 2023 15:57:51 +0000 (UTC) Date: Tue, 1 Aug 2023 23:57:48 +0800 From: Baoquan He To: Lorenzo Stoakes 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: References: <20230731215021.70911-1-lstoakes@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230731215021.70911-1-lstoakes@gmail.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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: X-Mailing-List: linux-kernel@vger.kernel.org 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 =============================================== [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