On Fri, Jan 13, 2017 at 05:10:30PM -0800, James Bottomley wrote:
> > No, it is correct as is. The cdev fops rely only on the tpm module.
> > When tpm_chip_unregister returns to the driver the chips->ops is set
> > to NULL with proper locking - the driver code becomes uncallable at
> > that point.
On Fri, Jan 13, 2017 at 09:40:08AM -0800, James Bottomley wrote:
> On Fri, 2017-01-13 at 10:25 -0700, Jason Gunthorpe wrote:
> > On Thu, Jan 12, 2017 at 10:56:28PM +0200, Jarkko Sakkinen wrote:
> >
> > > > dev_t tpm_devt;
> > >
> > > But they should have different major device numbers.
> >
> >
On Fri, 2017-01-13 at 14:23 -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 12:02:36PM -0800, James Bottomley wrote:
> > > > Actually, no, the devrm is a completely lifetime managed device
> > > > as part of the chip structure. once you've done a device_del
> > > > on it, it can be kfree
On Fri, Jan 13, 2017 at 12:02:36PM -0800, James Bottomley wrote:
> > > Actually, no, the devrm is a completely lifetime managed device as
> > > part
> > > of the chip structure. once you've done a device_del on it, it can
> > > be
> > > kfreed because it's no longer visible to anything else.
> >
On Fri, 2017-01-13 at 12:47 -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 11:20:47AM -0800, James Bottomley wrote:
> > On Thu, 2017-01-12 at 11:39 -0700, Jason Gunthorpe wrote:
> > > On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote:
> > >
> > > > struct tpm_chip {
> > > >
On Fri, Jan 13, 2017 at 11:20:47AM -0800, James Bottomley wrote:
> On Thu, 2017-01-12 at 11:39 -0700, Jason Gunthorpe wrote:
> > On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote:
> >
> > > struct tpm_chip {
> > > - struct device dev;
> > > - struct cdev cdev;
> > > + struct device
On Thu, 2017-01-12 at 11:39 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote:
>
> > struct tpm_chip {
> > - struct device dev;
> > - struct cdev cdev;
> > + struct device dev, devrm;
>
> Hum.. devrm adds a new kref but doesn't do anything with
On Fri, 2017-01-13 at 11:01 -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 09:40:08AM -0800, James Bottomley wrote:
> > On Fri, 2017-01-13 at 10:25 -0700, Jason Gunthorpe wrote:
> > > On Thu, Jan 12, 2017 at 10:56:28PM +0200, Jarkko Sakkinen wrote:
> > >
> > > > > dev_t tpm_devt;
> > > >
On Fri, Jan 13, 2017 at 09:40:08AM -0800, James Bottomley wrote:
> On Fri, 2017-01-13 at 10:25 -0700, Jason Gunthorpe wrote:
> > On Thu, Jan 12, 2017 at 10:56:28PM +0200, Jarkko Sakkinen wrote:
> >
> > > > dev_t tpm_devt;
> > >
> > > But they should have different major device numbers.
> >
> >
On Fri, 2017-01-13 at 10:25 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 12, 2017 at 10:56:28PM +0200, Jarkko Sakkinen wrote:
>
> > > dev_t tpm_devt;
> >
> > But they should have different major device numbers.
>
> major/minors don't really matter these days since they are dynamic
Right, althou
On Thu, Jan 12, 2017 at 10:56:28PM +0200, Jarkko Sakkinen wrote:
> > dev_t tpm_devt;
>
> But they should have different major device numbers.
major/minors don't really matter these days since they are dynamic
Jason
On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote:
> From: James Bottomley
>
> Currently the Resource Manager (RM) is not exposed to userspace. Make
> this exposure via a separate device, which can now be opened multiple
> times because each read/write transaction goes separately v
On Thu, 2017-01-12 at 19:46 +0200, Jarkko Sakkinen wrote:
> From: James Bottomley
>
> Currently the Resource Manager (RM) is not exposed to userspace.
> Make
> this exposure via a separate device, which can now be opened multiple
> times because each read/write transaction goes separately via t
On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote:
> struct tpm_chip {
> - struct device dev;
> - struct cdev cdev;
> + struct device dev, devrm;
Hum.. devrm adds a new kref but doesn't do anything with the release
function, so that is going to use after free, ie here:
From: James Bottomley
Currently the Resource Manager (RM) is not exposed to userspace. Make
this exposure via a separate device, which can now be opened multiple
times because each read/write transaction goes separately via the RM.
Concurrency is protected by the chip->tpm_mutex for each read/w
15 matches
Mail list logo
