Hi, Le mercredi 15 janvier 2014 à 13:24 +0200, Eli Cohen a écrit : > On Wed, Jan 15, 2014 at 11:02:55AM +0100, Yann Droneaud wrote: > > > > Is libmlx5/libibverbs the ABI ? > > > > Unfortunately, anybody is allowed to access the kernel uverbs API > > directly, so we must take care of the kernel ABI, just in case. > > > > I am not sure I understand the question but libibverbs to libmlx5 > relation is somehow like the relationship between ib_core and mlx5_ib. > e.g. libibverbs sets the API and libmlx5 implements it.
It's a theoretical question: where to draw the line of the kernel ABI when it comes to uverbs ? Is it write() + all the data structures for request and response ? Or is it libibverbs + provider specific library ? In second case, we can change the behavor of the uverbs provided that it doesn't interfere with libibverbs: modifying corner case behavors which were never hit by libibverbs is then safe: it won't break userspace application. But in the first case, we cannot for sure attest that modifying behavor will not break hypothetical userspace application issuing uverbs command without going through libibverbs: such specific/specialized application might call uverbs in a way different that libibverbs which could break. I'm not aware of such unknown application, but I believe it could exists in the "proprietary" world. > > > > For code not yet part of a released kernel version, we can fix that. > > But for all other, it would require proper checking/thinking before > > rejecting reserved field not set to 0 since it might theoterically break > > existing userspace program: it will be a departure from previous ABI. > > > > Yes, this needs to be done carefully for each driver. We need to check > if either libibverbs or any other provider library clears the struct > before sending. If this is the case then it should be safe to fix the > kernel part. > > > > > I would found more readable to have the two locks held next each other. > > YMMV. > > > I am not following you here. Please be more specific. I thought that reworking the code to move mutex_lock(&cq->resize_mutex) and spin_lock_irqsave(&cq->lock, flags); next to each other could show that the first one would not be needed: perhaps is it possible doing: - prepare everything, - take the lock, - swap, - release the lock, - clean up. (oh, that remind me RCU). I agree that resizing the CQ is not a frequent operation, so trying to rewrite the code as I suggest won't give a lot of advantages. Regards. -- Yann Droneaud OPTEYA -- 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
