From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: "Winkler, Tomas" <tomas.winkler@intel.com>,
"tpmdd-devel@lists.sourceforge.net"
<tpmdd-devel@lists.sourceforge.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tpm: don't destroy chip device prematurely
Date: Tue, 4 Oct 2016 10:47:38 -0600 [thread overview]
Message-ID: <20161004164738.GA17149@obsidianresearch.com> (raw)
In-Reply-To: <20161004051946.GA10572@intel.com>
On Tue, Oct 04, 2016 at 08:19:46AM +0300, Jarkko Sakkinen wrote:
> > Make the driver uncallable first. The worst race that can happen is that
> > open("/dev/tpm0", ...) returns -EPIPE. I do not consider this fatal at
> > all.
>
> No responses for this reasonable proposal so I'll show what I mean:
How is this any better than what Thomas proposed? It seems much worse
to me since now we have even more stuff in the wrong order.
There are three purposes to the ordering as it stands today
1) To guarantee that tpm2_shutdown is the last command delivered to
the TPM. When it is issued all other ways to access the device
are hard fenced off.
2) To hard fence the tpm subsystem for the 'platform' driver. Once
tpm_del_char_device completes no callback into the driver
is possible *at all*. The driver can destroy everything
(iounmap, dereg irq, etc) and the driver module can be unloaded.
3) To prevent oopsing with the sysfs code. Recall this comment
/* The sysfs routines rely on an implicit tpm_try_get_ops, device_del
* is called before ops is null'd and the sysfs core synchronizes this
* removal so that no callbacks are running or can run again
*/
device_del is what eliminates the sysfs access path, so
ordering device_del after ops = null is just unconditionally
wrong.
I still haven't heard an explanation why Thomas's other patches need
this, or why trying to change this ordering makes any sense at
all considering how the subsystem is constructed.
Further, if tpm_crb now needs a registered device, how on earth do all
the chip ops we call work *before* registration? Or is that another
bug?
Why can't tpm_crb return to the pre-registration operating state
in the driver remove function before calling unregister?
None of this makes any sense to me.
This whole thing was very carefully constructed to work *correctly*
during unregister. Many other subsystems have races and bugs during
remove (eg see the securityfs discussion). TPM has a hard requirement
to support safe unregister due to the vtpm stuff, so we don't get to
screw it up just to support one driver.
Jason
next prev parent reply other threads:[~2016-10-04 16:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-02 7:39 [PATCH] tpm: don't destroy chip device prematurely Tomas Winkler
[not found] ` <1475393971-12715-1-git-send-email-tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-10-02 10:17 ` Jarkko Sakkinen
[not found] ` <20161002101755.GA25844-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-10-02 10:24 ` Jarkko Sakkinen
[not found] ` <20161002102455.GA27464-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-10-02 21:21 ` Jason Gunthorpe
[not found] ` <20161002212126.GA25872-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-10-03 7:05 ` Winkler, Tomas
[not found] ` <5B8DA87D05A7694D9FA63FD143655C1B542F466B-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-10-03 7:38 ` Winkler, Tomas
[not found] ` <5B8DA87D05A7694D9FA63FD143655C1B542F46C1-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-10-03 12:42 ` Jarkko Sakkinen
2016-10-03 16:03 ` Jason Gunthorpe
[not found] ` <20161003160308.GA6801-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-10-03 17:30 ` Winkler, Tomas
2016-10-03 12:48 ` Jarkko Sakkinen
[not found] ` <20161003124836.GE9990-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-10-04 5:19 ` Jarkko Sakkinen
2016-10-04 16:47 ` Jason Gunthorpe [this message]
2016-10-04 21:55 ` Winkler, Tomas
2016-10-04 23:10 ` Jason Gunthorpe
[not found] ` <20161004231057.GA20062-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-10-05 7:48 ` Winkler, Tomas
[not found] ` <5B8DA87D05A7694D9FA63FD143655C1B542F5084-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-10-05 15:15 ` Jarkko Sakkinen
2016-10-05 16:37 ` Jason Gunthorpe
2016-10-05 17:11 ` Jason Gunthorpe
2016-10-05 20:09 ` Winkler, Tomas
2016-10-05 21:16 ` Jason Gunthorpe
2016-10-06 0:43 ` Winkler, Tomas
[not found] ` <5B8DA87D05A7694D9FA63FD143655C1B542F561B-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-10-06 2:07 ` Jason Gunthorpe
[not found] ` <20161006020748.GA17479-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-10-07 14:24 ` Winkler, Tomas
2016-10-07 19:17 ` Jason Gunthorpe
[not found] ` <20161007191724.GA28795-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-10-07 20:10 ` Winkler, Tomas
[not found] ` <5B8DA87D05A7694D9FA63FD143655C1B542F625A-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-10-08 10:47 ` Jarkko Sakkinen
2016-10-05 10:02 ` Jarkko Sakkinen
[not found] ` <20161005100234.GA20851-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-10-05 16:27 ` Jason Gunthorpe
2016-10-06 11:23 ` Jarkko Sakkinen
2016-10-06 16:22 ` Jason Gunthorpe
[not found] ` <20161006162245.GF1224-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-10-06 16:46 ` Jarkko Sakkinen
2016-10-05 10:09 ` Jarkko Sakkinen
2016-10-03 16:00 ` Jason Gunthorpe
2016-10-03 17:16 ` Winkler, Tomas
[not found] ` <5B8DA87D05A7694D9FA63FD143655C1B542F474C-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-10-03 17:30 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161004164738.GA17149@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tomas.winkler@intel.com \
--cc=tpmdd-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).