Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp161878ybi; Thu, 30 May 2019 22:43:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqyluUOqlCo32dY7/4GgbHs2TzL41hwc3zgZG8yh6ry/MPBYthYuJ65gDy/Aoh7iZmVV2UIa X-Received: by 2002:a63:480f:: with SMTP id v15mr7051308pga.373.1559281411145; Thu, 30 May 2019 22:43:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559281411; cv=none; d=google.com; s=arc-20160816; b=z/JWvn8AYQaNZjCbpl0G/OeZZy/SeBHju4SQB6oD2fUfOnkz1+Hu5lfqoGcuy45c+B D59AxoTRZO46vr8uvPQIMyP+AFxapXP5+P34V9xqMPDJU1mq1mreB7DRhZJ3Ies2hZHH eQ6oqYIRvuSEFfaMljXXpvnZY6fz5FrLUrA+HDvHnwvWv+Y6E1mf8WfXHn+HOR2DMueR jzTL+0KApNe3B7HdDcdhsZs5FQg9C77eZH7zKPU5iRwOWxn/BTx9iEm9Qhcw7clMTWK0 oYJOnbMvkPm5B8AH9XngmNF44UQI/k2ai/YE5UjPHFZcksh0u0fHr90O4j/yGjgkcM0O Yecw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=tzf4N8Yuf11L/sU2WqNDFLy9Hg+7U+yVCZCqP+VEsF4=; b=lLACJGhHeHx2s9MCX2aB7axg0h3+LgHfhtPttt3Yuo8yuvKLlrLcSs/TQDe6qhui0w nne00YiRMv1ew1tgucz17+tQ/v9Ej6LNPK05wMVz9Ys5idWAWZxuJl7EZIkFlSi2TnxH VPlqol9FMJXVDJ3G9DSIVvBJ/IzWpX2aZfGHrieeT7W9BU/OPAdiIDE2n4HWOjW2K18Y gIkHsNoUtYidpmrXhIWKjV56DF8JdFhJRZtpnXsEOjDNjXP7Cvphj17pRLmVyG4Q2/Sj BrOo7ScjHJPi5Oe292lukbU/Mfo09qRJtx+dTEJfbsgpty7PELb6P0AUU+Rv/eI+0YZ9 O47Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si4938808pgt.93.2019.05.30.22.43.04; Thu, 30 May 2019 22:43:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-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-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726002AbfEaFnC (ORCPT + 99 others); Fri, 31 May 2019 01:43:02 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:45674 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725955AbfEaFnC (ORCPT ); Fri, 31 May 2019 01:43:02 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1hWaJd-0003cY-8G; Fri, 31 May 2019 13:42:57 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hWaJW-000526-JU; Fri, 31 May 2019 13:42:50 +0800 Date: Fri, 31 May 2019 13:42:50 +0800 From: Herbert Xu To: Horia Geanta Cc: Ard Biesheuvel , Eric Biggers , Iuliana Prodan , "David S. Miller" , Sascha Hauer , "linux-crypto@vger.kernel.org" , "linux-kernel@vger.kernel.org" , dl-linux-imx Subject: Re: [PATCH] crypto: gcm - fix cacheline sharing Message-ID: <20190531054250.p2bc3igiu4s7dmvk@gondor.apana.org.au> References: <1559149856-7938-1-git-send-email-iuliana.prodan@nxp.com> <20190529202728.GA35103@gmail.com> <20190530053421.keesqb54yu5w7hgk@gondor.apana.org.au> <20190530132623.4h3y2bymv4uvfnms@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, May 31, 2019 at 05:22:50AM +0000, Horia Geanta wrote: > > Unless it's clearly defined *which* virtual addresses mustn't be accessed, > things won't work properly. > In theory, any two objects could share a cache line. We can't just stop all > memory accesses from CPU while a peripheral is busy. The user obviously can't touch the memory areas potentially under DMA. But in this case it's not the user that's doing it, it's the driver. So the driver must not touch any virtual pointers given to it as input/output while the DMA areas are mapped. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt