linux-kernel - Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64

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:   Sun, 18 Dec 2016 12:38:23 +0530
From:   Yury Norov <ynorov@...iumnetworks.com>
To:     <arnd@...db.de>, <catalin.marinas@....com>
CC:     <schwidefsky@...ibm.com>, <heiko.carstens@...ibm.com>,
        <pinskia@...il.com>, <broonie@...nel.org>,
        <joseph@...esourcery.com>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <bamvor.zhangjian@...wei.com>, <szabolcs.nagy@....com>,
        <klimov.linux@...il.com>, <Nathan_Lynch@...tor.com>,
        <agraf@...e.de>, <Prasun.Kapoor@...iumnetworks.com>,
        <kilobyte@...band.pl>, <geert@...ux-m68k.org>,
        <philipp.tomsich@...obroma-systems.com>,
        <manuel.montezelo@...il.com>, <linyongting@...wei.com>,
        <maxim.kuvyrkov@...aro.org>, <davem@...emloft.net>,
        <zhouchengming1@...wei.com>, <cmetcalf@...hip.com>
Subject: Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64

On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode, and as supporting work,
> introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> existing 32-bit architectures but disabled for new arches (so 64-bit
> off_t is is used by new userspace).
> 
> This version is based on kernel v4.9-rc1.  It works with glibc-2.24,
> and tested with LTP.

Hi Arnd, Catalin

For last few days I'm trying to rebase this series on current master,
and I see significant conflicts and regressions. In fact, every time
I rebase on next rc1, I feel like I play a roulette.

This is not a significant problem now because it's almost for sure
that this series will not get into 4.10, for reasons not related to
kernel code. And I have time to deal with regressions. But in general,
I'd like to try my patches on top of other candidates for next merge
window. I cannot read all emails in LKML, but I can easily detect
problems and join to the discussion at early stage if I see any problem.

This is probably a noob question, and there are well-known branches,
like Andrew Morton's one. But at this stage it's very important to
have this series prepared for merge, and I'd prefer to ask about it.

Yury.