Received: by 2002:a17:90a:c8b:0:0:0:0 with SMTP id v11csp2361176pja; Wed, 10 Apr 2019 18:49:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqznK7ShN2j3b7tNWvW6IDt9HF7tUtExy0A8J7Galsm6VVVgGdW1fCwNTCaCR1bsHExFByMo X-Received: by 2002:a62:e710:: with SMTP id s16mr39112132pfh.74.1554947347188; Wed, 10 Apr 2019 18:49:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554947347; cv=none; d=google.com; s=arc-20160816; b=hWRAufZtzsDjOhJCmUMY+XKhvGEez3UmThRuzXOvfcB/8pFB/PcjxDArAZIT+BdiGp c5ROLwCdZR9npwwdlLThak0sLAi6kHcAZeE/+DE4iQ8rvUh0CBjKSfj4tIFz9fYiYS7I 8X1CNx45hu73d9iufMsEQlnRldaz5s5FZomX2E+3O+6+uUdzvCoFe7c9NIyASIVn5Xc0 gcZ3rX35vsy7yeIB8bSl5TMOIhAmqZmSuofH/Ui9wk9AUcc8MgjNp33Ymsr3nrUjlHHm NaULhJWw4AaAkKILqHjImQv7TBwGvIwnBJFvAj4UJUXGn6x8gnZnqbFeGkRVHjmwvb/j vJUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=Y46XHKNhY8a5FCXxTFVeV1vpVkwmX9wKuuZ2wsIsUek=; b=Ahkr/wGAqy2tULan+VY46e7GKCRYO47ZgisCsNn45ms2oWBZmPw4qPF3RTok7MRDV2 qY8gSfthA9dgfmx4UhiknJqhA2YZet7qEy0CAOKFH+N6PZFdeGTTppBrhgRnSfBJJDYo pVdcy/A8w6tZgvI06xeGkHT0+jAiypX1OyZps42pLHrEmk/pkpcFrTTY8+k12jFbsX8U Dh4Jo43nwo7xDS15PsJLi/wmprnJL/ttFhLRj6w8VG81dtjPKL8rb92ibdGKXuugIi+N Fa6tLRGtvD11q1Fqv0FnRg6EEP3/aQe6Yq0RvxuTgElXUutzVAp3N4CJjbuikTsQntSm ERcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=26BUWuVZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v20si33115108pgn.105.2019.04.10.18.48.50; Wed, 10 Apr 2019 18:49:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=26BUWuVZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726672AbfDKBsR (ORCPT + 99 others); Wed, 10 Apr 2019 21:48:17 -0400 Received: from conssluserg-05.nifty.com ([210.131.2.90]:55568 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725981AbfDKBsQ (ORCPT ); Wed, 10 Apr 2019 21:48:16 -0400 Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (authenticated) by conssluserg-05.nifty.com with ESMTP id x3B1m0qu018655; Thu, 11 Apr 2019 10:48:01 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com x3B1m0qu018655 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1554947281; bh=Y46XHKNhY8a5FCXxTFVeV1vpVkwmX9wKuuZ2wsIsUek=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=26BUWuVZZShMtLp2G5sJvtYLVrNGmbDQtlpxB3xu7p/Et4qn8OAx6aAthL+Q4ryuZ wsqy0T0Quq4rEsRDS3rmEZeRnLJIIgbRjJFHemvkUwoM4QjSwAaaO4MJTYinin+JVZ e27/pzuXKUkaG1Z2LaA2rucVKaWBBPSLU5BMLRaG6bfMVYfnYT5IfhbN4yK41czrL0 iVYd3KSC4qP2GG8OK1S28znjdYpjyX9G16hUQMCIu36D1nNQlce7N7ah1SiJ8knCr9 2z/xFnxe326xJyLTM4XW7pwlzq6jLagAkWcvLOHOYV1mnC3wpUfy7kz0rR0CjhI7sC rg+6NiFjXqAEA== X-Nifty-SrcIP: [209.85.217.47] Received: by mail-vs1-f47.google.com with SMTP id d8so2565311vsp.2; Wed, 10 Apr 2019 18:48:00 -0700 (PDT) X-Gm-Message-State: APjAAAWmmlfVXuG7nUAvv02zC+lNZkTU3hE+aba12/ZLLIzllEv7H0Uw trfGak217MiNJuOMRe6ngdQ97lZLOiwKTSaErBo= X-Received: by 2002:a67:818e:: with SMTP id c136mr26287981vsd.65.1554947279787; Wed, 10 Apr 2019 18:47:59 -0700 (PDT) MIME-Version: 1.0 References: <20190408212855.233198-1-joel@joelfernandes.org> In-Reply-To: <20190408212855.233198-1-joel@joelfernandes.org> From: Masahiro Yamada Date: Thu, 11 Apr 2019 10:47:23 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 1/2] Provide in-kernel headers to make extending kernel easier To: "Joel Fernandes (Google)" Cc: Linux Kernel Mailing List , Andrew Morton , Alexei Starovoitov , atish patra , Daniel Colascione , Dan Williams , Dietmar Eggemann , Greg Kroah-Hartman , Guenter Roeck , Jonathan Corbet , Karim Yaghmour , Kees Cook , "Cc: Android Kernel" , "open list:DOCUMENTATION" , "open list:KERNEL SELFTEST FRAMEWORK" , linux-trace-devel@vger.kernel.org, Manoj Rao , Masahiro Yamada , Masami Hiramatsu , Qais Yousef , Randy Dunlap , Steven Rostedt , Shuah Khan , Yonghong Song Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Joel, I have no objection to this patch. I checked though it once again, please let me point out a little more. They are all nits. On Tue, Apr 9, 2019 at 6:37 AM Joel Fernandes (Google) wrote: > > Introduce in-kernel headers which are made available as an archive > through proc (/proc/kheaders.tar.xz file). This archive makes it > possible to run eBPF and other tracing programs tracing programs that Just one "tracing programs" is enough. > need to extend the kernel for tracing purposes without any dependency on > the file system having headers. > > On Android and embedded systems, it is common to switch kernels but not > have kernel headers available on the file system. Further once a > different kernel is booted, any headers stored on the file system will > no longer be useful. By storing the headers as a compressed archive > within the kernel, we can avoid these issues that have been a hindrance > for a long time. > > The best way to use this feature is by building it in. Several users > have a need for this, when they switch debug kernels, they donot want to 'donot' -> 'do not' ? > update the filesystem or worry about it where to store the headers on > it. However, the feature is also buildable as a module in case the user > desires it not being part of the kernel image. This makes it possible to > load and unload the headers from memory on demand. A tracing program, or > a kernel module builder can load the module, do its operations, and then > unload the module to save kernel memory. The total memory needed is 3.8MB. > > By having the archive available at a fixed location independent of > filesystem dependencies and conventions, all debugging tools can > directly refer to the fixed location for the archive, without concerning > with where the headers on a typical filesystem which significantly > simplifies tooling that needs kernel headers. > > The code to read the headers is based on /proc/config.gz code and uses > the same technique to embed the headers. > > IKHD_ST and IKHD_ED markers as is to facilitate future patches that > would extract the headers from a kernel or module image. > > Signed-off-by: Joel Fernandes (Google) [snip] > > diff --git a/init/Kconfig b/init/Kconfig > index 4592bf7997c0..ea75bfbf7dfa 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -580,6 +580,17 @@ config IKCONFIG_PROC > This option enables access to the kernel configuration file > through /proc/config.gz. > > +config IKHEADERS_PROC > + tristate "Enable kernel header artifacts through /proc/kheaders.tar.xz" > + depends on PROC_FS > + help > + This option enables access to the kernel header and other artifacts that This line is indented by a TAB, which is correct. > + are generated during the build process. These can be used to build kernel > + modules or by other in-kernel programs such as those generated by eBPF Now that you have dropped the ability to "build kernel modules", I'd like you to update this help message. > + and systemtap tools. If you build the headers as a module, a module > + called kheaders.ko is built which can be loaded on-demand to get access > + to the headers. These lines are indented by 8-spaces instead of one TAB. Please use TAB-indentation consistently. [snip] > +rm -rf $cpio_dir > +mkdir $cpio_dir > + > +pushd $kroot > /dev/null > +for f in $src_file_list; > + do find "$f" ! -name "*.cmd" ! -name ".*"; > +done | cpio --quiet -pd $cpio_dir > +popd > /dev/null > + > +# The second CPIO can complain if files already exist which can > +# happen with out of tree builds. Just silence CPIO for now. > +for f in $obj_file_list; > + do find "$f" ! -name "*.cmd" ! -name ".*"; > +done | cpio --quiet -pd $cpio_dir >/dev/null 2>&1 > + Could you add a simple comment about what the following code is doing? "Remove comments except SPDX" etc. > +find $cpio_dir -type f -print0 | Please replace two spaces after 'find' with one. > + xargs -0 -P8 -n1 perl -pi -e 'BEGIN {undef $/;}; s/\/\*((?!SPDX).)*?\*\///smg;' > + > +tar -Jcf $tarfile -C $cpio_dir/ . > /dev/null > + > +echo "$src_files_md5" > kernel/kheaders.md5 > +echo "$obj_files_md5" >> kernel/kheaders.md5 > +echo "$(md5sum $tarfile | cut -d ' ' -f1)" >> kernel/kheaders.md5 > + > +rm -rf $cpio_dir > diff --git a/kernel/kheaders.c b/kernel/kheaders.c > new file mode 100644 > index 000000000000..d072a958a8f1 > --- /dev/null > +++ b/kernel/kheaders.c > @@ -0,0 +1,73 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * kernel/kheaders.c > + * Provide headers and artifacts needed to build kernel modules. Ditto. Could you update this comment ? > + * (Borrowed code from kernel/configs.c) > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +/* > + * Define kernel_headers_data and kernel_headers_data_end, within which the the > + * compressed kernel headers are stpred. The file is first compressed with xz. > + */ > + > +asm ( > +" .pushsection .rodata, \"a\" \n" > +" .global kernel_headers_data \n" > +"kernel_headers_data: \n" > +" .incbin \"kernel/kheaders_data.tar.xz\" \n" > +" .global kernel_headers_data_end \n" > +"kernel_headers_data_end: \n" > +" .popsection \n" > +); You mentioned "IKHD_ST and IKHD_ED markers..." in the commit description, but I do not see them in the code. If you plan to work on a tool to extract the headers, I think it is OK to have the markers here. Anyway, please make the code and the commit-log consistent. > + > +extern char kernel_headers_data; > +extern char kernel_headers_data_end; > + > +static ssize_t > +ikheaders_read_current(struct file *file, char __user *buf, Could you stretch this line ? It will still fit in 80-cols. (This is a coding style error in kernel/configs.c) Last thing, when CONFIG_IKHEADERS_PROC=y, I always see: GEN kernel/kheaders_data.tar.xz which I think misleading because the script is just checking the md5sum. What I like to see is: CHK kernel/kheaders_data.tar.xz for checking md5sum. And, GEN kernel/kheaders_data.tar.xz for really (re-)generating the tarball. How about this code? index e3c581d8cde7..12399614c350 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -125,7 +125,7 @@ $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE $(obj)/kheaders.o: $(obj)/kheaders_data.tar.xz -quiet_cmd_genikh = GEN $(obj)/kheaders_data.tar.xz +quiet_cmd_genikh = CHK $(obj)/kheaders_data.tar.xz cmd_genikh = $(srctree)/kernel/gen_ikh_data.sh $@ $(obj)/kheaders_data.tar.xz: FORCE $(call cmd,genikh) diff --git a/kernel/gen_ikh_data.sh b/kernel/gen_ikh_data.sh index ef72c2740d01..613960e18691 100755 --- a/kernel/gen_ikh_data.sh +++ b/kernel/gen_ikh_data.sh @@ -57,6 +57,10 @@ if [ -f kernel/kheaders.md5 ] && exit fi +if [ "${quiet}" != "silent_" ]; then + echo " GEN $tarfile" +fi + rm -rf $cpio_dir mkdir $cpio_dir Thanks. -- Best Regards Masahiro Yamada