linux-kernel - Re: regression: Bug 215601 - gcc segv at startup on ia64

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]

Date:   Mon, 28 Feb 2022 11:46:13 +0100
From:   Magnus Groß <magnus.gross@...h-aachen.de>
To:     <keescook@...omium.org>
CC:     <akpm@...ux-foundation.org>, <anthony.yznaga@...cle.com>,
        <glaubitz@...sik.fu-berlin.de>, <linux-fsdevel@...r.kernel.org>,
        <linux-ia64@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <matoro_bugzilla_kernel@...oro.tk>,
        <matoro_mailinglist_kernel@...oro.tk>, <regressions@...mhuis.info>,
        <regressions@...ts.linux.dev>, <viro@...iv.linux.org.uk>
Subject: Re: regression: Bug 215601 - gcc segv at startup on ia64

> When the kernel tries to map these with a combined allocation, it asks
> for a giant mmap of the file, but the file is, of course, not at all
> that large, and the mapping is rejected.

> So... I'm trying to think about how best to deal with this. If I or
> anyone else can't think of an elegant solution, I'll send a revert for
> the offending patch next week.

Shouldn't we just be able to patch total_mapping_size() again to instead
sum up all p_memsz fields, instead of comparing minimum and maximum
p_vaddr?

Runtime complexity would be the same as we are iterating through all
segments already anyway. And I would also argue that is the behaviour
that one wanted to see in that function anyway.

If you agree with this, I can post a patch, but I would need to know
what tree to base it on to avoid merge conflicts with the just merged
patch from Alexey.

--
Magnus