linux-kernel - Re: linux-next: manual merge of the crypto tree with the kbuild 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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 11 Apr 2017 16:51:08 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>
Subject: Re: linux-next: manual merge of the crypto tree with the kbuild tree

Hi Linus, Stephen,

2017-04-11 14:02 GMT+09:00 Stephen Rothwell <sfr@...b.auug.org.au>:
> Hi Herbert,
>
> On Tue, 11 Apr 2017 10:42:15 +0800 Herbert Xu <herbert@...dor.apana.org.au> wrote:
>>
>> Actually the patch in the kbuild tree should be reverted because
>> we have now increased the in-kernel length limit and this must not
>> be directly exposed to user-space or it'll break compatibility.
>
> So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported
> header but 128 in the kernel header?  In which case the kbuild patch
> needs to be changed not removed.  Or the merge resolution needs to be
> cleverer.

In the development cycle for 4.12-rc1, some patches
from Kbuild cause conflicts in linux-next from time to time.

The patches in linux-kbuild/uapi branch touched some files
in other subsystems because they are prerequisites
to export the uapi directory as-is.

Most of the conflicts are trivial to fix-up,
and they are handled nicely thanks to Stephen.

But, today's one is hard:
https://lkml.org/lkml/2017/4/10/1208

As Herbert suggested, the easiest way is to revert
c394d1683, but reverting it will cause an error in Kbuild tree:
.../linux/cryptouser.h:58:16: error: ‘CRYPTO_MAX_ALG_NAME’ undeclared
here (not in a function)

So, I will rebase the linux-kbuild/uapi branch onto Linus's tree
(resolving all conflicts) after crypto changes are pulled
during the next merge window.

Then, I will send the kbuild/uapi pull request so that Linus can pull
it with no (less) conflicts.

The commit c394d1683 will effectively be dropped.

I think this is the cleanest way to fix the issue.

Please let me know if you see problems in this plan.

Thanks.

-- 
Best Regards
Masahiro Yamada