Hi Sebastian,
Thanks for the response.
"I haven't look in detail at this but your new preempt_disable() makes
things unbalanced for the err != 0 case."
This cannot happen. The only possible return values of this function
are -ENOENT or 0.
In the case where we return -ENOENT, we'll go
straight to "unlock," which releases the two locks being held, but
doesn't disable preemption, and since err != we won't call
preemption_enable.
In the case where we return 0, then that means the works were queued
successfully, and preemption was disabled, and we'll fall into the
if branch, after releasing the locks, and enable preemption, which is
correct.
In either case, there is no imbalance between the
preemption_[disable/enable]
calls.
Thanks,
Isaac Manjarres
On 2018-07-23 23:23, Sebastian Andrzej Siewior wrote:
On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote:
Hi all,
Hi,
Are there any comments about this patch?
I haven't look in detail at this but your new preempt_disable() makes
things unbalanced for the err != 0 case.
Thanks,
Isaac Manjarres
Sebastian
