linux-kernel - Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d89ec1c84546e7b8044b3d2b24fc175@codeaurora.org>
Date:   Tue, 24 Jul 2018 21:15:05 -0700
From:   isaacm@...eaurora.org
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     peterz@...radead.org, matt@...eblueprint.co.uk, mingo@...nel.org,
        tglx@...utronix.de, linux-kernel@...r.kernel.org,
        psodagud@...eaurora.org, gregkh@...uxfoundation.org,
        pkondeti@...eaurora.org, stable@...r.kernel.org
Subject: Re: [PATCH] stop_machine: Disable preemption after queueing stopper
 threads

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@...eaurora.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