[PATCH v3 net-next] ptp: only allow phase values lower than 1 period

* [PATCH v3 net-next] ptp: only allow phase values lower than 1 period
@ 2020-08-05  0:10 Vladimir Oltean
  2020-08-05  2:05 ` Richard Cochran
  2020-08-05 19:07 ` David Miller
  0 siblings, 2 replies; 4+ messages in thread
From: Vladimir Oltean @ 2020-08-05  0:10 UTC (permalink / raw)
  To: kuba, davem, netdev; +Cc: richardcochran, jacob.e.keller

The way we define the phase (the difference between the time of the
signal's rising edge, and the closest integer multiple of the period),
it doesn't make sense to have a phase value equal or larger than 1
period.

So deny these settings coming from the user.

Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
Changes in v3:
Adjust the comments to cover the equality case.

Changes in v2:
Be sure to also deny the case where the period is equal to the phase.
This represents a 360 degree offset, which is equivalent to a phase of
zero, so it should be rejected on the grounds of having a modulo
equivalent as well.

 drivers/ptp/ptp_chardev.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index e0e6f85966e1..af3bc65c4595 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -218,6 +218,19 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
 					break;
 				}
 			}
+			if (perout->flags & PTP_PEROUT_PHASE) {
+				/*
+				 * The phase should be specified modulo the
+				 * period, therefore anything equal or larger
+				 * than 1 period is invalid.
+				 */
+				if (perout->phase.sec > perout->period.sec ||
+				    (perout->phase.sec == perout->period.sec &&
+				     perout->phase.nsec >= perout->period.nsec)) {
+					err = -ERANGE;
+					break;
+				}
+			}
 		} else if (cmd == PTP_PEROUT_REQUEST) {
 			req.perout.flags &= PTP_PEROUT_V1_VALID_FLAGS;
 			req.perout.rsv[0] = 0;
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread