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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85B2AC433EF for ; Thu, 9 Sep 2021 09:57:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2513F60F13 for ; Thu, 9 Sep 2021 09:57:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2513F60F13 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9A2C66B0071; Thu, 9 Sep 2021 05:57:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 952BD6B0072; Thu, 9 Sep 2021 05:57:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81A3E6B0073; Thu, 9 Sep 2021 05:57:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 6A0076B0071 for ; Thu, 9 Sep 2021 05:57:04 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DB0F7183E39B3 for ; Thu, 9 Sep 2021 09:57:03 +0000 (UTC) X-FDA: 78567581526.11.E680035 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf03.hostedemail.com (Postfix) with ESMTP id 24A7030000A6 for ; Thu, 9 Sep 2021 09:57:03 +0000 (UTC) Received: by mail-pg1-f171.google.com with SMTP id k24so1235040pgh.8 for ; Thu, 09 Sep 2021 02:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=gzICtbJ4Bh221sUWyjG9nHimvszKfm0/ZRr+c99dKNs=; b=LFTZVq9M9dssSqcTNB/bRAl1ZE3p1kQcbBwy07b5MwKSGwy84mVsQVXXOTQfXzrRVn WFc3k4T93RqY1b0VQ1z48Y8BbsqAbQwyeuGCisNb68rNWbVT3AjIhG0Wdx1zsT1Ky5+B 39c05wPejsShEgJYdk8d38IBIJxiEErb8I2t1gWbwk8XaJ2FrTwNjxraVMv8Mrusnwro vP8MO9sOs0YhArFYgQy655umtmudl9gM8vaMwse3NEbCb492hzA83qW7b24nieBxcL7D llrdoH6XHgajs2rblibS9hiLngS+mpPsXbaUEUM2iNaH33+/FpVjDz8ptUEUM1BAq4Fn s3vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=gzICtbJ4Bh221sUWyjG9nHimvszKfm0/ZRr+c99dKNs=; b=cooZwyzDk/fjyViFO+sj8eSpQ2EPZ/Wl6o39DgHGBqL8wkgcstsw7D7k9i//GiE0+J q0UJDXlLHcZUq/wmhNmDnXSDjWO0qKt9t1RHmkGcQwK+lsUrqeRTO1nWd81HWyA+XhuE +hfI5X03KIeVUETrzOx01MbVBcusGTmOU5PREybBBkTtrHLsUfGlG5ONpo//RdvbQ1E7 t31HyyV4Q+c6KhpRhOeEEb/6jPjo9ZFmogfz4AFMmEQEJRtQgToOls5RRYzEUeC0wmAW +ahMjuiAG9RdD9iFNFl13QHgPsUwOYw8j6XfSnmAW1URk0uSllHEI2E9ItTKaf0tzZC9 +AJA== X-Gm-Message-State: AOAM5307K4f1RV9j8UxU2hqCAqJeEutzy/E9u1w1Yhh0TPfQnF6S7gVZ WiAjoCZUdIuvadkTeChOv3LJ6g== X-Google-Smtp-Source: ABdhPJz5zrrS2Rp9/PxBMwXNMW+WtRdwBHi9Chlh5kwCPpZVE2jjdtMd+GW0KbEgAX/FitI4qv8TEg== X-Received: by 2002:aa7:8106:0:b0:416:143c:44e3 with SMTP id b6-20020aa78106000000b00416143c44e3mr2322380pfi.41.1631181421884; Thu, 09 Sep 2021 02:57:01 -0700 (PDT) Received: from [10.86.116.180] ([139.177.225.230]) by smtp.gmail.com with ESMTPSA id s26sm1680453pfw.5.2021.09.09.02.56.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 02:57:01 -0700 (PDT) Subject: Re: [External] Re: [patch 079/147] fs/proc/kcore.c: add mmap interface To: Linus Torvalds , Andrew Morton Cc: Alexey Dobriyan , chenying.kernel@bytedance.com, Linux-MM , mm-commits@vger.kernel.org, Mike Rapoport , Muchun Song , zhouchengming@bytedance.com, zhengqi.arch@bytedance.com References: <20210907195226.14b1d22a07c085b22968b933@linux-foundation.org> <20210908025730.S88ylmikU%akpm@linux-foundation.org> From: Feng Zhou Message-ID: Date: Thu, 9 Sep 2021 17:56:55 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------23D6341CB5CCC82ED95093BB" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 24A7030000A6 X-Stat-Signature: x38akdx5g1bxye6iq465tg4uyhwnti4q Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=LFTZVq9M; spf=pass (imf03.hostedemail.com: domain of zhoufeng.zf@bytedance.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=zhoufeng.zf@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-HE-Tag: 1631181423-584526 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: This is a multi-part message in MIME format. --------------23D6341CB5CCC82ED95093BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2021/9/9 =E4=B8=8A=E5=8D=882:13, Linus Torvalds =E5=86=99=E9=81= =93: > On Tue, Sep 7, 2021 at 7:57 PM Andrew Morton wrote: >> After looking at the kcore code, it is found that kcore does not imple= ment >> mmap, resulting in frequent context switching triggered by read. >> Therefore, we want to add mmap interface to optimize performance. Sin= ce >> vmalloc and module areas will change with allocation and release, >> consistency cannot be guaranteed, so mmap interface only maps KCORE_TE= XT >> and KCORE_RAM. > Honestly, I still hate this patch. > > The last time people wanted to speed up /dev/kcore accesses, it was > all for black-hat reasons and speeding up kernel attacks. > > And this code just makes me nervous even aside from that, because I do > not understand what the heck it's doing. > > >> + if (kern_addr_valid(start)) { >> + if (m->type =3D=3D KCORE_RAM) >> + pfn =3D __pa(start) >> PAGE_SHIFT; >> + else if (m->type =3D=3D KCORE_TEXT) >> + pfn =3D __pa_symbol(start) >> PAGE_SHIFT; > Why is "__pa(start)" right in one situation, and "__pa_symbol(start)" > in another. Hi, Linus The use here is refer to "read_kcore" in fs/proc/kcore.c. list_for_each_entry(m, &kclist_head, list) { ... if (m->type =3D=3D KCORE_RAM || m->type =3D=3D KCORE_REMAP) phdr->p_paddr =3D __pa(m->addr); else if (m->type =3D=3D KCORE_TEXT) phdr->p_paddr =3D __pa_symbol(m->addr); ... } Ensure consistency of usage. > > So this just makes me go "this is all confusing, dangerous, and the > use-case is dubious". > > Mapping kernel memory is dangerous. The use-cases for it are dubious. > The patch isn't obvious. Kcore mmap kernel memory just has read permission. + if (vma->vm_flags & (VM_WRITE | VM_EXEC)) { + ret =3D -EPERM; + goto out; + } + + vma->vm_flags &=3D ~(VM_MAYWRITE | VM_MAYEXEC); + vma->vm_flags |=3D VM_MIXEDMAP; + vma->vm_ops =3D &kcore_mmap_ops; Compared to the read interface, kcore mmap has no increased risk, just reduce context switching. > > All of that screams "I'll skip this". > > Linus --------------23D6341CB5CCC82ED95093BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2021/9/9 =E4=B8=8A=E5=8D=882= :13, Linus Torvalds =E5=86=99=E9=81=93:
On Tue, Sep 7, 2021 at 7:57 =
PM Andrew Morton <akpm@linux-foundation.org> wrote:

