From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] posix-clock: drop code duplication using compat_ptr_ioctl
Date: Tue, 21 Jan 2025 13:48:23 +0100 [thread overview]
Message-ID: <bb07ee50-a686-420e-abe8-0fce852086a1@t-8ch.de> (raw)
In-Reply-To: <Z49DPK2FGkOu_FA6@grain>
Hi Cyrill!
On 2025-01-21 09:48:28+0300, Cyrill Gorcunov wrote:
> On Mon, Jan 20, 2025 at 11:41:26PM +0100, Thomas Weißschuh wrote:
> > >
> > > > +#ifdef CONFIG_COMPAT
> > > > +long ptp_compat_ioctl(struct posix_clock_context *pccontext, unsigned int cmd,
> > > > + unsigned long arg)
> > > > +{
> > > > + switch (cmd) {
> > > > + case PTP_ENABLE_PPS:
> > > > + case PTP_ENABLE_PPS2:
> > > > + /* These take in scalar arg, do not convert */
> > > > + break;
> > > > + default:
> > > > + arg = (unsigned long)compat_ptr(arg);
> > >
> > > Here^^^
> > The key is to only call compat_ptr() on *pointers*.
> > Scalars have to be passed through unmodified.
> > For ptp_ioctl(), PTP_ENABLE_PPS and PTP_ENABLE_PPS2 take such scalars,
> > which is why those two *can not* use compat_ptr().
> > compat_ptr_ioctl() however passes all arguments through compat_ptr().
>
> 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.
It's indeed an edge case.
Personally I prefer the correct solution.
> > Admittedly it's quite unlikely anybody would pass a value where it would
> > make a difference in practice. But if we fix this now, it might as well
> > be correct.
>
> Sure, I see your point. Thanks for comments!
Let's see what the maintainers prefer :-)
Thomas
next prev parent reply other threads:[~2025-01-21 12:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-20 22:10 Cyrill Gorcunov
2025-01-20 22:22 ` Thomas Weißschuh
2025-01-20 22:30 ` Cyrill Gorcunov
2025-01-20 22:41 ` Thomas Weißschuh
2025-01-21 6:48 ` Cyrill Gorcunov
2025-01-21 12:48 ` Thomas Weißschuh [this message]
2025-01-21 18:16 ` Cyrill Gorcunov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb07ee50-a686-420e-abe8-0fce852086a1@t-8ch.de \
--to=linux@weissschuh.net \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®