From: Qian Cai <cai@lca.pw>
To: Rafael Aquini <aquini@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-doc@vger.kernel.org, kexec@lists.infradead.org,
linux-fsdevel@vger.kernel.org, dyoung@redhat.com,
Baoquan He <bhe@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] kernel: add panic_on_taint
Date: Thu, 7 May 2020 20:28:40 -0400 [thread overview]
Message-ID: <438575BA-00CA-44BF-8C4C-693DCC00FDD1@lca.pw> (raw)
In-Reply-To: <20200507233634.GA367616@optiplex-lnx>
> On May 7, 2020, at 7:36 PM, Rafael Aquini <aquini@redhat.com> wrote:
>
> On Thu, May 07, 2020 at 07:07:20PM -0400, Qian Cai wrote:
>>
>>
>>> On May 7, 2020, at 6:15 PM, Rafael Aquini <aquini@redhat.com> wrote:
>>>
>>> It's a reasonable and self-contained feature that we have a valid use for.
>>> I honestly fail to see it causing that amount of annoyance as you are
>>> suggesting here.
>>
>> It is not a big trouble yet, but keeping an obsolete patch that not very straightforward to figure out that it will be superseded by the panic_on_taint patch will only cause more confusion the longer it has stayed in linux-next.
>>
>> The thing is that even if you can’t get this panic_on_taint (the superior solution) patch accepted for some reasons, someone else could still work on it until it get merged.
>>
>> Thus, I failed to see any possibility we will go back to the inferior solution (mm-slub-add-panic_on_error-to-the-debug-facilities.patch) by all means.
>>
>
> There are plenty of examples of things being added, changed, and
> removed in -next. IOW, living in a transient state. I think it's
> a reasonable compromise to keep it while the other one is beind
> ironed out.
>
> The fact that you prefer one solution to another doesn't
> invalidate the one you dislike.
As far I can tell, the bar of the other core subsystems are quite high even for linux-next. People have been voiced over and over again to urge Andrew not picking up patches so eagerly, but I will save that discussion for the next time.
Anyway, thanks for working for the panic_on_taint patch. I believe it could be useful for all testing agents to catch those bad pages earlier.
WARNING: multiple messages have this Message-ID (diff)
From: Qian Cai <cai@lca.pw>
To: Rafael Aquini <aquini@redhat.com>
Cc: Kees Cook <keescook@chromium.org>, Baoquan He <bhe@redhat.com>,
linux-doc@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
kexec@lists.infradead.org, LKML <linux-kernel@vger.kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
dyoung@redhat.com
Subject: Re: [PATCH] kernel: add panic_on_taint
Date: Thu, 7 May 2020 20:28:40 -0400 [thread overview]
Message-ID: <438575BA-00CA-44BF-8C4C-693DCC00FDD1@lca.pw> (raw)
In-Reply-To: <20200507233634.GA367616@optiplex-lnx>
> On May 7, 2020, at 7:36 PM, Rafael Aquini <aquini@redhat.com> wrote:
>
> On Thu, May 07, 2020 at 07:07:20PM -0400, Qian Cai wrote:
>>
>>
>>> On May 7, 2020, at 6:15 PM, Rafael Aquini <aquini@redhat.com> wrote:
>>>
>>> It's a reasonable and self-contained feature that we have a valid use for.
>>> I honestly fail to see it causing that amount of annoyance as you are
>>> suggesting here.
>>
>> It is not a big trouble yet, but keeping an obsolete patch that not very straightforward to figure out that it will be superseded by the panic_on_taint patch will only cause more confusion the longer it has stayed in linux-next.
>>
>> The thing is that even if you can’t get this panic_on_taint (the superior solution) patch accepted for some reasons, someone else could still work on it until it get merged.
>>
>> Thus, I failed to see any possibility we will go back to the inferior solution (mm-slub-add-panic_on_error-to-the-debug-facilities.patch) by all means.
>>
>
> There are plenty of examples of things being added, changed, and
> removed in -next. IOW, living in a transient state. I think it's
> a reasonable compromise to keep it while the other one is beind
> ironed out.
>
> The fact that you prefer one solution to another doesn't
> invalidate the one you dislike.
As far I can tell, the bar of the other core subsystems are quite high even for linux-next. People have been voiced over and over again to urge Andrew not picking up patches so eagerly, but I will save that discussion for the next time.
Anyway, thanks for working for the panic_on_taint patch. I believe it could be useful for all testing agents to catch those bad pages earlier.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-05-08 0:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 22:28 [PATCH] kernel: add panic_on_taint Rafael Aquini
2020-05-06 22:28 ` Rafael Aquini
2020-05-06 23:24 ` Luis Chamberlain
2020-05-06 23:24 ` Luis Chamberlain
2020-05-07 0:12 ` Rafael Aquini
2020-05-07 0:12 ` Rafael Aquini
2020-05-07 0:20 ` Randy Dunlap
2020-05-07 0:20 ` Randy Dunlap
2020-05-07 2:50 ` Qian Cai
2020-05-07 2:50 ` Qian Cai
2020-05-07 20:42 ` Rafael Aquini
2020-05-07 20:42 ` Rafael Aquini
2020-05-07 22:05 ` Qian Cai
2020-05-07 22:05 ` Qian Cai
2020-05-07 22:15 ` Rafael Aquini
2020-05-07 22:15 ` Rafael Aquini
2020-05-07 23:07 ` Qian Cai
2020-05-07 23:07 ` Qian Cai
2020-05-07 23:36 ` Rafael Aquini
2020-05-07 23:36 ` Rafael Aquini
2020-05-08 0:28 ` Qian Cai [this message]
2020-05-08 0:28 ` Qian Cai
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=438575BA-00CA-44BF-8C4C-693DCC00FDD1@lca.pw \
--to=cai@lca.pw \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=bhe@redhat.com \
--cc=corbet@lwn.net \
--cc=dyoung@redhat.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.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.