Page MenuHomeFreeBSD

watchdog: Just pat existing watchdogs when dumping
Needs ReviewPublic

Authored by jhb on Thu, Oct 8, 3:32 PM.
Tags
None
Referenced Files
F175298807: D60468.id189059.diff
Fri, Oct 9, 6:49 PM
F175252055: D60468.id189059.diff
Fri, Oct 9, 10:55 AM
F175228248: D60468.diff
Fri, Oct 9, 6:38 AM
F175201834: D60468.id189059.diff
Fri, Oct 9, 1:46 AM
F175200265: D60468.diff
Fri, Oct 9, 1:28 AM
Unknown Object (File)
Thu, Oct 8, 11:03 PM
Subscribers

Details

Reviewers
jhibbits
markj
Summary

Dumping (particulary after a panic) is not an appropriate time to
probe for new watchdog devices or configure the pre-timeout callout.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 77852
Build 74735: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Thu, Oct 8, 3:32 PM

I'm not fully sure if this is correct (as in, should we be checking SCHEDULER_STOPPED instead?) My use case is I had a panic because of a use-after-free where a callout was freed while it was still scheduled and the system panicked when the callout was finally executed. However, that panic occurred with the callout_mtx lock held and so the pretimeout here then recursively panicked since the lock was already held so I could not get a dump (also couldn't reboot, but that's a different problem). It seems to me what when we pat the watchdog during the loop in doadump() we should only be patting existing watchdogs and not messing with any other state. Possibly we shouldn't be doing the softtimer stuff either in that case, only invoking the eventhandlers and returning.