Messages in this thread | | | Date | Wed, 06 Jan 2016 11:27:54 -0500 | From | Prarit Bhargava <> | Subject | Re: [PATCH 1/2] kernel, timekeeping, add trylock option to ktime_get_with_offset() |
| |
On 01/06/2016 11:04 AM, Jiri Bohac wrote: > On Wed, Jan 06, 2016 at 08:00:33AM -0500, Prarit Bhargava wrote: >> -ktime_t ktime_get_with_offset(enum tk_offsets offs) >> +ktime_t ktime_get_with_offset(enum tk_offsets offs, int trylock) >> { >> struct timekeeper *tk = &tk_core.timekeeper; >> unsigned int seq; >> ktime_t base, *offset = offsets[offs]; >> s64 nsecs; >> + unsigned long flags = 0; >> + >> + if (unlikely(!timekeeping_initialized)) >> + return ktime_set(0, 0); >> >> WARN_ON(timekeeping_suspended); >> >> + if (trylock && !raw_spin_trylock_irqsave(&timekeeper_lock, flags)) >> + return ktime_set(KTIME_MAX, 0); >> + > > Are you trying to avoid a deadlock caused by calling printk() with > timekeeper_lock locked?
Not exactly. When I initially sent this as a RFE to jstultz he pointed out that if CPU A had acquired the timekeeper_lock (and therefore incremented tk_core.seq for a write), and CPU B panicked, no output would occur because the reads of tk_core.seq would spin indefinitely.
> > I believe this is already unsafe, as explained in the commit log > of 6d9bcb62 (timekeeping: use printk_deferred when holding > timekeeping seqlock).
Hmm ... John Stultz, any suggestions here?
P.
> > So directly calling ktime_get() from printk would just turn a > rare deadlock into a certain one - perhaps a good thing? > >
| |