> When the driver needs to dynamically allocate char device numbers in systems > with more than IB_UVERBS_MAX_DEVICES, it releases map lock, allocates a new > range and a new device number from that range, and only then re-acquires the > lock. This must be protected for the same reasoning that the map_lock > spinlock > is used. Without protecting we could also end up calling > alloc_chrdev_region() > a nubmer of times and cause a leakage. Fix this by replacing map_lock with a > mutex and apply on the all the allocation code.
Looks like a good catch. I assume you found this through inspection and not hitting it practice? Also it seems user_mad.c would need the same fix. Although looking at this I wonder if we do need that lock... we don't seem to do any locking when we do the clear_bit in the dev_map, and all of this is done through the device add/remove callback, which seems to be serialized by the device_mutex in device.c. But we probably don't want to make that a requirement in case we parallelize in the future. - R. -- Roland Dreier <[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
