Re: regression: Bug 215601 - gcc segv at startup on ia64
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Magnus Groß <magnus.gross@xxxxxxxxxxxxxx>
- Subject: Re: regression: Bug 215601 - gcc segv at startup on ia64
- From: Kees Cook <keescook@xxxxxxxxxxxx>
- Date: Mon, 28 Feb 2022 12:41:47 -0800
- Cc: akpm@xxxxxxxxxxxxxxxxxxxx, anthony.yznaga@xxxxxxxxxx, glaubitz@xxxxxxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, matoro_bugzilla_kernel@xxxxxxxxx, matoro_mailinglist_kernel@xxxxxxxxx, regressions@xxxxxxxxxxxxx, regressions@xxxxxxxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx
- In-reply-to: <Yhyn9cjDV8XfXLHm@fractal.localdomain>
- References: <202202260344.63C15C3356@keescook> <Yhyn9cjDV8XfXLHm@fractal.localdomain>
On Mon, Feb 28, 2022 at 11:46:13AM +0100, Magnus Groß wrote:
> > 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?
I don't think so, and I need to have a "minimal change" to fix this so
it's more obviously correct.
And, apologies, I failed to Cc you on this patch:
https://lore.kernel.org/linux-hardening/20220228194613.1149432-1-keescook@xxxxxxxxxxxx/
--
Kees Cook
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]