Hi Christian, On Thu, Jan 23, 2014 at 07:29:06AM +0000, cristian.sto...@freescale.com wrote: > You may want to have a look at this patch since it addresses an incomplete > fix of mine.
[snip] > > diff --git a/ioctl.c b/ioctl.c > > index 999fb31..7a69e5a 100644 > > --- a/ioctl.c > > +++ b/ioctl.c > > @@ -453,9 +453,9 @@ cryptodev_open(struct inode *inode, struct file > > *filp) > > int i; > > > > pcr = kzalloc(sizeof(*pcr), GFP_KERNEL); > > + filp->private_data = pcr; > > if (!pcr) > > return -ENOMEM; > > - filp->private_data = pcr; > > > > mutex_init(&pcr->fcrypt.sem); > > mutex_init(&pcr->free.lock); Why should that be necessary? I just did a quick test, simply assigning NULL to pcr instead of the kzalloc call - despite filp->private_data being garbage at the beginning of cryptodev_open, cryptodev_release is not being called when it fails with -ENOMEM. Instead, I see a more prominent potential memleak here: If one of the todo list item allocations fails, nothing is being freed. There probably should be a bunch of gotos to the end of the function to undo stuff that has been done so far. What do you think? Greetings, Phil _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
