> > diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c > > index 67ec9d3..a353b7a 100644 > > +++ b/drivers/char/tpm/tpm-chip.c > > @@ -327,11 +327,6 @@ static int tpm_add_char_device(struct tpm_chip > *chip) > > } > > } > > > > - /* Make the chip available. */ > > - mutex_lock(&idr_lock); > > - idr_replace(&dev_nums_idr, chip, chip->dev_num); > > - mutex_unlock(&idr_lock); > > This is actually in the wrong place already, it needs to be done before > cdev_device_add - this is because cdev_device_add generates the uevent to > userspace which could trigger userspace to use the kernel device. So a patch > to move it to the start of this function woud be good. The function would be > better described as 'make visible'
I have looked again at the code and I am not sure this is an issue. The call to idr_replace is only necessary to enable in-kernel usage (i.e. RNG, IMA, ...) of the TPM, but it should not affect userspace in any way. So the location of the idr_replace call does not matter much, as long as the TPM is already initialized. In fact, the main purpose of this patch series (please see PATCH 3/3) is to export the device to userspace without calling idr_replace at all under some circumstances. Or is there something I missed? The only function that ever tries to access the value stored by idr_replace is tpm_chip_find_get. It is usually called with TPM_ANY_NUM, selecting any TPM that might be present. If no TPM is present (or if idr_replace has not been called) the caller needs to deal with the situation already. Alexander ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
