linux-kernel - Re: [GIT PULL] Namespace file descriptors for 2.6.40

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1306048393.4092.8.camel@mulgrave.site>
Date:	Sun, 22 May 2011 11:13:13 +0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Linux Containers <containers@...ts.osdl.org>,
	netdev@...r.kernel.org, Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [GIT PULL] Namespace file descriptors for 2.6.40

On Sat, 2011-05-21 at 17:33 -0700, Eric W. Biederman wrote:
> Linus Torvalds <torvalds@...ux-foundation.org> writes:
> 
> > On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
> > <ebiederm@...ssion.com> wrote:
> >>
> >> In a hopeless quest to avoid conflicts when merging a new system call
> >> and wiring it up I have pulled in bits of net-next and the parisc tree.
> >> You have already pulled the net-next bits.  The parisc bits in my tree
> >> are:
> >
> > Ok, this just means that I won't pull from you.
> 
> Sure.  I will try to be a little more patient and resend the pull
> request after James has sent the pull request for the parisc tree.
> At which point the only unique changes in my tree will be mine.

Right ... effectively you're running a postmerge tree, since you now
depend on bits I have in the parisc tree.

Traditionally, the arch trees tend to go a bit later because they wait
to see if there's any fallout from x86; but this time, I think it looks
OK, so I've sent the pull request:

http://marc.info/?l=linux-parisc&m=130604805417277

As soon as that's in, you should be good to go.

James


> > It's that simple. We don't do this. Ever.
> 
> Hah. I seem to remember bits of pulling from non-rebasing trees being ok
> in well defined contexts.  This seems like one.  Especially when you
> have checked with the maintainers.
> 
> Plus all of the parisc bits in addition to being in the linux-next
> are trivially correct.
> 
> > Why the hell did you even worry about wiring up parisc system calls?
> > That's not your job.
> 
> Because in general it is the job of he who changes something to fix up
> every possible place.
> 
> Now maybe I went a little too far in trying to resolve the conflicts,
> but I did check with the David Miller and James Bottomley and they knew
> what I was doing.
> 
> Quite honestly adding system calls is a mess that know one seems to
> know how to do right.  So I flipped a coin and took a stab at it.

Right, the solution is reasonable and means linux-next doesn't have to
carry a conflict resolution patch for this.  It also means we agree on
the syscall numbering ...

The only real mistake was not waiting for the merge sequence: the base
trees have to go first before you can push a postmerge tree.

James


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