Date:   Sun, 12 May 2019 15:17:42 -0400
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Casey Schaufler <casey@...aufler-ca.com>,
        James Morris <jmorris@...ei.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2

On Sun, May 12, 2019 at 11:33 AM Paul Moore <paul@...l-moore.com> wrote:
>
> As far as I'm concerned, whatever makes it easier for Linus to consume
> the changes is the preferred path.

So for me it's not so much the pulling itself that ends up being a
problem, it's just that I want to feel like the pull request makes
sense, and I want to feel "safe" in pulling it.

The audit and selinux trees haven't had any issues that I can recall,
so that has worked fine. And it's been easier now that most of the
security layer things have been coming in separately, so it's easy for
me to see what's coming in, when it's in sane chunks that stand alone.
And then I also feel like _if_ there are problems in one area, it's
not affecting any other area the things are now. So if there's
something I want to look at a bit more, I might pull all the other
requests that I don't have any questions about, so that I can then
look more closely at the part I want to understand better.

I basically want to see pulls being "well-defined". That's both in the
area they affect, but also in the explanations for the pull request,
and preferably really also in the history (ie both the whole "starting
at a well-defined point", but also a "history is nice and clear", so I
like seeing topic branches and well-defined merges).

I guess it's kind of hard to explain, but it just gives me the warm
and fuzzies if I do a

    gitk ORIG_HEAD..

after having done a merge, and the history and merges I see "make sense".

Then I feel like even if there are problems with the code I pull, even
the problems will hopefully be well-defined. Sometimes that is
literally "ok, I'm bisecting some issue, but even before I've bisected
the whole way, I can see that it came in through a particular pull
request or two" because the changes came in through a few clearly
separated topic branch and it's clear which pull request it is even if
there are still a hundred more commits to bisect all the way..

Side note: this depends on the subsystem. When I pull huge subsystems
like networking from Davem or the big driver pulls from Greg, I don't
even look at the gitk history and ask myself "does this make sense",
because I have ceded that kind of worries over to Greg and Davem. The
history in their areas are their concern, and their subsystems are so
big that I don't expect them to make it make sense to me, if you see
what I mean. But if you want to see an area where you can see how
people have split up development in topic branches, you can look at my
"x86 merges", where I get separate pull requests for each topic
branch, and they all tend to be very clearly defined (but then there
might often a "misc leftovers" branch, or a couple of branches that
are just one or two commits).

>     My guess is that you are right and
> any *significant* changes to the LSM layer itself, e.g. security/*, is
> best sent via James' tree.  For smaller changes to the LSM layer I
> think it's okay if they go in via an individual LSM tree so long as
> all the other LSMs agree-on/ack the changes; which pretty much fits
> what we've been doing for some time now and it seems to work well
> enough.

Yeah, I think that's the sane model. And I think it's mostly been working.

             Linus

Powered by blists - more mailing lists