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], isaacm@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