From: Petr Mladek <pmladek@suse.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
Ondrej Mosnacek <omosnace@redhat.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf()
Date: Fri, 29 May 2020 10:17:48 +0200 [thread overview]
Message-ID: <20200529081748.GC27273@linux-b0ei> (raw)
In-Reply-To: <CAHk-=wgz=7MGxxX-tmMmdCsKyYJkuyxNc-4uLP=e_eEV=OzUaw@mail.gmail.com>
On Thu 2020-05-28 12:50:35, Linus Torvalds wrote:
> On Thu, May 28, 2020 at 8:17 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >
> > CONFIG_TWIST_FOR_SYZKALLER_TESTING is meant for linux-next only.
> > But CONFIG_TWIST_KERNEL_BEHAVIOR is meant for Linus's tree.
>
> I really absolutely still detest this all. I don't see the point. The
> naming is completely random (both "twist" and then options like
> "TWIST_FOR_SYZKALLER_TESTING" that have no conceptual meaning.
>
> I still don't understand why this small set of random options couldn't
> just be kernel options that get set on the command line, and that have
> independent and sane and explainable behavior? Why this odd mentality
> of "syzkaller is special"?
I am afraid that many of them could not be normal options. They change or
break some behavior that is necessary by seriously used system.
> I've complained about this whole thing before. I'm getting really fed
> up with this whole concept of "magic crazy config options".
Just to make my role clear in this saga.
I am focused on the change of pr_debug() behavior. I do _not_ believe
that it is worth it. But I wanted to give fuzzer guys a chance to get
some data.
This is why I offered to push hacky patch into linux-next via printk
tree to get fuzzers fed. Such a patch would change the behavior only
for the fuzzer (with the crazy config enabled) and it would be there
only for a limited time.
I personally do _not_ have a good feeling about having such hacks in
upstream kernel. But I do not feel in position to decide about it.
I wanted to solve this question later if there would have been
anything to upstream.
I am _not_ going to push any twists, in the current form,
upstream via printk tree.
Best Regards,
Petr
next prev parent reply other threads:[~2020-05-29 8:17 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-24 14:50 [PATCH] twist: allow converting pr_devel()/pr_debug() into printk(KERN_DEBUG) Tetsuo Handa
2020-05-24 17:38 ` Joe Perches
2020-05-24 19:18 ` Ondrej Mosnacek
2020-05-25 5:03 ` Tetsuo Handa
2020-05-25 6:07 ` Joe Perches
2020-05-25 7:38 ` Dmitry Vyukov
2020-05-25 8:42 ` Petr Mladek
2020-05-25 9:11 ` Sergey Senozhatsky
2020-05-25 10:43 ` Tetsuo Handa
2020-05-27 8:37 ` Petr Mladek
2020-05-27 10:13 ` Tetsuo Handa
2020-05-27 15:55 ` Petr Mladek
2020-05-27 23:33 ` Tetsuo Handa
2020-05-28 6:56 ` [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() Tetsuo Handa
2020-05-28 11:06 ` Petr Mladek
2020-05-28 15:16 ` Tetsuo Handa
2020-05-28 19:10 ` Andrew Morton
2020-05-28 19:50 ` Linus Torvalds
2020-05-28 20:01 ` Linus Torvalds
2020-05-29 0:07 ` Tetsuo Handa
2020-05-29 0:28 ` Linus Torvalds
2020-05-29 2:13 ` Tetsuo Handa
2020-05-29 2:24 ` Linus Torvalds
2020-05-29 4:47 ` Tetsuo Handa
2020-05-29 13:26 ` Tetsuo Handa
2020-06-03 11:03 ` twist: allow disabling reboot request Tetsuo Handa
2020-06-03 12:44 ` Petr Mladek
2020-06-03 13:35 ` Tetsuo Handa
2020-06-04 10:21 ` Petr Mladek
2020-06-08 7:48 ` [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() Dmitry Vyukov
2020-06-08 10:30 ` Tetsuo Handa
2020-06-08 11:31 ` Andrey Konovalov
2020-05-29 8:17 ` Petr Mladek [this message]
2020-06-08 16:39 ` Geert Uytterhoeven
2020-05-28 10:59 ` [PATCH] twist: allow converting pr_devel()/pr_debug() into printk(KERN_DEBUG) Petr Mladek
2020-05-28 11:33 ` Tetsuo Handa
2020-05-28 12:14 ` Petr Mladek
2020-05-28 14:13 ` Tetsuo Handa
2020-05-28 17:08 ` Joe Perches
2020-05-29 2:04 ` Sergey Senozhatsky
2020-05-29 5:06 ` Tetsuo Handa
2020-05-27 9:59 ` kbuild test robot
2020-05-27 9:59 ` kbuild test robot
2020-05-27 13:41 ` Tetsuo Handa
2020-05-27 13:41 ` Tetsuo Handa
2020-05-27 12:37 ` kbuild test robot
2020-05-27 12:37 ` kbuild test robot
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=20200529081748.GC27273@linux-b0ei \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.