linux-kernel - Re: [PATCH 2/3] tpm: Get rid of chip->pdev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 12 Feb 2016 19:00:25 -0700
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Stefan Berger <stefanb@...ibm.com>
Cc:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Peter Huewe <peterhuewe@....de>,
	tpmdd-devel@...ts.sourceforge.net
Subject: Re: [PATCH 2/3] tpm: Get rid of chip->pdev

On Fri, Feb 12, 2016 at 08:31:21PM -0500, Stefan Berger wrote:

> The vtpm driver will introduce chip->priv, which will point to
> vtpm_dev. For

Why not just use chip->vendor.priv? Aka TPM_VPRIV

> this reason we need to hold a reference to the vtpm_dev->dev in the
> front end.

Yes, but all drivers are like this. Most will just kfree their priv immediately

All sane Linux core subsystems guarentee that after their unregister
returns the driver callbacks will be done and uncallable, it is a bug
that tpm does not do this.

> So we could optimize it:
> 
> if (chip->priv)
>         get_device(chip->dev.parent);

That doesn't address the race

Jason