linux-kernel - Re: [PATCH v3 2/2] tpm: add support for nonblocking operation

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <c6ea057d-5818-7c3b-09c6-329856736941@intel.com>
Date:   Wed, 13 Jun 2018 11:05:26 -0700
From:   Tadeusz Struk <tadeusz.struk@...el.com>
To:     J Freyensee <why2jjj.linux@...il.com>,
        jarkko.sakkinen@...ux.intel.com
Cc:     jgg@...pe.ca, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] tpm: add support for nonblocking operation

On 06/13/2018 10:55 AM, J Freyensee wrote:
>> +    /*
>> +     * If in nonblocking mode schedule an async job to send
>> +     * the command return the size.
>> +     * In case of error the err code will be returned in
>> +     * the subsequent read call.
>> +     */
>> +    if (file->f_flags & O_NONBLOCK) {
>> +        queue_work(tpm_dev_wq, &priv->async_work);
>> +        return size;
> 
> Apologies for the question, but should there be a mutex_unlock() here?  It's about the only return statement I am seeing where I cannot tell if a mutex_unlock() will be called before return or is needed before return.  The rest of the code is pretty obvious the return statements are being re-factored to an out: block where the mutex_unlock() will always be called before returning.

Hi Jay,
We need to hold the lock until the whole command is sent and the device is ready for next one.
In case of the async job the mutex in unlocked in tpm_async_work() just after the tpm_transmit() returns.
Thanks for reviewing.
-- 
Tadeusz