[openib-general] Re: [PATCH] fix umad object lifetime stuff

Roland Dreier 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.

 - R.



More information about the general mailing list