Hi Phil, > Why should that be necessary? The patch is concerned with 'close' being called with garbage input. I'm not sure about the call chain here: is 'close' never called when 'open' fails? What is the assumption of the caller?
> 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. [] This looks like the caller assumes that nothing ever happened if 'open' failed. In that case, any cleanup should be done in 'open'. > 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? [] Based on your observations, all clean-up should be done in 'open' to avoid the possibility of memleaks because 'close' is not called. However, if 'close' is ever called with garbage, then it will fail - so we should cover that case too. It's one thing less to think about. Cristian S. _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
