[openib-general] Re: [PATCH] fix umad object lifetime stuff
rdreier at cisco.com
Wed Jan 4 13:41:53 PST 2006
Sean> I'm just now getting back to looking at this issue. If I
Sean> understand the problem in the ucm correctly, struct cdev is
Sean> freed as part of struct ib_ucm_device after cdev_del()
Sean> returns; however, a user could still have a reference on the
Sean> cdev. Also, the user could still make calls into the driver.
Sean> Is this correct?
Sean> If this is the case, isn't more protection needed that
Sean> simply preventing access to cdev? I.e. what prevents the
Sean> user from invoking a call that tries to access the
Sean> underlying ib_device? Does every file operation need
Sean> synchronization with device removal to ensure that the
Sean> underlying hardware is still there? (This appears to be
Sean> what user_mad now does.)
That all sounds right, although to be honest I'd have to take more
time to recreate my old reasoning. The basic idea is that we have to
keep every object around as long as there is a way to reach it.
If you look at the comment in user_mad.c that starts
* Our lifetime rules for these structs...
you might find some clues about my reasoing...
Sean> Assuming that my understanding is correct (which is a
Sean> stretch), it seems that there has to be a better way to
Sean> handle this that is or can be integrated with the kernel,
Sean> rather than adding complex reference counting,
Sean> synchronization, and clean-up code to every driver that
Sean> wants to handle device removal...
There probably is but I wasn't smart enough to see it. On the other
hand keeping one reference to an object for each way to reach it and
not freeing the object until the last reference is gone seems fairly
natural to me.
More information about the general