[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180129175720.GB23714@ziepe.ca>
Date: Mon, 29 Jan 2018 10:57:20 -0700
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Winkler, Tomas" <tomas.winkler@...el.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
"Usyskin, Alexander" <alexander.usyskin@...el.com>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2 v2] tpm: cmd_ready command can be issued only after
granting locality
On Sun, Jan 28, 2018 at 09:17:53PM +0000, Winkler, Tomas wrote:
> > I think if a driver can fail reliquish then it needs some kind of strategy to
> > recover.
> Maybe some driver can and some not, but if it doesn't succeed it
> should return an error.
But you can't just leave the driver in some inconsistent state..
Every time I've audited something to do with 'add error codes to
destroy/free/release' I find driver design issues..
> > Suggest trying the reliquish again on every next request until success,
> > otherwise fail request locality, potentially permanently.
>
> This is something I rather prevent because it leaves the HW in kind of undefined state
> ( and we should probably work on that a bit more later).
> As far as I've debugged the flow now, the driver just fails, and the error goes up
> user space caller or the internal flow is stopped.
But tranmist_command will be called again - then what does the driver
do? The driver needs an answer for that..
If you don't want to retry then I'd rather see request_locality
permanently fail then adding a return code to release.
Jason
Powered by blists - more mailing lists