archive mirror
 help / color / mirror / Atom feed
From: Greg KH <>
To: "Joel Fernandes (Google)" <>
	Masahiro Yamada <>,
	Andrew Morton <>,,,,
	Dan Williams <>,, Guenter Roeck <>,
	Jonathan Corbet <>,, Kees Cook <>,,,,,
	Manoj Rao <>,,,,, Shuah Khan <>,
Subject: Re: [PATCH v7 resend 1/2] Provide in-kernel headers to make extending kernel easier
Date: Sat, 27 Apr 2019 15:38:44 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Apr 26, 2019 at 03:04:29PM -0400, 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 that need to extend the
> kernel for tracing purposes without any dependency on the file system
> having headers.
> A github PR is sent for the corresponding BCC patch at:
> 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. This is an issue even well known to distros.
> 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 do not want to
> 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 can
> load the module, do its operations, and then unload the module to save
> kernel memory. The total memory needed is 3.3MB.
> 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.
> Other approaches were discussed such as having an in-memory mountable
> filesystem, but that has drawbacks such as requiring an in-kernel xz
> decompressor which we don't have today, and requiring usage of 42 MB of
> kernel memory to host the decompressed headers at anytime. Also this
> approach is simpler than such approaches.
> Reviewed-by: Masahiro Yamada <>
> Signed-off-by: Joel Fernandes (Google) <>

Reviewed-by: Greg Kroah-Hartman <>

  parent reply	other threads:[~2019-04-27 13:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26 19:04 Joel Fernandes (Google)
2019-04-26 19:04 ` [PATCH v7 resend 2/2] init/config: Do not select BUILD_BIN2C for IKCONFIG Joel Fernandes (Google)
2019-04-27 13:38 ` Greg KH [this message]
2019-04-29 13:26   ` [PATCH v7 resend 1/2] Provide in-kernel headers to make extending kernel easier Joel Fernandes
2019-04-29 13:54     ` Greg KH
2019-04-29 14:14       ` Masahiro Yamada
2019-04-29 14:24         ` Greg KH
2019-04-29 14:29           ` Joel Fernandes
2019-05-03  7:30           ` Pavel Machek
2019-05-03  7:49             ` Greg KH
2019-05-03 14:33           ` Steven Rostedt
2019-05-03 15:08             ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v7 resend 1/2] Provide in-kernel headers to make extending kernel easier' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).