Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp620928img; Wed, 20 Mar 2019 07:33:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqzo1FF6wQttI/P7udaCfuLQNi4hHqAyFRox3Uq0lXBqBRGuWdXUFkn8p9RIqBWzOXUwtXR4 X-Received: by 2002:a17:902:1621:: with SMTP id g30mr8625215plg.116.1553092390178; Wed, 20 Mar 2019 07:33:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553092390; cv=none; d=google.com; s=arc-20160816; b=EQyE4Weabl0J8y+SAIsPU2pr/PT7oFJYWheddPf6SvsaQyr0Ymy+Agsks6tNBXuX9O m0UnzPu9VwOtKyuRenT2ZLYE6zUD9YAxw+Hig0dhdJHkzzQch+7+12PTIW2rIMdxbwMT cuGw9I7uF7xxE47Myw3r89j1b/ioxhNHf9UaauGQu/TZ6TteMhWziW0B9K4W/VaxKkoX zNyy74T8VzKP94KkmnI9fnLKC7DpCY7DvKC/YjYOpIU7dlsEYhGCyJfT8P/iuHl4bvnR QCoiMMa5sBFotXJ4Tehy3eeeZ5tHz0B6nEBa0yB4seU4JFudhLTjRROf3kj2JQR7PemM gWlg== 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:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=WaxiGxnWu7AWOP8+F4jvk9zOLNZ2qqsd+6GKszgXR88=; b=QDFYhioaR//z8pmyhxq5T30WJ156wEo2uxCOQSWIzgRvjfOP39coKXKSunvrjUO25g GMTl35/tFH+QjFiOYF2T7K6uHilSvt73iHkIRGEt1AAHt8lsN73CiSN5oB+DvD0kxfg1 lBJibeSyNqVefW2fwiDmQ0VLUq3zll3JVQFGAjHD04dmGr8Ea+m+uW1CqGp6DNPmGEeA IP0mZeAyYYOG5IHwAsBTbWPtD8coWp/9cbFpo1YtECW21BSpy1e2kbeFnq5oYN+CZk1M YvlXr7GFxzvDC/g8WUSY6RS0hORwdpx8sgG/DXCwggNNKZDTyGHOWS7L/80fp3PbB8a+ 8ONA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=W+oVgI3O; 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=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n18si1774287pgb.91.2019.03.20.07.32.52; Wed, 20 Mar 2019 07:33:10 -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=fail header.i=@hansenpartnership.com header.s=20151216 header.b=W+oVgI3O; 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=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727495AbfCTOaq (ORCPT + 99 others); Wed, 20 Mar 2019 10:30:46 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38642 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726169AbfCTOaq (ORCPT ); Wed, 20 Mar 2019 10:30:46 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 627DB8EE10A; Wed, 20 Mar 2019 07:30:45 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G71zh68vwYKH; Wed, 20 Mar 2019 07:30:45 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id ACA1E8EE0CF; Wed, 20 Mar 2019 07:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1553092244; bh=GIn7yoSnPArPkrIyJL4Yj913wXPitEgfP98S9BP82qQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=W+oVgI3OdtcJhSNGFBqIDhgLuVC3Ne4pPWpzXAAbWhIC53DutVSsSoowyEEc3Jvid lQ9ia3dTINusPXcBRutRTzy3Hpci4OYUGcuvfJqU4rXTCymHPWrRBAw1HmcQQPBOpJ HNOWqtcD5y8ucXRusNzh7qWP+cF0mw00bqx3mI0Q= Message-ID: <1553092243.2835.3.camel@HansenPartnership.com> Subject: Re: [PATCH v2] tpm: fix an invalid condition in tpm_common_poll From: James Bottomley To: Tadeusz Struk , jarkko.sakkinen@linux.intel.com Cc: grawity@gmail.com, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 20 Mar 2019 07:30:43 -0700 In-Reply-To: <155302749437.13955.651380639754310898.stgit@tstruk-mobl1.jf.intel.com> References: <155302749437.13955.651380639754310898.stgit@tstruk-mobl1.jf.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2019-03-19 at 13:31 -0700, Tadeusz Struk wrote: > The poll condition should only check response_length, > because reads should only be issued if there is data to read. > The response_read flag only prevents double writes. > The problem was that the write set the response_read to false, > enqued a tpm job, and returned. Then application called poll > which checked the response_read flag and returned EPOLLIN. > Then the application called read, but got nothing. > After all that the async_work kicked in. > Added also mutex_lock around the poll check to prevent > other possible race conditions. > > Fixes: 9488585b21bef0df12 ("tpm: add support for partial reads") > Reported-by: Mantas Mikulėnas > Signed-off-by: Tadeusz Struk > --- > drivers/char/tpm/tpm-dev-common.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/char/tpm/tpm-dev-common.c > b/drivers/char/tpm/tpm-dev-common.c > index 5eecad233ea1..7312d3214381 100644 > --- a/drivers/char/tpm/tpm-dev-common.c > +++ b/drivers/char/tpm/tpm-dev-common.c > @@ -203,12 +203,14 @@ __poll_t tpm_common_poll(struct file *file, > poll_table *wait) > __poll_t mask = 0; > > poll_wait(file, &priv->async_wait, wait); > + mutex_lock(&priv->buffer_mutex); > > - if (!priv->response_read || priv->response_length) > + if (priv->response_length) > mask = EPOLLIN | EPOLLRDNORM; > else > mask = EPOLLOUT | EPOLLWRNORM; > > + mutex_unlock(&priv->buffer_mutex); Just an observation on this: the mutex is now no-longer necessary because a read on a size_t quantity is always atomic. James