[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM4PR12MB855850D05B3332C4DDA0D76CBEFA2@DM4PR12MB8558.namprd12.prod.outlook.com>
Date: Wed, 19 Feb 2025 09:45:38 +0000
From: Wojtek Wasko <wwasko@...dia.com>
To: Thomas Gleixner <tglx@...utronix.de>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>
CC: "richardcochran@...il.com" <richardcochran@...il.com>,
"vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>, "kuba@...nel.org"
<kuba@...nel.org>, "horms@...nel.org" <horms@...nel.org>,
"anna-maria@...utronix.de" <anna-maria@...utronix.de>, "frederic@...nel.org"
<frederic@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>
Subject: RE: [PATCH net-next v3 2/3] ptp: Add file permission checks on PHCs
On Mon, Feb 17 2025 at 21:24, Thomas Gleixner wrote:
> > One limitation
> > remains: querying the adjusted frequency of a PTP device (using
> > adjtime() with an empty modes field) is not supported for chardevs
> > opened without WRITE permissions, as the POSIX layer mandates WRITE
> > access for any adjtime operation.
>
> That's a fixable problem, no?
Absolutely, but to be honest I wasn't sure about how to properly change
the access check in adjtime given it's a "generic" API. I ended up with
something along the lines of:
if (tx->modes & ~(ADJ_NANO | ADJ_MICRO))
/* require WRITE */
being that ADJ_NANO and ADJ_MICRO by themselves don't mean the clock will
be modified. So the modes field is not really "empty" per se and the check
becomes less self-explanatory.
But then maybe I'm overthinking it. If you think the above modes check is
the right way to go, I'll send a v4 (using the opportunity to add the
Reviewed-By and Acked-By tags from v2 I missed in v3 - I'm new to kernel
development, sorry).
Thanks,
W
Powered by blists - more mailing lists