From: Petr Mladek <pmladek@suse.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Chris Down <chris@chrisdown.name>,
linux-kernel@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
John Ogness <john.ogness@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Kees Cook <keescook@chromium.org>,
kernel-team@fb.com
Subject: Re: [PATCH v6 3/4] printk: Userspace format indexing support
Date: Tue, 25 May 2021 17:19:20 +0200 [thread overview]
Message-ID: <YK0VeJsPMVwvK+vG@alley> (raw)
In-Reply-To: <YKYrIzUGV7VlDu9D@smile.fi.intel.com>
On Thu 2021-05-20 12:25:55, Andy Shevchenko wrote:
> On Wed, May 19, 2021 at 08:59:06AM +0200, Rasmus Villemoes wrote:
> > On 18/05/2021 18.00, Andy Shevchenko wrote:
> > > On Tue, May 18, 2021 at 03:07:44PM +0100, Chris Down wrote:
> > >>>> +static int __init pi_init(void)
> > >
> > >>> No __exit? (There is a corresponding call for exit)
> > >>
> > >> Hmm, can't printk only be built in to the kernel, so it can't be unloaded?
> > >> At least it looks that way from Kconfig. Maybe I'm missing something and
> > >> there's some other way that might be invoked?
> > >
> > > While it's true, it may help in these cases:
> > > 1) getting things done in a clean way
> >
> > Huh?
> >
> > > 2) finding bugs during boot cycle
> >
> > What bugs would code that doesn't get executed find?
> >
> > > 3) (possibly) making better debugging in virtual environments
> >
> > How?
> >
> > > 4) (also possibly) clean up something which shouldn't be seen by the next
> > > (unsecure) kernel, like kexec.
> >
> > Tearing down a few debugfs files wouldn't touch a lot of memory, the
> > printk format strings are very unlikely to be sensitive, and I highly
> > doubt __exit code is kept around and run at kexec time anyway.
>
> I admit that I'm on a learning curve in this area, and perhaps it was unclear
> from the above that the list I gave is what I think may or might be relevant.
>
> > IOW, please do not bloat the kernel image with __exit code in things
> > which cannot be built modular.
>
> Why we have exitcall in the code which can't be modular? Is somebody going to
> clean that up? (Ex. `git grep -w __exitcall`)
Most exit calls are in "um" arch code. AFAIK, it is a kernel that can be
booted in userspace. And it is very special.
Anyway, this functionality (printk index) do not need any special
handling during suspend, reboot, halt, or other system state
changes.
It only has to be initialized during boot at the right time.
It is after debugfs is initialized and before modules can be
loaded.
Best Regards,
Petr
next prev parent reply other threads:[~2021-05-25 15:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 12:00 [PATCH v6 0/4] printk: Userspace format indexing support Chris Down
2021-05-18 12:00 ` [PATCH v6 1/4] string_helpers: Escape double quotes in escape_special Chris Down
2021-05-18 13:10 ` Andy Shevchenko
2021-05-18 14:10 ` Chris Down
2021-05-25 10:17 ` Petr Mladek
2021-05-18 12:00 ` [PATCH v6 2/4] printk: Straighten out log_flags into printk_info_flags Chris Down
2021-05-25 10:33 ` Petr Mladek
2021-05-25 11:35 ` John Ogness
2021-05-26 7:31 ` Petr Mladek
2021-05-26 8:39 ` John Ogness
2021-05-26 9:25 ` Petr Mladek
2021-06-01 15:16 ` Chris Down
2021-05-18 12:00 ` [PATCH v6 3/4] printk: Userspace format indexing support Chris Down
2021-05-18 13:30 ` Andy Shevchenko
2021-05-18 14:07 ` Chris Down
2021-05-18 16:00 ` Andy Shevchenko
2021-05-18 16:28 ` Chris Down
2021-05-18 16:59 ` Chris Down
2021-05-19 6:59 ` Rasmus Villemoes
2021-05-20 9:25 ` Andy Shevchenko
2021-05-25 15:19 ` Petr Mladek [this message]
2021-05-25 15:06 ` Petr Mladek
2021-06-01 15:15 ` Chris Down
2021-06-04 10:19 ` Petr Mladek
2021-06-04 11:50 ` Chris Down
2021-05-18 12:00 ` [PATCH v6 4/4] printk: index: Add indexing support to dev_printk Chris Down
2021-05-26 8:57 ` Petr Mladek
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YK0VeJsPMVwvK+vG@alley \
--to=pmladek@suse.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=chris@chrisdown.name \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=jeyu@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=keescook@chromium.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox