linux-kernel - Re: linux-next: manual merge of the keys tree with the ecryptfs tree

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] [day] [month] [year] [list]

Date:   Tue, 9 Jul 2019 10:10:34 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     David Howells <dhowells@...hat.com>,
        Tyler Hicks <tyhicks@...onical.com>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        YueHaibing <yuehaibing@...wei.com>
Subject: Re: linux-next: manual merge of the keys tree with the ecryptfs
 tree

Hi all,

On Wed, 26 Jun 2019 14:28:38 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> 
> Today's linux-next merge of the keys tree got a conflict in:
> 
>   fs/ecryptfs/keystore.c
> 
> between commit:
> 
>   29a51df0609c ("ecryptfs: remove unnessesary null check in ecryptfs_keyring_auth_tok_for_sig")
> 
> from the ecryptfs tree and commit:
> 
>   79512db59dc8 ("keys: Replace uid/gid/perm permissions checking with an ACL")
> 
> from the keys tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc fs/ecryptfs/keystore.c
> index 216fbe6a4837,ba382f135918..000000000000
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@@ -1611,10 -1610,10 +1611,10 @@@ int ecryptfs_keyring_auth_tok_for_sig(s
>   {
>   	int rc = 0;
>   
> - 	(*auth_tok_key) = request_key(&key_type_user, sig, NULL);
> + 	(*auth_tok_key) = request_key(&key_type_user, sig, NULL, NULL);
>  -	if (!(*auth_tok_key) || IS_ERR(*auth_tok_key)) {
>  +	if (IS_ERR(*auth_tok_key)) {
>   		(*auth_tok_key) = ecryptfs_get_encrypted_key(sig);
>  -		if (!(*auth_tok_key) || IS_ERR(*auth_tok_key)) {
>  +		if (IS_ERR(*auth_tok_key)) {
>   			printk(KERN_ERR "Could not find key with description: [%s]\n",
>   			      sig);
>   			rc = process_request_key_err(PTR_ERR(*auth_tok_key));

I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped