Re: linux-next: unusual update of the security tree

2012-12-13 Thread James Morris
On Thu, 13 Dec 2012, Stephen Rothwell wrote:

> Hi James,
> 
> On Fri, 7 Dec 2012 10:21:31 +1100 (EST) James Morris  
> wrote:
> >
> > On Thu, 6 Dec 2012, Linus Torvalds wrote:
> > 
> > > Have people pulled that thing into anything else? Because quite
> > > frankly, I think it's unsalvageable except with a rebase.
> > 
> > AFAIK, only developers such as Casey will have pulled it for development 
> > purposes.
> > 
> > And sorry, I should be checking the trees I pull from more carefully.
> 
> Are you going to fix this before asking Linus to pull?

Yes.

-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-12-12 Thread Stephen Rothwell
Hi James,

On Fri, 7 Dec 2012 10:21:31 +1100 (EST) James Morris  wrote:
>
> On Thu, 6 Dec 2012, Linus Torvalds wrote:
> 
> > Have people pulled that thing into anything else? Because quite
> > frankly, I think it's unsalvageable except with a rebase.
> 
> AFAIK, only developers such as Casey will have pulled it for development 
> purposes.
> 
> And sorry, I should be checking the trees I pull from more carefully.

Are you going to fix this before asking Linus to pull?
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpu7LR2jHhBy.pgp
Description: PGP signature


Re: linux-next: unusual update of the security tree

2012-12-06 Thread Casey Schaufler
On 12/6/2012 3:21 PM, James Morris wrote:
> On Thu, 6 Dec 2012, Linus Torvalds wrote:
>
>> Have people pulled that thing into anything else? Because quite
>> frankly, I think it's unsalvageable except with a rebase.
> AFAIK, only developers such as Casey will have pulled it for development 
> purposes.
>
> And sorry, I should be checking the trees I pull from more carefully.

I have messed up and believe that I understand my error and the
impact that it has had on others. I also believe that I understand
what I should be doing henceforth. Once I get the word from James
I will rebase my tree from his. I will stop doing merges except as
recommended.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-12-06 Thread James Morris
On Thu, 6 Dec 2012, Linus Torvalds wrote:

> Have people pulled that thing into anything else? Because quite
> frankly, I think it's unsalvageable except with a rebase.

AFAIK, only developers such as Casey will have pulled it for development 
purposes.

And sorry, I should be checking the trees I pull from more carefully.



- James
-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-12-06 Thread Stephen Rothwell
Hi James,

On Thu, 6 Dec 2012 08:25:21 -0800 Linus Torvalds 
 wrote:
>
> Have people pulled that thing into anything else? Because quite
> frankly, I think it's unsalvageable except with a rebase.

So to be explicit, I think you need to do this:

- tell as many people as possible that you are going to rebase
  your tree
- reset your tree back to the point just before you pulled Casey's
  tree (3f0cc6ae8662).
- Casey needs to rebase his tree on top of yours
- then after Casey has tested his tree again you can repull his
  new tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpG8Fi89BoBA.pgp
Description: PGP signature


Re: linux-next: unusual update of the security tree

2012-12-06 Thread Linus Torvalds
On Thu, Dec 6, 2012 at 5:25 AM, James Morris  wrote:
> Any suggestions on how to fix this?  That branch is public, and what
> people use to develop against, so I can't rebase it.

Quite frankly, I really am not going to pull that. It has random crazy
merges for no reason what-so-ever. This is *exactly* the kind of stuff
I used to speak out against years ago, and I thought we had long since
put behind us. Do

git fetch 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
next
gitk ..FETCH_HEAD

from mainline to see what I'm talking about. It has all those random
merges interspersed with random sporadic development. This is not how
we make history make sense.

It looks like Casey has for the last year+ just had his own tree, done
his own thing, and then pulled from the 'next' branch of security at
random points to intermix his occasional commits with everything
else.So now all his sporadic commits are randomly intermixed together
with *everything* else that happened over the last year. It's kind of
the epitome of not-a-feature-branch.

