linux-kernel - Re: [GIT PULL 2/4] Kbuild updates for v4.21 part2

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, 8 Jan 2019 08:42:57 +0800
From:   Changbin Du <changbin.du@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Changbin Du <changbin.du@...il.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [GIT PULL 2/4] Kbuild updates for v4.21 part2

On Mon, Jan 07, 2019 at 01:32:56PM +0900, Masahiro Yamada wrote:
> (+CC Changbin Du, Arnd Bergmann)
> 
> 
> 
[...]
> > This branch already added a couple of extra inline markers just to
> > make code work reasonably. How many tens (or hundreds) got missed just
> > because the build still works, but the lack of inlining means that we
> > generate completely garbage code?
> 
> 
> I do not have the exact number, but
> my impression was "not so many".
> 
> Changbin and Arnd might have better insight.
> They were trying to eliminate potential problems beforehand.
> 
> For example,
> 7e17916b
> 412dd15c
> 08813e0e
> 
Yes, the case is not so many. At the beginning, I also thought this could
require incredible change. But after trying, just found it is not so bad. I have
a couple of patches to fix the remaing warnings which adds 'inline' or '_init'
markers for related functions.

I promise that all warnings get fixed with new version. And since I only have
coressponding setup to fully test x86 and ARM platform, I think we could make
this new option depend on x86 or arm temparaly so untested platforms will
not complain anymore.

Linus, is this good for you? Thank you for revewing.

> 
> 
> 
> > I'm going to skip this pull request.
> >
> > We have basically always required a certain level of competence from
> > the compiler, and this basically says that the compiler can do stupid
> > things and we'd have to fix those stupidities by hand.
> >
> >              Linus
> 
> 
> 
> -- 
> Best Regards
> Masahiro Yamada

-- 
Cheers,
Changbin Du