Hi Paul,
The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next)
contains some commits going back to January and also has merges of
v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1,
you find that it has onlt 2 unique commits (the most recent 2) which
means that the others were merged upstream after being rewritten. :-(
Please clean this up.
--
Cheers,
Stephen Rothwell [email protected]
On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote:
> Hi Paul,
>
> The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next)
> contains some commits going back to January and also has merges of
> v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1,
> you find that it has onlt 2 unique commits (the most recent 2) which
> means that the others were merged upstream after being rewritten. :-(
Without going through each of the differences between the SELinux tree and
what is in Linus' tree in this email, I can assure you there is nothing
nefarious going on here, just some differences in tree management between
James' Linux Security tree and the SELinux tree which resulted in some
backports and other mess. The good news is that James' and the rest of us
under the Linux Security tree have now established a protocol moving forward
which should avoid these nasties.
So, back to your concerns - what do you want to see in linux-next? My
practice for the SELinux #next branch has been to apply patches on top of the
latest "major" release from Linus, e.g. 3.15, and when a new major release is
made I merge it into #next and restart the process. I generally send James' a
pull request in the -rc6/7 timeframe using the #next branch. While this has
resulted in some ugliness (see above comments) it keeps the SELinux #next
branch steady so others can pull from it without major problems.
Does this approach not work for you and linux-next?
--
paul moore
http://www.paul-moore.com
Hi Paul,
On Wed, 18 Jun 2014 14:26:27 -0400 Paul Moore <[email protected]> wrote:
>
> On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote:
> >
> > The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next)
> > contains some commits going back to January and also has merges of
> > v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1,
> > you find that it has onlt 2 unique commits (the most recent 2) which
> > means that the others were merged upstream after being rewritten. :-(
>
> Without going through each of the differences between the SELinux tree and
> what is in Linus' tree in this email, I can assure you there is nothing
> nefarious going on here, just some differences in tree management between
> James' Linux Security tree and the SELinux tree which resulted in some
> backports and other mess. The good news is that James' and the rest of us
> under the Linux Security tree have now established a protocol moving forward
> which should avoid these nasties.
Sounds good. I usually assume that these issues are misunderstandings
or oversights.
> So, back to your concerns - what do you want to see in linux-next? My
> practice for the SELinux #next branch has been to apply patches on top of the
> latest "major" release from Linus, e.g. 3.15, and when a new major release is
> made I merge it into #next and restart the process. I generally send James' a
> pull request in the -rc6/7 timeframe using the #next branch. While this has
> resulted in some ugliness (see above comments) it keeps the SELinux #next
> branch steady so others can pull from it without major problems.
>
> Does this approach not work for you and linux-next?
OK, you should probably base your tree on -rc1 or 2, that way all your
stuff for the previous merge window is upstream and you don't need to
worry about it any more.
As for your current tree, it contains the following commits:
(1) 5c7001b84be5 SELinux: use ARRAY_SIZE
(2) aa65506f198c selinux, kbuild: remove unnecessary $(hostprogs-y) from clean-files
170b5910d9fb Merge tag 'v3.15' into next
(3) 47dd0b76ace9 selinux: conditionally reschedule in hashtab_insert while loading selinux policy
(4) 612c353178c4 selinux: conditionally reschedule in mls_convert_context while loading selinux policy
(5) 4f189988a0a5 selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES
(6) 626b9740fa73 selinux: Report permissive mode in avc: denied messages.
6d32c850621b Merge tag 'v3.14' into next
(7) eee3094683fb selinux: correctly label /proc inodes in use before the policy is loaded
(8) 0909c0ae999c selinux: put the mmap() DAC controls before the MAC controls
(9) 81c94e76ce8e selinux: fix the output of ./scripts/get_maintainer.pl for SELinux
41be702a542a Merge tag 'v3.13' into next
1 and 2 are new
3 is in Linus' tree as commit ed1c96429a6a
4 9a591f39a9d1
5 5b589d44fad1
6 ca7786a2f916
7 f64410ec6654
8 and 9 are subsumed by something in Linus' tree.
So every time I merge your tree into linux-next I get duplicates (whcih
can cause conflicts if there are other changes to the same areas of the
the files effected). Also, if James really merged you tree (i.e. with
a "git pull" or "git fetch; get merge") then we would end up with
duplicates in his tree (and then Linus' tree).
I can see that part of the problem this time round is that Serge
cherry-picked (or rebased) your commits 3-6 above onto James' tree
before asking Linus to pull.
So, the easiest way for you to clean up from this is to now rebase onto
v3.16-rc1 (which will leave you with just commits 1 and 2) and then
ensure that in the future James (or whoever is handling the security
tree) pulls your tree (and doesn't cherry-pick the patches). Then
after that has happened, you can fast forward your tree onto that
upstream tree, or wait until the next -rc1 and fast forward to that.
I hope that is sort of clear and makes some sense?
(As an aside, if you do a git pull on a tag, it will create a merge
commit even if it doesn't need to, so for example doing "git merge <tag
from Linus' tree after your commits are merged upstream>" will create a
merge rather than just fast forwarding.)
--
Cheers,
Stephen Rothwell [email protected]
On Friday, June 20, 2014 01:08:37 AM Stephen Rothwell wrote:
> Hi Paul,
Howdy.
> On Wed, 18 Jun 2014 14:26:27 -0400 Paul Moore <[email protected]> wrote:
> > On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote:
I'm going to chop up your email a bit so it makes more sense when replying, my
apologies if I make things worse.
> As for your current tree, it contains the following commits:
>
> (1) 5c7001b84be5 SELinux: use ARRAY_SIZE
> (2) aa65506f198c selinux, kbuild: remove unnecessary $(hostprogs-y) from
> clean-files 170b5910d9fb Merge tag 'v3.15' into next
> (3) 47dd0b76ace9 selinux: conditionally reschedule in hashtab_insert while
> loading selinux policy (4) 612c353178c4 selinux: conditionally reschedule
> in mls_convert_context while loading selinux policy (5) 4f189988a0a5
> selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES (6)
> 626b9740fa73 selinux: Report permissive mode in avc: denied messages.
> 6d32c850621b Merge tag 'v3.14' into next
> (7) eee3094683fb selinux: correctly label /proc inodes in use before the
> policy is loaded (8) 0909c0ae999c selinux: put the mmap() DAC controls
> before the MAC controls (9) 81c94e76ce8e selinux: fix the output of
> ./scripts/get_maintainer.pl for SELinux 41be702a542a Merge tag 'v3.13' into
> next
>
> 1 and 2 are new
Yes, these are the "new" SELinux patches that should be in linux-next.
> 3 is in Linus' tree as commit ed1c96429a6a
> 4 9a591f39a9d1
> 5 5b589d44fad1
> 6 ca7786a2f916
> 7 f64410ec6654
> 8 and 9 are subsumed by something in Linus' tree.
These are likely caused by the problems we talked about earlier.
> > So, back to your concerns - what do you want to see in linux-next? My
> > practice for the SELinux #next branch has been to apply patches on top of
> > the latest "major" release from Linus, e.g. 3.15, and when a new major
> > release is made I merge it into #next and restart the process. I
> > generally send James' a pull request in the -rc6/7 timeframe using the
> > #next branch. While this has resulted in some ugliness (see above
> > comments) it keeps the SELinux #next branch steady so others can pull
> > from it without major problems.
> >
> > Does this approach not work for you and linux-next?
>
> OK, you should probably base your tree on -rc1 or 2, that way all your
> stuff for the previous merge window is upstream and you don't need to
> worry about it any more.
...
> So, the easiest way for you to clean up from this is to now rebase onto
> v3.16-rc1 (which will leave you with just commits 1 and 2) and then
> ensure that in the future James (or whoever is handling the security
> tree) pulls your tree (and doesn't cherry-pick the patches). Then
> after that has happened, you can fast forward your tree onto that
> upstream tree, or wait until the next -rc1 and fast forward to that.
I want to avoid use a -rcX release as the foundation of any of my trees; the -
rc releases aren't as stable and it goes against what we're trying to do with
the different Linux Security trees. Unfortunately, based on what I've read
above, this seems to be incompatible with linux-next.
While I hate to split my development branch from the #next branch, it seems
like that is the only way to accomplish both a reasonably current and stable
development tree and get the patches into linux-next. Unless you, or anyone
else for that matter, has a different suggestion I'm going to go ahead and
turn the current SELinux #next branch into a development branch and create a
new #next branch that will be based on the most current -rc1, this new #next
branch will be created new for each major release. Not exactly what I was
hoping for, but will that work?
--
paul moore
http://www.paul-moore.com
Hi Paul,
On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore <[email protected]> wrote:
>
> I want to avoid use a -rcX release as the foundation of any of my trees; the -
> rc releases aren't as stable and it goes against what we're trying to do with
> the different Linux Security trees. Unfortunately, based on what I've read
> above, this seems to be incompatible with linux-next.
The problem with basing your development for v3.17 on v3.15 is that
you do not take into account any of the changes done by others during
v3.16-rc1 (or even your upstream tree) some of which may be core API
changes.
> While I hate to split my development branch from the #next branch, it seems
I don't want that either ...
> like that is the only way to accomplish both a reasonably current and stable
> development tree and get the patches into linux-next. Unless you, or anyone
> else for that matter, has a different suggestion I'm going to go ahead and
> turn the current SELinux #next branch into a development branch and create a
> new #next branch that will be based on the most current -rc1, this new #next
> branch will be created new for each major release. Not exactly what I was
> hoping for, but will that work?
Do you mean that your #next branch will just be a merge of -rc1 and
your development branch? That would not actually change anything
(except that you would possibly take care of some conflicts for me).
At the core, what is in linux-next should just be exactly what will be
merged by your upstream. My real point here is that that is not what
has happened recently. The patches in your tree have been
cherry-picked or rebased into James' or Serge's trees, not merged so we
now have duplication. This is what you need to solve with James and
Serge. linux-next is a side issue - I can cope with a lot.
--
Cheers,
Stephen Rothwell [email protected]
Quoting Stephen Rothwell ([email protected]):
> Hi Paul,
>
> On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore <[email protected]> wrote:
> >
> > I want to avoid use a -rcX release as the foundation of any of my trees; the -
> > rc releases aren't as stable and it goes against what we're trying to do with
> > the different Linux Security trees. Unfortunately, based on what I've read
> > above, this seems to be incompatible with linux-next.
>
> The problem with basing your development for v3.17 on v3.15 is that
> you do not take into account any of the changes done by others during
> v3.16-rc1 (or even your upstream tree) some of which may be core API
> changes.
>
> > While I hate to split my development branch from the #next branch, it seems
>
> I don't want that either ...
>
> > like that is the only way to accomplish both a reasonably current and stable
> > development tree and get the patches into linux-next. Unless you, or anyone
> > else for that matter, has a different suggestion I'm going to go ahead and
> > turn the current SELinux #next branch into a development branch and create a
> > new #next branch that will be based on the most current -rc1, this new #next
> > branch will be created new for each major release. Not exactly what I was
> > hoping for, but will that work?
>
> Do you mean that your #next branch will just be a merge of -rc1 and
> your development branch? That would not actually change anything
> (except that you would possibly take care of some conflicts for me).
>
> At the core, what is in linux-next should just be exactly what will be
> merged by your upstream. My real point here is that that is not what
> has happened recently. The patches in your tree have been
> cherry-picked or rebased into James' or Serge's trees, not merged so we
> now have duplication. This is what you need to solve with James and
> Serge. linux-next is a side issue - I can cope with a lot.
The duplicates were the result of several misunderstandings and general
naivity all on my part. I'm actually still not clear on what usually
happens with the selinux tree - it feeds into linux-next, then gets
'pull'ed by James into security-next for a pull request? Do you usually
send a request to James when ready, he pulls, then he sends pull request
to Linus? (Or am I wrong, and you usually send your own requests to
Linus?)
-serge
Hi Serge,
On Fri, 20 Jun 2014 05:43:56 +0200 "Serge E. Hallyn" <[email protected]> wrote:
>
> The duplicates were the result of several misunderstandings and general
> naivity all on my part. I'm actually still not clear on what usually
> happens with the selinux tree - it feeds into linux-next, then gets
> 'pull'ed by James into security-next for a pull request? Do you usually
> send a request to James when ready, he pulls, then he sends pull request
> to Linus? (Or am I wrong, and you usually send your own requests to
> Linus?)
If "you" is Paul, then I am pretty sure he asks James to pull and then
James in turn asks Linus to pull.
If "you" is me, then no :-)
--
Cheers,
Stephen Rothwell [email protected]
Quoting Stephen Rothwell ([email protected]):
> Hi Serge,
>
> On Fri, 20 Jun 2014 05:43:56 +0200 "Serge E. Hallyn" <[email protected]> wrote:
> >
> > The duplicates were the result of several misunderstandings and general
> > naivity all on my part. I'm actually still not clear on what usually
> > happens with the selinux tree - it feeds into linux-next, then gets
> > 'pull'ed by James into security-next for a pull request? Do you usually
> > send a request to James when ready, he pulls, then he sends pull request
> > to Linus? (Or am I wrong, and you usually send your own requests to
> > Linus?)
>
> If "you" is Paul, then I am pretty sure he asks James to pull and then
> James in turn asks Linus to pull.
>
> If "you" is me, then no :-)
Thanks :)
-serge
On Friday, June 20, 2014 08:59:31 AM Stephen Rothwell wrote:
> Hi Paul,
Hello again.
> On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore <[email protected]> wrote:
> > I want to avoid use a -rcX release as the foundation of any of my trees;
> > the -rc releases aren't as stable and it goes against what we're trying
> > to do with the different Linux Security trees. Unfortunately, based on
> > what I've read above, this seems to be incompatible with linux-next.
>
> The problem with basing your development for v3.17 on v3.15 is that
> you do not take into account any of the changes done by others during
> v3.16-rc1 (or even your upstream tree) some of which may be core API
> changes.
The way I currently do things - merge the latest major release on top of the
existing #next and then start applying the new #next patches - does leave the
SELinux tree a bit behind when it comes to other subsystems, but it does at
least include all of the SELinux relevant patches.
I'll admit it isn't perfect, but it seems to work reasonably well for SELinux
development, and it was the process used by the previous SELinux maintainer.
> > While I hate to split my development branch from the #next branch, it
> > seems
>
> I don't want that either ...
>
> > like that is the only way to accomplish both a reasonably current and
> > stable development tree and get the patches into linux-next. Unless you,
> > or anyone else for that matter, has a different suggestion I'm going to
> > go ahead and turn the current SELinux #next branch into a development
> > branch and create a new #next branch that will be based on the most
> > current -rc1, this new #next branch will be created new for each major
> > release. Not exactly what I was hoping for, but will that work?
>
> Do you mean that your #next branch will just be a merge of -rc1 and
> your development branch? That would not actually change anything
> (except that you would possibly take care of some conflicts for me).
Sort of, I would basically create a new #next branch for linux-next which
would be created fresh from the latest -rc1 and I would cherry-pick the
patches for linux-next from my development branch. It would be a bit of a
mess to be honest, but I'm trying to reconcile the SELinux development
needs/wants with the linux-next needs/wants.
> At the core, what is in linux-next should just be exactly what will be
> merged by your upstream.
That has been, and remains the goal for me as well. However, there have been
a number of problems with this in the past, even excluding the latest merge
window; I believe these past problems are what you are seeing now.
I am hopeful that these issues are behind us now, at least for the most part.
> My real point here is that that is not what has happened recently. The
> patches in your tree have been cherry-picked or rebased into James' or
> Serge's trees, not merged so we now have duplication. This is what you need
> to solve with James and Serge. linux-next is a side issue - I can cope with
> a lot.
See above. This issue has been solved with James a few months ago, this merge
window was actually on track to go off without a problem, and it sorta did,
but there were some out-of-band issues which caused some confusion in the
linux-security world. Let's try to move on a bit, discussing why the SELinux
#next branch has some cruft in it doesn't help us resolve things since we all
acknowledge there were problems for a while that should now be resolved ...
Stephen, assuming for a moment that I created a fresh branch, based against
3.15, and then added the SELinux patches for 3.16 (basically the few new
patches that were in the ole #next branch) would that serve as a reasonable
basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
send a pull request to James to pull from this next branch into the Linux
Security branch for 3.17. Once 3.16 is released, I would merge that into this
new #next branch and continue with the next round of patches.
FYI, more or less, the above is the process we've settled upon for all of the
trees that get accumulated into the Linux Security tree.
--
paul moore
http://www.paul-moore.com
On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
{big snip}
> Stephen, assuming for a moment that I created a fresh branch, based against
> 3.15, and then added the SELinux patches for 3.16 (basically the few new
> patches that were in the ole #next branch) would that serve as a reasonable
> basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
> send a pull request to James to pull from this next branch into the Linux
> Security branch for 3.17. Once 3.16 is released, I would merge that into
> this new #next branch and continue with the next round of patches.
>
> FYI, more or less, the above is the process we've settled upon for all of
> the trees that get accumulated into the Linux Security tree.
Hi Stephen,
Does the above work for you in linux-next? I'd like to try and resolve this
sooner rather than later and I imagine you feel the same ...
--
paul moore
http://www.paul-moore.com
Hi Paul,
On Tue, 24 Jun 2014 14:03:08 -0400 Paul Moore <[email protected]> wrote:
>
> On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
>
> {big snip}
>
> > Stephen, assuming for a moment that I created a fresh branch, based against
> > 3.15, and then added the SELinux patches for 3.16 (basically the few new
> > patches that were in the ole #next branch) would that serve as a reasonable
> > basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
> > send a pull request to James to pull from this next branch into the Linux
> > Security branch for 3.17. Once 3.16 is released, I would merge that into
> > this new #next branch and continue with the next round of patches.
> >
> > FYI, more or less, the above is the process we've settled upon for all of
> > the trees that get accumulated into the Linux Security tree.
>
> Does the above work for you in linux-next? I'd like to try and resolve this
> sooner rather than later and I imagine you feel the same ...
Well, I see that James has pulled your tree, so past problems are now
moot. He has some duplicate commits in his tree now and Linus will get
a few more when he next pulls James' tree. We just need to avoid this
going forward. And given that James or Serge will, from now on, *pull*
your tree (not cherry-pick from it), things should be fine.
--
Cheers,
Stephen Rothwell [email protected]
On 06/25/2014 09:59 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> On Tue, 24 Jun 2014 14:03:08 -0400 Paul Moore <[email protected]> wrote:
>>
>> On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
>>
>> {big snip}
>>
>>> Stephen, assuming for a moment that I created a fresh branch, based against
>>> 3.15, and then added the SELinux patches for 3.16 (basically the few new
>>> patches that were in the ole #next branch) would that serve as a reasonable
>>> basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
>>> send a pull request to James to pull from this next branch into the Linux
>>> Security branch for 3.17. Once 3.16 is released, I would merge that into
>>> this new #next branch and continue with the next round of patches.
>>>
>>> FYI, more or less, the above is the process we've settled upon for all of
>>> the trees that get accumulated into the Linux Security tree.
>>
>> Does the above work for you in linux-next? I'd like to try and resolve this
>> sooner rather than later and I imagine you feel the same ...
>
> Well, I see that James has pulled your tree, so past problems are now
> moot. He has some duplicate commits in his tree now and Linus will get
> a few more when he next pulls James' tree. We just need to avoid this
> going forward. And given that James or Serge will, from now on, *pull*
> your tree (not cherry-pick from it), things should be fine.
>
I haven't pulled in Paul's tree, I merged with the latest Linus release.
On Wednesday, June 25, 2014 09:59:28 AM Stephen Rothwell wrote:
> Well, I see that James has pulled your tree, so past problems are now
> moot. He has some duplicate commits in his tree now and Linus will get
> a few more when he next pulls James' tree. We just need to avoid this
> going forward. And given that James or Serge will, from now on, *pull*
> your tree (not cherry-pick from it), things should be fine.
Okay, sorry again for the confusion, hopefully we won't have to worry about
this again.
--
paul moore
http://www.paul-moore.com
Hi James,
On Wed, 25 Jun 2014 20:51:43 +1000 James Morris <[email protected]> wrote:
>
> I haven't pulled in Paul's tree, I merged with the latest Linus release.
Ummm, yesterday your security tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
moved from commit 2fd4e6698f08 ("Merge branch 'smack-for-3.16' of
git://git.gitorious.org/smack-next/kernel into next") (which is
included in v3.16-rc1) to commit f01387d26938 ("Merge commit 'v3.15'
into next"). The commit between those 2 commits is 92953ff38ba5
("Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux
into next").
--
Cheers,
Stephen Rothwell [email protected]
On 06/26/2014 08:12 AM, Stephen Rothwell wrote:
> Hi James,
>
> On Wed, 25 Jun 2014 20:51:43 +1000 James Morris <[email protected]> wrote:
>>
>> I haven't pulled in Paul's tree, I merged with the latest Linus release.
>
> Ummm, yesterday your security tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> moved from commit 2fd4e6698f08 ("Merge branch 'smack-for-3.16' of
> git://git.gitorious.org/smack-next/kernel into next") (which is
> included in v3.16-rc1) to commit f01387d26938 ("Merge commit 'v3.15'
> into next"). The commit between those 2 commits is 92953ff38ba5
> ("Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux
> into next").
>
Ok, I thought you meant pulled in more recently.