There are 26 "normal" commits spread out over the year, coupled with
22 merges that have been done bi-weekly or something, and have
altogether brought in 13 *thousand* commits that have very little to
do with the 26 commits that are new work. And with many of the merges
done despite that development tree having *no* development in it of
its own, so you have those repeated "let's merge upstream code" pulls
that only add upstream code with no development in between.

This is the kind of development that should be kept private, and maybe
using a "git pull --rebase" to maintain the private commits on top of
whatever upstream. NOT be used to say "ok, I now have more than a year
of messy development history of 22 changes randomly interspersed with
the thirteen thousand commits that went into mainline during that
year+ time".

Or it should just have been a development branch that only did its own
development and never pulled from upstream.

Have people pulled that thing into anything else? Because quite
frankly, I think it's unsalvageable except with a rebase.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-12-06 Thread James Morris
Any suggestions on how to fix this?  That branch is public, and what 
people use to develop against, so I can't rebase it.



On Wed, 28 Nov 2012, Stephen Rothwell wrote:

> Hi Casey,
> 
> On Tue, 27 Nov 2012 15:45:17 -0800 Casey Schaufler  
> wrote:
> >
> > On 11/27/2012 3:16 PM, Stephen Rothwell wrote:
> > 
> > > The security tree
> > > (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> > > looks a bit strange today ... It appears to have been created by Casey
> > > Schaufler (cc'd) and contains some quite old commits and back merges of
> > > your tree.  I *guess* you have merged in Casey's tree after he merged in
> > > your tree from yesterday.
> > 
> > I *thought* that I had used the same procedures that worked before.
> > In fact, I still do think that, but if it's a problem I can purge my
> > smack-next tree and start over.
> > 
> > James, the two changes that came from smack-next are pretty minor. I
> > don't think you should hesitate to back them out if that helps.
> 
> This is the shortlog for the changes in the security tree between
> yesterday and today;
> 
> Casey Schaufler (32):
>   Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced a change 
> to the way rule lists are handled and reported in the smackfs filesystem. 
> One of the issues addressed had to do with the termination of read 
> requests on /smack/load. This change introduced a error in /smack/cipso, 
> which shares some of the same list processing code.
>   Revert "Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced"
>   Smack: smackfs cipso seq read repair
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Smack: recursive tramsmute
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Smack: allow for significantly longer Smack labels v4
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Smack: fix smack_new_inode bogosities
>   Smack: Maintainer Record
>   Smack: onlycap limits on CAP_MAC_ADMIN
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Smack: user access check bounds
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Smack: remove task_wait() hook.
>   Smack: setprocattr memory leak fix
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'for-1209'
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>   Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security 
> into for-1211
>   Smack: use select not depends in Kconfig
>   Smack: create a sysfs mount point for smackfs
> 
> Rafal Krypa (2):
>   Smack: don't show empty rules when /smack/load or /smack/load2 is read
>   Smack: implement revoking all rules for a subject label
> 
> Tetsuo Handa (1):
>   gfp flags for security_inode_alloc()?
> 
> It's a bit of a mess :-(
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 

-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-12-03 Thread James Morris
On Tue, 27 Nov 2012, Linus Torvalds wrote:

> On Nov 27, 2012 4:01 PM, "Stephen Rothwell"  wrote:
> >
> > Hi
> > This is the shortlog for the changes in the security tree between
> > yesterday and today;
> 
> This is an excellent example of the kind of tree I will not pull from.
> 
> There are more merges than actual work. No way, Jose.

Ugh, I somehow missed this thread last week.


-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-11-27 Thread Stephen Rothwell
Hi Casey,

On Tue, 27 Nov 2012 15:45:17 -0800 Casey Schaufler  
wrote:
>
> On 11/27/2012 3:16 PM, Stephen Rothwell wrote:
> 
> > The security tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> > looks a bit strange today ... It appears to have been created by Casey
> > Schaufler (cc'd) and contains some quite old commits and back merges of
> > your tree.  I *guess* you have merged in Casey's tree after he merged in
> > your tree from yesterday.
> 
> I *thought* that I had used the same procedures that worked before.
> In fact, I still do think that, but if it's a problem I can purge my
> smack-next tree and start over.
> 
> James, the two changes that came from smack-next are pretty minor. I
> don't think you should hesitate to back them out if that helps.

This is the shortlog for the changes in the security tree between
yesterday and today;

Casey Schaufler (32):
  Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced a change 
to the way rule lists are handled and reported in the smackfs filesystem. 
One of the issues addressed had to do with the termination of read requests 
on /smack/load. This change introduced a error in /smack/cipso, which 
shares some of the same list processing code.
  Revert "Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced"
  Smack: smackfs cipso seq read repair
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Smack: recursive tramsmute
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Smack: allow for significantly longer Smack labels v4
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Smack: fix smack_new_inode bogosities
  Smack: Maintainer Record
  Smack: onlycap limits on CAP_MAC_ADMIN
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Smack: user access check bounds
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Smack: remove task_wait() hook.
  Smack: setprocattr memory leak fix
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'for-1209'
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
  Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security 
into for-1211
  Smack: use select not depends in Kconfig
  Smack: create a sysfs mount point for smackfs

Rafal Krypa (2):
  Smack: don't show empty rules when /smack/load or /smack/load2 is read
  Smack: implement revoking all rules for a subject label

Tetsuo Handa (1):
  gfp flags for security_inode_alloc()?

It's a bit of a mess :-(
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpax5Yk1aUq8.pgp
Description: PGP signature


Re: linux-next: unusual update of the security tree

2012-11-27 Thread Stephen Rothwell
On Tue, 27 Nov 2012 15:30:31 -0800 Linus Torvalds 
 wrote:
>
> On Tue, Nov 27, 2012 at 3:28 PM, Stephen Rothwell  
> wrote:
> >
> > If that is what happened, it may be worth always using the --no-ff flag
> > to git merge/pull to make sure that the top commit on your tree always
> > has you as the committer (and maybe SOB).
> >
> > Linus, does that make sense in general for maintainers?
> 
> No. That just hides the real problem - back-merges of random points in 
> history.
> 
> Don't do them, people. EVER.

I was also thinking about the case where a developer does work based on
the maintainer's published tree and then the maintainer pulls that work
sometime later (when his published tree has not been updated in the mean
time).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp0tmOLnXPo4.pgp
Description: PGP signature


Re: linux-next: unusual update of the security tree

2012-11-27 Thread Casey Schaufler
On 11/27/2012 3:16 PM, Stephen Rothwell wrote:

> Hi James,
>
> The security tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> looks a bit strange today ... It appears to have been created by Casey
> Schaufler (cc'd) and contains some quite old commits and back merges of
> your tree.  I *guess* you have merged in Casey's tree after he merged in
> your tree from yesterday.

I *thought* that I had used the same procedures that worked before.
In fact, I still do think that, but if it's a problem I can purge my
smack-next tree and start over.

James, the two changes that came from smack-next are pretty minor. I
don't think you should hesitate to back them out if that helps.


>
> Just for your consideration.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-11-27 Thread Linus Torvalds
On Tue, Nov 27, 2012 at 3:28 PM, Stephen Rothwell  wrote:
>
> If that is what happened, it may be worth always using the --no-ff flag
> to git merge/pull to make sure that the top commit on your tree always
> has you as the committer (and maybe SOB).
>
> Linus, does that make sense in general for maintainers?

No. That just hides the real problem - back-merges of random points in history.

Don't do them, people. EVER.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: unusual update of the security tree

2012-11-27 Thread Stephen Rothwell
Hi James,

On Wed, 28 Nov 2012 10:16:35 +1100 Stephen Rothwell  
wrote:
>
> The security tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> looks a bit strange today ... It appears to have been created by Casey
> Schaufler (cc'd) and contains some quite old commits and back merges of
> your tree.  I *guess* you have merged in Casey's tree after he merged in
> your tree from yesterday.

If that is what happened, it may be worth always using the --no-ff flag
to git merge/pull to make sure that the top commit on your tree always
has you as the committer (and maybe SOB).

Linus, does that make sense in general for maintainers?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpAZjkllgULg.pgp
Description: PGP signature