After looking at the kcore code, it is found that kcore does not implemen=
t
mmap, resulting in frequent context switching triggered by read.
Therefore, we want to add mmap interface to optimize performance.  Since
vmalloc and module areas will change with allocation and release,
consistency cannot be guaranteed, so mmap interface only maps KCORE_TEXT
and KCORE_RAM.

Honestly, I still hate this patch.

The last time people wanted to speed up /dev/kcore accesses, it was
all for black-hat reasons and speeding up kernel attacks.

And this code just makes me nervous even aside from that, because I do
not understand what the heck it's doing.



+       if (kern_addr_vali=
d(start)) {
+               if (m->type =3D=3D KCORE_RAM)
+                       pfn =3D __pa(start) >> PAGE_SHIFT;
+               else if (m->type =3D=3D KCORE_TEXT)
+                       pfn =3D __pa_symbol(start) >> PAGE_SHIFT;

Why is "__pa(start)" right in one situation, and "__pa_symbol(start)"
in another.

Hi, Linus

The use here is refer to "read_kcore" in fs/proc/kcore.c.

list_for_each_entry(m, &kclist_head, list) {
...
if (m->type =3D=3D KCORE_RAM || m->type =3D=3D = KCORE_REMAP)
phdr->p_paddr =3D __pa(m->addr);
else if (m->type =3D=3D KCORE_TEXT)
phdr->p_paddr =3D __pa_symbol(m->addr);
...
}

Ensure consistency of usage.



So this just makes me go "this is all confusing, dangerous, and the
use-case is dubious".

Mapping kernel memory is dangerous. The use-cases for it are dubious.
The patch isn't obvious.

Kcore mmap kernel memory just has read permission.

+	if (vma->vm_flags & (=
VM_WRITE | VM_EXEC)) {
+		ret =3D -EPERM;
+		goto out;
+	}
+
+	vma->vm_flags &=3D ~(VM_MAYWRITE | VM_MAYEXEC);
+	vma->vm_flags |=3D VM_MIXEDMAP;
+	vma->vm_ops =3D &kcore_mmap_ops;

Compared to the read interface, kcore mmap has no increased risk, just=20
reduce context switching.



All of that screams "I'll skip this".

           Linus
--------------23D6341CB5CCC82ED95093BB--