From: "Theodore Tso" <tytso@mit.edu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "igor.stoppa@gmail.com" <igor.stoppa@gmail.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Greg KH <gregkh@linuxfoundation.org>,
ksummit@lists.linux.dev, istoppa@nvidia.com
Subject: Re: [TECH TOPIC] Improving kernel security & integrity by generalizing ad-hoc safety mechanisms
Date: Tue, 8 Sep 2026 21:31:08 -0400 [thread overview]
Message-ID: <aqC1_EGWSkFTQzM3@mit.edu> (raw)
In-Reply-To: <20260908133545.05cbbd74@gandalf.local.home>
On Tue, Sep 08, 2026 at 01:35:45PM -0500, Steven Rostedt wrote:
> Just don't Cc the maintainers of the code you modify, as they may think
> it's for inclusion. Cc'ing LKML is one thing, as the only ones that read it
> are those that are curious about what is happening around the kernel. If it
> has some marking in the subject that denotes the patch is for a fork of the
> kernel (that you would be happy to be included one day) it should be fine.
The one exception I'd make to Steven's good advice is if you have a
pre-established working relationship with the maintainer, and the
subject is prefixed with something like [RFC PATCH] or [PATCH SAFETY],
you can ask them to give their opinion of their approach in your patch
set. (Especially if this is a feature that you are asking if this is
something which in their opinion might be ripe for inclusion in the
subsystem in the upstream feature.)
- Ted
prev parent reply other threads:[~2026-09-09 1:32 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 16:53 [TECH TOPIC] Improving kernel security & integrity by generalizing ad-hoc safety mechanisms igor.stoppa
2026-09-07 19:46 ` Greg KH
2026-09-07 21:42 ` igor.stoppa
2026-09-08 3:51 ` Theodore Tso
2026-09-08 10:14 ` igor.stoppa
2026-09-08 13:55 ` Theodore Tso
2026-09-08 14:32 ` igor.stoppa
2026-09-08 19:29 ` Steven Rostedt
2026-09-08 21:13 ` igor.stoppa
2026-09-08 23:14 ` Steven Rostedt
2026-09-08 23:48 ` igor.stoppa
2026-09-09 7:44 ` Gabriele Monaco
2026-09-09 9:40 ` igor.stoppa
2026-09-09 15:22 ` Gabriele Monaco
2026-09-09 16:07 ` igor.stoppa
2026-09-09 16:14 ` Steven Rostedt
2026-09-09 16:24 ` igor.stoppa
2026-09-09 16:32 ` Steven Rostedt
2026-09-10 10:10 ` Gabriele Monaco
2026-09-08 5:05 ` Greg KH
2026-09-08 11:26 ` igor.stoppa
2026-09-08 11:54 ` Greg KH
2026-09-08 12:25 ` igor.stoppa
2026-09-08 12:39 ` Greg KH
2026-09-08 12:52 ` igor.stoppa
2026-09-08 13:11 ` Miguel Ojeda
2026-09-08 13:52 ` igor.stoppa
2026-09-08 14:44 ` Theodore Tso
2026-09-08 15:32 ` igor.stoppa
2026-09-08 12:41 ` James Bottomley
2026-09-08 13:03 ` igor.stoppa
2026-09-08 15:40 ` Steven Rostedt
2026-09-08 16:09 ` igor.stoppa
2026-09-08 17:35 ` Steven Rostedt
2026-09-09 1:31 ` Theodore Tso [this message]
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=aqC1_EGWSkFTQzM3@mit.edu \
--to=tytso@mit.edu \
--cc=James.Bottomley@hansenpartnership.com \
--cc=gregkh@linuxfoundation.org \
--cc=igor.stoppa@gmail.com \
--cc=istoppa@nvidia.com \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.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.