On 2020-08-31 11:25, Alan Stern wrote:
> Let me clarify this description.
>
> Firstly, the second-to-last sentence is ambiguous. The word "only" is
> all too easy to misuse through carelessness. In this case you meant
> to say "by accepting only power management requests while suspended",
> but what you actually wrote was equivalent to "by accepting power
> management requests only while suspended". And as it happens, both
> meanings are incorrect because we don't want to accept _any_ requests
> while the device is suspended -- not even power-management requests.
> The description should have said "by postponing all non-power-management
> requests while the device is suspending, suspended, or resuming."
>
> Secondly, the scenario described above is not a deadlock; it is a race
> leading to a command failure. Namely, the thread setting q->rpm_status
> to RPM_SUSPENDED races with the thread testing q->rpm_status.
>
> Thirdly, this race is _not_ the problem that Martin encountered. His
> problem was a simple bug (failure to postpone a request), not a race or
> a deadlock.
>
> Fourthly, the race illustrated above is, for now, theoretical. It
> cannot occur with the existing code base (mostly because the existing
> code is buggy). The advantage of your series over the patch I submitted
> on Aug. 23 ("block: Fix bug in runtime-resume handling") is that it
> fixes Martin's problem without introducing this new race.
Hi Alan,
Thanks for having taken a look at this patch. Do you perhaps plan to
review the other patches in this series too?
Thanks,
Bart.
