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: <20080811153536.02ac0561.sfr@canb.auug.org.au>
Date:	Mon, 11 Aug 2008 15:35:36 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	James Morris <jmorris@...ei.org>
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

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?
-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au
http://www.canb.auug.org.au/~sfr/

Content of type "application/pgp-signature" skipped