linux-kernel - Re: [PATCH] posix-clock: drop code duplication using compat_ptr

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: <Z4_kbrqCQamjSYVQ@grain>
Date: Tue, 21 Jan 2025 21:16:14 +0300
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	Frederic Weisbecker <frederic@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] posix-clock: drop code duplication using compat_ptr_ioctl

On Tue, Jan 21, 2025 at 01:48:23PM +0100, Thomas Weißschuh wrote:
...
> > Yeah, and the PTP_ENABLE_PPS/PTP_ENABLE_PPS2 consider `arg` as 0/1 flip-flop
> > so compat_ptr won't screw it. So I personally would rather stick with a more
> > simple code (taking into account that ptp is the only real underlied device
> > so far sitting in code for so long).
> 
> It is valid to pass any value to these ioctls, not only booleans.
> On s390 the value 0x80000000 aka BIT(31) would interpreted as "true" by
> a native 32bit kernel and "false" by a 64bit kernel in compat mode.

Heh, indeed, I managed to forget that s390 clears the top bit and been scratching
my head thinking of how losing the sign bit is possible)

> 
> It's indeed an edge case.
> Personally I prefer the correct solution.

The correct solution is better, without a doubt. Thanks for looking into the
patch, Thomas!