[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200805001047.1372299-1-olteanv@gmail.com>
Date: Wed, 5 Aug 2020 03:10:47 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org
Cc: richardcochran@...il.com, jacob.e.keller@...el.com
Subject: [PATCH v3 net-next] ptp: only allow phase values lower than 1 period
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@...il.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
Powered by blists - more mailing lists