Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
So I applied this, but thinking about it further, do you (theoretically at least) have the same problem with CQ and SRQ async events? - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
> I agree, that's why I posted the driver fix first. Glad we agree :) I thought about it a little more and really convinced myself that there is no good way for generic code to handle this race. > So, will you apply it next? Yes, will apply it shortly. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
On Wednesday 07 May 2008 17:32:03 Roland Dreier wrote: > > We are not sure if this should be fixed in the driver or in uverbs itself. > > Roland, what's your opinion about this? > > Would be nice to be able to fix it in uverbs but I don't see how. In > particular a kernel consumer has to have the same guarantee that no > async events will come in after destroy QP returns. And I don't see any > way generic code can provide a guarantee about what low-level driver > code may do internally. > I agree, that's why I posted the driver fix first. So, will you apply it next? Regards Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
> We are not sure if this should be fixed in the driver or in uverbs itself. > Roland, what's your opinion about this? Would be nice to be able to fix it in uverbs but I don't see how. In particular a kernel consumer has to have the same guarantee that no async events will come in after destroy QP returns. And I don't see any way generic code can provide a guarantee about what low-level driver code may do internally. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
