Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t
On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook <keescook(a)chromium.org> wrote:
On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore
<paul(a)paul-moore.com> wrote:
> I just realized that include/linux/refcount.h didn't make it into
> v4.10 which means there is going to be delay until I merge them into
> the audit tree (I don't base the tree on -rc releases except under
> extreme circumstances). I've got the patches queued up in a private
> holding branch (I added #includes BTW) so I won't forget, but as a
> FYI, they likely won't make it in until v4.12.
I'm not asking for you to change this, but I am curious: doesn't that
force you to always be a release behind? I've tended to base trees on
-rc2 (and then the final release while the next merge window is open).
But that may be because I tend to have such wide dependencies...
In general, yes ... and if you are just looking for the short answer
I'd leave it at that. I do leave door open for exceptions under
unusual circumstances, but I don't believe the refcount_t conversion
is one of those cases.
The longer answer lies in a balancing act between what I understand
Linus' and/or James desires (different upstream maintainers, different
approaches, but for my own sanity I like to stick to a single
"process" across my trees), the linux-next effort, branch stability
(aka limited or predictable rebases), and my own testing requirements.
First off, the current policy I follow for the SELinux and audit trees
can be found here:
* http://www.paul-moore.com/blog/d/2016/03/kernel-repo-process.html
... it's relatively simple and has proven to work reasonably well over
the past year or so. On occasion, the subsystem changes in a given
release are significant enough that I skip a rebase (step #2 in the
process) but that has only happened once (twice?) with the audit tree
and didn't prove to be a real problem; this is less of an issue with
the SELinux tree as James often rebases the linux-security tree to the
current -rc1 or -rc2 tree.
As for the balancing act ... My understanding is that Linus doesn't
like to see pull requests from trees based on -rcX tags, he would much
prefer to see trees based on a proper release, e.g. v4.10; on the plus
side, Linus is willing to put up with some merge fuzzing so long as it
is understandable and/or well explained. James wants pull requests
that apply with zero merge conflicts to his linux-security/next tree;
on the plus side, the linux-security/next tree tends to be based on
the current -rc1/2 so a broad set of dependencies isn't too bad (which
is important for SELinux). The linux-next people want to see a commit
ID follow a steady progression of multiple weeks in the subsystem
-next branch and then a trickle up through various trees until it hits
Linus' tree. The branch stability requirements are pretty obvious,
and with the exception of the -next branches during/immediately-after
the merge window, I don't really rebase branches unless there is a
Very Good Reason. Finally, my own testing requirements are such that
I want to test the current SELinux and audit -next/-stable branches
against the latest bits in Linus' tree (e.g. -rcX releases) on a
weekly basis so keeping those branches as current as possible is
important; I talked a bit more about my testing at Flock 2016,
slides/video at the link below:
* http://www.paul-moore.com/blog/d/2016/08/flock-kernel-testing.html
* https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext
There ya go, probably more than you wanted to know, but that's why
things are the way they are with the SELinux and audit trees. I
remain open to new ideas about how to manage the trees, but the
current arrangement seems to work reasonably well at the moment.
--
paul moore
www.paul-moore.com