Shrikanth Kamath
2018-09-19 22:40:24 UTC
Referring to the following snippet (MFC 309148 in stable/11)in the function
callout_when in kern_timeout.c,
@@ -981,6 +981,8 @@ callout_when(sbintime_t sbt, sbintime_t precision, int
flags,
spinlock_exit();
#endif
#endif
+ if (cold && to_sbt == 0)
+ to_sbt = sbinuptime();
if ((flags & C_HARDCLOCK) == 0)
to_sbt += tick_sbt;
} else
If someone were to use msleep during the window where system has reset
"cold" to zero post SI_SUB_CONFIGURE and before clocks are available
(after SI_SUB_CLOCKS is processed) then msleep which default has
C_HARDCLOCK set would get a wrong timeout set which would lead to erroneous
EWOULDBLOCK return from sleepq_check_timeout.
In my scenario the value of DPCPU_GET(hardclocktime) which is referenced in
callout_when was zero hence to_sbt was zero but the 'adjustment' for that
failed because the above check is doing a if(cold && to_sbt) to do that.
Should the check be just if (to_sbt == 0) then set to_sbt to sbinuptime?
--
Shrikanth R K
callout_when in kern_timeout.c,
@@ -981,6 +981,8 @@ callout_when(sbintime_t sbt, sbintime_t precision, int
flags,
spinlock_exit();
#endif
#endif
+ if (cold && to_sbt == 0)
+ to_sbt = sbinuptime();
if ((flags & C_HARDCLOCK) == 0)
to_sbt += tick_sbt;
} else
If someone were to use msleep during the window where system has reset
"cold" to zero post SI_SUB_CONFIGURE and before clocks are available
(after SI_SUB_CLOCKS is processed) then msleep which default has
C_HARDCLOCK set would get a wrong timeout set which would lead to erroneous
EWOULDBLOCK return from sleepq_check_timeout.
In my scenario the value of DPCPU_GET(hardclocktime) which is referenced in
callout_when was zero hence to_sbt was zero but the 'adjustment' for that
failed because the above check is doing a if(cold && to_sbt) to do that.
Should the check be just if (to_sbt == 0) then set to_sbt to sbinuptime?
--
Shrikanth R K