linux-kernel - Re: perf tools build broken after v5.1-rc1

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]

Message-ID: <506c2df7-4088-9a18-91c0-c86b944714da@synopsys.com>
Date:   Thu, 2 May 2019 10:10:15 -0700
From:   Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
CC:     Arnd Bergmann <arnd@...db.de>, Rich Felker <dalias@...c.org>,
        "Arnaldo Carvalho de Melo" <acme@...hat.com>,
        lkml <linux-kernel@...r.kernel.org>,
        "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
        "Jiri Olsa" <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
        arcml <linux-snps-arc@...ts.infradead.org>
Subject: Re: perf tools build broken after v5.1-rc1

On 5/2/19 9:41 AM, Arnaldo Carvalho de Melo wrote:
>> While this takes care of immediate issues, for the long term, are you open to idea
>> of removing the header duplicity.
>
> In the beginning we used the kernel headers directly, then, acting on
> advice/complaints from Linus about tooling breaking when changes were
> made in the kernel sources we were using directly, we moved to have
> copies and notice when things change so that we could think about what
> changed and act accordingly, without putting the burden to the kernel
> developers to keep tools/ building, I want to keep it that way.

Sure, and the reduced duplicity I propose doesn't change that in any way. The onus
is still on perf maintainers to copy over any unistd changes - in the new regime,
it will be just lesser since we only care about a handful of syscalls, not the
entire unistd.


> Now you say, validly, that there are bits that are designed to be used
> by userspace, so for those, we should go back to not copying and using
> it direcly, elliminating the duplicity you don't like.

Indeed.

> I don't know, I'm used to the duplicity and the checks,

:-)

> not breaking
> tools even when kernel developers make mistakes in the UAPI headers,

Not sure how replacing the full header with just a small hunk, out of same header
out-of-line will change anything or cause any more breakage.

> tools/perf is self container wrt the latest and greatest stuff not
> present in older environments, and the onus is on perf developers to do
> the sync.

Sure it is, I'm proposing to make their work less, no more.


> This specific issue here happened because I made a mistake, which I
> fixed when reported,

Exactly, it was a genuien mistake with a super prompt followup - your promptness
is really appreciated and emulation worthy for other maintainers including myself ;-)

> now I have three containers for cross building for
> ARC, two versions for the uCLibc based toolchain, one for the glibc one,
> libnuma, elfutils and zlib are cross build there, so should make it less
> likely problems like this will happen again.

Ok, well lets leave it at that for now then.


>> We could use a "less evil" idiom of copying only the minimal bits (since the sync
>> onus remains one way or the other)
>> e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects
>  
>> #ifdef __NR_xx
>> # if defined (__arch_y__)
>>
>> # elif defined (__arch_z__)
>>
>> # endif
>> #endif

Thx,
-Vineet