Sherry Moore wrote:
> Hi Garrett,
>
>
>> I think the framework should guarantee that the kernel is single
>> threaded at the point that quiesce is called, and that there will be no
>> subsequent IO performed to the device. I suspect that this guarantee is
>> already in place, but maybe the project team can clarify.
>>
>
> We would like to call quiesce in the single-threaded environment. That
> was original design that you reviewed. However, once we are in a
> single-threaded environment, we must not grab locks. When I contacted
> various driver owners, they all said that it's very difficult to
> implement quiesce() in a lock-free manner. As a result, I have moved
> the quiesce() invocation to immediately before the system becomes
> single-threaded. If driver owners can step up and provide lock-free,
> no-memory-allocation, do-the-bare-minimal quiesce() implementations,
> that might solve the panic reboot problem as well.
>
> Thanks,
> Sherry
>
Wow. I'm surprised driver developers made that assertion. I wonder if
the problem is really that device driver authors expect to be able to
use interrupts to quiesce, and hence need condvars to synchronize with?
It seems (to me at least), that if interrupts are disabled and the
kernel is truly single threaded, then device drivers should just be able
to poll during quiesce if they need to wait for a device to respond, and
should just poll for completion of other things.
Perhaps the driver folks didn't understand that at the point of quiesce,
no inflight operations are going to complete on their own. (Other than
perhaps ones that have already been submitted to the device.) Locks in
a single threaded non-preemptable environment seem pointless to me.
-- Garrett
