linux-kernel - Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F

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]

Message-ID: <20210413154646.GC27287@lst.de>
Date:   Tue, 13 Apr 2021 17:46:46 +0200
From:   Christoph Hellwig <hch@....de>
To:     Helge Deller <deller@....de>
Cc:     Christoph Hellwig <hch@....de>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        "David S. Miller" <davem@...emloft.net>,
        Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
        linux-mips@...r.kernel.org
Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64
 in fcntl.h

On Tue, Apr 13, 2021 at 05:43:18PM +0200, Helge Deller wrote:
> On 4/12/21 10:55 AM, Christoph Hellwig wrote:
>> The F_GETLK64/F_SETLK64/F_SETLKW64 commands are only implemented for
>> 32-bit syscall APIs, but we also need them for compat handling on 64-bit
>> kernels.
>
> Ok.
>
>> Given that redefining them is rather error prone, as shown by parisc
>> getting the opcodes wrong currently, just use the existing definitions
>> for the compat handling.
>
> Can you please show me where parisc gets it currently wrong?
> I'm somehow blind to see it and of course I'd like to fix it in
> stable kernel series if that's true...

Looking again I think my comment was wrong, I thought parisc would
fall back to the asm-generic version with different code points for
the compat case, but parisc actually already defines the constants
unconditionally like this patch does for everyone else.  So I'll
retract that part of the comment.