On Mon, May 21, 2012 at 01:24:57PM -0700, John Stultz wrote:Well, that needs to be reworked so it doesn't. :) Again, passing the required time state to NTP functions from the timekeeping context should handle these issues, and for those few NTP paths that aren't triggered from the timekeeping core (do_adjtimex basically), we can grab the required time state before taking the ntp lock as we have been doing.The locking order is pretty straight forward: timekeeper.lock ->The icky part is the fact that ntp would need access to timekeeper
ntp_lock. This only gets messy when you require timekeeping data
from the ntp context, but usually we provide the required data via
the caller. But better documentation is always welcome.
state while holding ntp_lock.