On Wed, Mar 1, 2017 at 11:35 AM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore <paul@xxxxxxxxxxxxxx> 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. Right, totally agreed: doing refcount_t conversions is going to be a long tail process, which is fine. > 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. Ah, hrm, yeah, I'd heard Linus mention that in the past, but when I was talking with sfr about what's best for -next tree targets, he mentioned -rc2 since it tends (in my understanding/memory of what he told me) to be the least "noisy" position. Interesting! > 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. Actually, no, this was great. Thanks! It's why I asked. :) Whenever I see a maintainer with a different approach I try to figure out what I'm missing, etc. :) -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html