From: Paul Moore <paul@paul-moore.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Reshetova, Elena" <elena.reshetova@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
"linux-audit@redhat.com" <linux-audit@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"tj@kernel.org" <tj@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"lizefan@huawei.com" <lizefan@huawei.com>,
"acme@kernel.org" <acme@kernel.org>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
Eric Paris <eparis@redhat.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"luto@kernel.org" <luto@kernel.org>,
Hans Liljestrand <ishkamiel@gmail.com>,
David Windsor <dwindsor@gmail.com>
Subject: Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t
Date: Wed, 1 Mar 2017 14:35:15 -0500 [thread overview]
Message-ID: <CAHC9VhR8FO+YDFy+jfL_Bv5SYHR1vjkznmber1xV+mWridg5fw@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5j+FdV--H8VBxJoZnY6ktgiyv4xSheQOkD77B-L-Cd1SVg@mail.gmail.com>
On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore <paul@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
next prev parent reply other threads:[~2017-03-01 22:16 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 10:18 [PATCH 00/19] Kernel subsystem refcounter conversions Elena Reshetova
2017-02-20 10:18 ` [PATCH 01/19] kernel: convert sighand_struct.count from atomic_t to refcount_t Elena Reshetova
2017-02-20 12:30 ` kbuild test robot
2017-02-20 12:42 ` kbuild test robot
2017-02-20 10:18 ` [PATCH 02/19] kernel: convert signal_struct.sigcnt " Elena Reshetova
2017-02-20 10:18 ` [PATCH 03/19] kernel: convert user_struct.__count " Elena Reshetova
2017-02-20 10:18 ` [PATCH 04/19] kernel: convert task_struct.usage " Elena Reshetova
2017-02-20 10:18 ` [PATCH 05/19] kernel: convert task_struct.stack_refcount " Elena Reshetova
2017-02-20 10:18 ` [PATCH 06/19] kernel: convert perf_event_context.refcount " Elena Reshetova
2017-02-20 10:28 ` Peter Zijlstra
2017-02-20 12:14 ` Reshetova, Elena
2017-02-20 10:18 ` [PATCH 07/19] kernel: convert ring_buffer.refcount " Elena Reshetova
2017-02-20 10:18 ` [PATCH 08/19] kernel: convert ring_buffer.aux_refcount " Elena Reshetova
2017-02-20 10:18 ` [PATCH 09/19] kernel: convert uprobe.ref " Elena Reshetova
2017-02-20 10:18 ` [PATCH 10/19] kernel: convert nsproxy.count " Elena Reshetova
2017-02-20 10:19 ` [PATCH 11/19] kernel: convert cgroup_namespace.count " Elena Reshetova
2017-03-06 19:55 ` Tejun Heo
2017-02-20 10:19 ` [PATCH 12/19] kernel: convert css_set.refcount " Elena Reshetova
2017-03-06 19:54 ` Tejun Heo
2017-03-07 19:12 ` Reshetova, Elena
2017-03-07 19:21 ` Tejun Heo
2017-02-20 10:19 ` [PATCH 13/19] kernel: convert group_info.usage " Elena Reshetova
2017-02-20 10:19 ` [PATCH 14/19] kernel: convert cred.usage " Elena Reshetova
2017-02-20 10:19 ` [PATCH 15/19] kernel: convert audit_tree.count " Elena Reshetova
2017-02-20 22:07 ` Paul Moore
2017-02-21 7:15 ` Reshetova, Elena
2017-02-28 22:11 ` Paul Moore
2017-03-01 0:16 ` Kees Cook
2017-03-01 19:35 ` Paul Moore [this message]
2017-03-01 23:04 ` Kees Cook
2017-04-11 19:01 ` Paul Moore
2017-04-18 6:33 ` Reshetova, Elena
2017-02-20 10:19 ` [PATCH 16/19] kernel: convert audit_watch.count " Elena Reshetova
2017-02-20 10:19 ` [PATCH 17/19] kernel: convert numa_group.refcount " Elena Reshetova
2017-02-20 10:19 ` [PATCH 18/19] kernel: convert futex_pi_state.refcount " Elena Reshetova
2017-02-20 10:19 ` [PATCH 19/19] kernel: convert kcov.refcount " Elena Reshetova
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=CAHC9VhR8FO+YDFy+jfL_Bv5SYHR1vjkznmber1xV+mWridg5fw@mail.gmail.com \
--to=paul@paul-moore.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=arnd@arndb.de \
--cc=cgroups@vger.kernel.org \
--cc=dwindsor@gmail.com \
--cc=elena.reshetova@intel.com \
--cc=eparis@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=ishkamiel@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-audit@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).