On Tue, Oct 04, 2016 at 11:12:31AM -0600, Jason Gunthorpe wrote: > On Tue, Oct 04, 2016 at 08:26:51AM +0300, Jarkko Sakkinen wrote: > > On Mon, Oct 03, 2016 at 03:11:29PM -0600, Jason Gunthorpe wrote: > > > On Mon, Oct 03, 2016 at 11:22:30PM +0300, Jarkko Sakkinen wrote: > > > > > > > > Sort of, the typical race is broadly > > > > > > > > > > CPU0 CPU1 > > > > > > > > > > fops->open() > > > > > securityfs_remove() > > > > > kref_put(chip) > > > > > kfree(chip) > > > > > kref_get(data->chip.kref) > > > > You need to actually race open and securityfs_remove to see the > > > kref_get() loose its race and then use-after-free. > > > > So you are worried that get_device() might come when the chip is already > > gone? > > Yes, I'm worried that securityfs_remove doesn not guarentee that > all threads running open() have completed and that no new threads can > start an open(). If that is guarenteed then we are fine once the > get_device is added. > > There might be some tricky thing guaranteeing that but I haven't found > it..
Great, thanks for time and patience explaining. This will help me a lot to properly review the next revisions of this series. /Jarkko ------------------------------------------------------------------------------ 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
