linux-kernel - Re: Resolved merge conflicts in next-creds

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: <alpine.LRH.1.10.0808120751001.10017@tundra.namei.org>
Date:	Tue, 12 Aug 2008 07:53:40 +1000 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
cc:	David Howells <dhowells@...hat.com>, linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Steve French <sfrench@...ibm.com>
Subject: Re: Resolved merge conflicts in next-creds

On Mon, 11 Aug 2008, Stephen Rothwell wrote:

> Hi David, James,
> 
> On Mon, 11 Aug 2008 10:16:02 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > I have a plan for getting rid of these - I will start on it today or
> > tomorrow.
> 
> As a start, can you create a patch (or patches) that does just the
> include/linux/creds.h part of commits
> 785af0f385cd424d4b40908bf0e467df3dc05434 ("CRED: Change current->fs[ug]id
> to current_fs[ug]id()") and f4d399d40debd14b22967153294b94087cbcf789
> ("CRED: Wrap most current->e?[ug]id and some task->e?[ug]id") and send
> that to Linus explaining to him the reason we want these in 2.6.27
> (Something like "The introduction of the credentials API in 2.6.28
> requires the abstracting of access to some fields in the task structure.
> This change introduces trivial noop version of the desired accessors so
> that other subsystems can start to be converted over.").  This
> explanation should go in the commit message.
> 
> After he has put those patch(es) in, you could break up the rest of those
> two commits by subsystem/arc/driver (or something) and ask the
> appropriate maintainers to apply them and send them to Linus (with a
> similar explanation) (or just ask them to ACK such patches so you can
> send them upstream).
> 
> Hopefully this way ww will avoid a lot of the merge pain during the next
> merge window and the other subsystems can continue on in their
> development.
> 
> How does that sound?

We have tried this approach thus far without success, although perhaps now 
the code has been in linux-next and you've come to the same conclusion, we 
could try again.

David, if you want to make a minimal API-only patch set, I'll can stage it 
and push to Linus.


- James
-- 
James Morris
<jmorris@...ei.org>
--
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/