Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp955808imm; Wed, 13 Jun 2018 10:56:16 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIigdr+IXpnaI5PJPCBSLIaG3+gfgXlkUaPXmyBG/2DQvn+G1sVXImecg9QycfReaMUivtn X-Received: by 2002:a17:902:8d98:: with SMTP id v24-v6mr6204907plo.250.1528912576516; Wed, 13 Jun 2018 10:56:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528912576; cv=none; d=google.com; s=arc-20160816; b=mQ/oDY0170VqByVVltXZlOHX8gifnUG3vba9tu+pf3knXqtKgFiT42mlGEltbhx/mp XW9xdyioF9/aApIthoav0wE+CUaNddH1KdiRAOfOCZRGsPmD9l9FVigbXPekCqCKFYPq fre0WwWHyLf5Kmv9dWmx3r9/umzXuIUV/Rq6CpMMDx1/Gor5P8huWFpEi9bE78jXEAbC nzR3Ishe4A2ichVFa0t1MgmR4ieM5fvDsYR/lqCyvBHTSAGnAnfPEmef4Bf1FOiuMspQ osUokIPLYGhYK9jwL9/3IodeOHRdpakk64ZILE9rCVq9v+FN3aoLH5XylocyI7u6c2/Y NKtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=s8oIl8Njyr5FUlaShgpVHuhgTh3S77iE9ZkDjAS+gr4=; b=cRrOcdG/TwFOVJcNiOyey80d1yqfcociF+ugT1sQxtZQwil4g6Ib+aw/WMry7BQFKC aZiaKQGmO7EJHa9R493sbzzo1rf+wTSClWD1q9b3/UOTYCeQJeBz+1GSkP9Pk27mi6vd av7pH3YQRrDX1DyapF+2QJx1cFNXw0ob05XxMlQ4FW1goWVS8AKkLQDn6oTBqUPlCh1H kpgI8NGno/DxrmJeqbXMTfNM5NNjWOy0XlITHDAF0Vx+gWPmBNZFPGK/wNA9RPqluZ0j jqzC0NbJDOrjXReq8Xmaq5o97/WWd/mqaMOD76q9QVz+wxJFcnatfJH4rp8vmRja14Ea 8ZGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QMYjElAj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z87-v6si3420635pff.159.2018.06.13.10.56.02; Wed, 13 Jun 2018 10:56:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QMYjElAj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754536AbeFMRzj (ORCPT + 99 others); Wed, 13 Jun 2018 13:55:39 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:42125 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752349AbeFMRzh (ORCPT ); Wed, 13 Jun 2018 13:55:37 -0400 Received: by mail-pf0-f194.google.com with SMTP id w7-v6so1805648pfn.9; Wed, 13 Jun 2018 10:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=s8oIl8Njyr5FUlaShgpVHuhgTh3S77iE9ZkDjAS+gr4=; b=QMYjElAjZTaCZ58YCL/z8JFPxj19xqIgqnS832kKTkIQ5ogbATVClvesDl2/iv6BLQ 3Jga53qH42aMW4ZpzCxJbda/hJDLsIXW7+QdT/hKscG4S8UyS0GkT9AxZpMQm/jPchFp V29ic7c+fOV80wpC4YzNLk+7OcbVWA6RJTt6CS4M1P9W7ns+6X1sngKeMy3LW44MXtyS 4zn/aF8gKhyZm+ckB13eBjwo+hMUfSSvX671UhHoefJZ2B70OBbscWx5dFfa4saVF1ih jZ98gXSLBXTXT+yxolQiJd8GKkRXuJBS6R3klWimU/0RxAuv5zPs741vZI9A6K6j7nFY 6ioQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=s8oIl8Njyr5FUlaShgpVHuhgTh3S77iE9ZkDjAS+gr4=; b=L7HYifnn8payCfEdGgPuh2OIh1iBkfppv2BjkwEmGmWKRnovXvJaeFz70tB6qrznIq I5Po36OVFYNDlFY4dq/IM/WVZLJ+1NORxYKqHHA/OaKbG49aJGvfEn711gre8ITKdcxJ V3FJeCpGx3RQtfNdHGCdN/0J0P9nzPhLBTk8s6h9Uz/O1qmxjcq08DH/zXqz0E/4uLG1 4f27hzDLd76Zfnk4uYYH4C+sJUOrx33+qsCSdCW/WUZK5kW5pp3IHsHqFg4x5twhnJjU DLu+l9oMTelsFgVzuEb1Yd/eScNAuoxsB3aqqtUQgbFPd5LLuaeeTfcjRKbh887na5bf qPYQ== X-Gm-Message-State: APt69E2Vu6SA0YVFOxCkBiiq+drw6fCbd4RaesHc2t1I/dJOddSKgh1A TcH53q7TYVfLKMGtm+aoDkn0Fzuq X-Received: by 2002:a62:830e:: with SMTP id h14-v6mr6008557pfe.64.1528912536393; Wed, 13 Jun 2018 10:55:36 -0700 (PDT) Received: from JF-EN-C02V905BHTDF.tld ([12.111.169.54]) by smtp.gmail.com with ESMTPSA id q11-v6sm4411719pgs.2.2018.06.13.10.55.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 10:55:35 -0700 (PDT) Subject: Re: [PATCH v3 2/2] tpm: add support for nonblocking operation To: Tadeusz Struk , jarkko.sakkinen@linux.intel.com Cc: jgg@ziepe.ca, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org References: <152882630662.30206.8805136953394285180.stgit@tstruk-mobl1.jf.intel.com> <152882631679.30206.9516257862583104447.stgit@tstruk-mobl1.jf.intel.com> From: J Freyensee Message-ID: Date: Wed, 13 Jun 2018 10:55:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152882631679.30206.9516257862583104447.stgit@tstruk-mobl1.jf.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/12/18 10:58 AM, Tadeusz Struk wrote: > Currently the TPM driver only supports blocking calls, which doesn't allow > asynchronous IO operations to the TPM hardware. > This patch changes it and adds support for nonblocking write and a new poll > function to enable applications, which want to take advantage of this. > > Signed-off-by: Tadeusz Struk > --- snip . . . > @@ -84,10 +124,9 @@ ssize_t tpm_common_write(struct file *file, const char __user *buf, > size_t size, loff_t *off) > { > struct file_priv *priv = file->private_data; > - size_t in_size = size; > - ssize_t out_size; > + int ret = 0; > > - if (in_size > TPM_BUFSIZE) > + if (size > TPM_BUFSIZE) > return -E2BIG; > > mutex_lock(&priv->buffer_mutex); > @@ -97,20 +136,19 @@ ssize_t tpm_common_write(struct file *file, const char __user *buf, > * buffered writes from blocking here. > */ > if (priv->data_pending != 0) { > - mutex_unlock(&priv->buffer_mutex); > - return -EBUSY; > + ret = -EBUSY; > + goto out; > } > > - if (copy_from_user > - (priv->data_buffer, (void __user *) buf, in_size)) { > - mutex_unlock(&priv->buffer_mutex); > - return -EFAULT; > + if (copy_from_user(priv->data_buffer, buf, size)) { > + ret = -EFAULT; > + goto out; > } > > - if (in_size < 6 || > - in_size < be32_to_cpu(*((__be32 *) (priv->data_buffer + 2)))) { > - mutex_unlock(&priv->buffer_mutex); > - return -EINVAL; > + if (size < 6 || > + size < be32_to_cpu(*((__be32 *)(priv->data_buffer + 2)))) { > + ret = -EINVAL; > + goto out; > } > > /* atomic tpm command send and result receive. We only hold the ops > @@ -118,25 +156,48 @@ ssize_t tpm_common_write(struct file *file, const char __user *buf, > * the char dev is held open. > */ > if (tpm_try_get_ops(priv->chip)) { > - mutex_unlock(&priv->buffer_mutex); > - return -EPIPE; > + ret = -EPIPE; > + goto out; > } > - out_size = tpm_transmit(priv->chip, priv->space, priv->data_buffer, > - sizeof(priv->data_buffer), 0); > > - tpm_put_ops(priv->chip); > - if (out_size < 0) { > - mutex_unlock(&priv->buffer_mutex); > - return out_size; > + /* > + * 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. Thanks, Jay