Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp967150imm; Wed, 13 Jun 2018 11:06:09 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLxg00W1G2kg1/z2WaetysBNOfhY4WIbYO0pHqpHhrgm6uBYRT1Ac1aNGtV/qVO4tIs0Bk6 X-Received: by 2002:a63:6185:: with SMTP id v127-v6mr4792425pgb.301.1528913169664; Wed, 13 Jun 2018 11:06:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528913169; cv=none; d=google.com; s=arc-20160816; b=Q7Ko4/rzwYKdiEXmT2mTFdWSI1yuC8eZzLr38c8mvC2hNgh3ejrlNz+dBpt1KViF7B QGMqTd8cnYYt9YIdeG8ixGsK52UNT8EdZgXc2NjDB9CR2vDHj8Bvs40LBqvHl35ZE4eK l6tjPKtA/moVsfGtQpLCeMX6ap2rmzEQ4DlCH+Rkuv/OyZJ+OTPlEMLTSE6EQOlAUdeZ 3mOD37ZYNs8O8h0VvTe3d3kd+DxxcBWT2mGP49pCZK/XKdCbxhmSsxAI2XsB4xMYLpdC u5dJa4VnPZ6ilaXFp2f09xBPt026EXpSb8ElAkoj2gdx3sjVEsqoNMByf25HKBf8wUz7 RUqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject :arc-authentication-results; bh=47tJf9Pc60y/gSyjR8fEPlvQbJWG60P2WJr3G+XnqaU=; b=sySKb1gOqvylTCahrCg69GQocKPyeliN/fzYIJkH3bzrel8oipbv9Iqz2GwYxdBuzT ctMziOEcnKLJwK9dGjONasGhNePvEKMsaR7MnnTujw7+UykxyMooeqU0F2E/eJ2J8pyc OMmSjRCX2hgHZtIaNmFgN1qZfxAaJuZEUkl0aiYmz9x+RqrFinKBxcOhIPYr4IDpco6c /BIVSSeCbLsJPXKfPorjIlfa91P4J1jaVbys41JpQgPnHbu6EGA5K5zAqU4V4+Eu/ZTs 77gYDpMiOq8mdn3ynibv9fGmBKvrouiw9YVWCs++SIqMXrwWcW2oYgY7J5CpwmTlb3Tl AF5A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z141-v6si3474253pfc.95.2018.06.13.11.05.54; Wed, 13 Jun 2018 11:06:09 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935202AbeFMSF3 (ORCPT + 99 others); Wed, 13 Jun 2018 14:05:29 -0400 Received: from mga17.intel.com ([192.55.52.151]:25165 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934993AbeFMSF1 (ORCPT ); Wed, 13 Jun 2018 14:05:27 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2018 11:05:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,220,1526367600"; d="scan'208";a="49084623" Received: from tstruk-mobl1.jf.intel.com ([10.7.196.162]) by orsmga008.jf.intel.com with ESMTP; 13 Jun 2018 11:05:26 -0700 Subject: Re: [PATCH v3 2/2] tpm: add support for nonblocking operation To: J Freyensee , 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: Tadeusz Struk Openpgp: preference=signencrypt Autocrypt: addr=tadeusz.struk@intel.com; prefer-encrypt=mutual; keydata= xsDiBEiLICMRBADteQacQxypsuFvAw6IwYzbD8pgQi+kLYBcqfGgVAUN/cO+sLl6u1lVdaDB fhAArdbV9lpoqcWnmhQFTb4A+W569EpydBr6nuatWkEB+fmmx8YoUtuZfXt7v+1l1rc09kaW LY+TkwQkvFCeuvdasgmBLnmRWymEGWi1E12hUgTw/wCgtK24geC7XkiuANMv0gpr+raOgQMD /2yJZ0SeXQApWyTRaeIYN8GgYHZTWuBp/ofN+viEkhrDxahcaGPP5B/Nv6VS1+M0e5m8OzHj qPUbgfyOeJcslC5aoZdqqqzVWVLaA/+Jy+O+6T3k3R/IryVVATldBlwnGFDhET0mKQsd15zt cIdQBBbfSFR5VlugZuWV5q442IpPA/4g7nen9FFPxh45Te8D54hAsOCywjm6xUE0UJGYHeJ/ MXCPtuXfVCbYcOxZVH7kUS2Vtk5d3bF40IE2WnVq1ZScNANF4ZjikxYhYGfNWX3HXak1gSoj UrY87rMSjPIAry4L0BoIx2qgL/k4iV/3QcXL4t5wosU0iw++suf1zGGcKM0gVGFkZXVzeiBT dHJ1ayA8dHN0cnVrQGdtYWlsLmNvbT7CYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4B AheABQJQTjJTAhkBAAoJEDFswfskq9xyqvcAoI2nsaUCX8ZGbu+Jhq+++qlBFJ2rAJ983RoO R2ofHhn3g3Qi4K34tw0l087BTQRauzUlARAAqkWRL/InEPnoGMg/gw/CRaDBaIBgMsvIcghI 7xevIzpleXt6jKHghSBooH+zaT7qi4u2gkgPn4odsER3Rm94XgrZJgoqls6EpKMWpJNGP4HT eYgykhfsZOLX8ijUbjTM/Sm/dZVo6aYoBL2+ciJwyl+Zt3Mp6un3/GWu6cA9005V50pRqO7j PTlVCHi2bedcEEf5DDsYJv/3Oz8/4LpSf6BL6BltjeZVa2y03dTMmD031JTH+OuyJm1yh72Z HWxhlYNXOv6uFJJVr+paQjrAsBVIYKhK24bD+uGJxLm8AN9i7/Si+2YeSsXvKUhk9mIoFBnU VFo63cziRTcpRu/kXgDAbujwN88qytEcvhEZHS6B9vdws+lhTpolEjkLCkz0Y59z4Fs9srKy QkRN+wtdiLgrwyDW3ryAKxcDmOumGWebDxpaOI/pBhrlS93HmDlvj7JmgTUU4a/NhwI3dXh5 pn8FZzZyVXe3Kc3bu5T3UAC7uztinsAvCJQS6jGZWrXmXkqYkaLXQOw61eInWjr01zE/zDbE mdJPM0+va/gtZx9TtGxr4PpjbqswqCiubLDZXZHh5uqArPv/i+E8aXIsNSTN6Rrqs1j9YgDN ALksibv6+tXH3sOlCUgjuZgJH3+s/mnaAtiV2rZ/WlH15d6nd0uiDSZrKhlR+g4NHMh1ztEA EQEAAcJPBBgRAgAPBQJauzUlAhsMBQkJZgGAAAoJEDFswfskq9xyfv8AoI8aPrJCoM0h5WOP kKxMmPEPHzUNAJ9jBBYXhX1CWg+IhI7i/fLlI0vwCA== Message-ID: Date: Wed, 13 Jun 2018 11:05:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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