On Tue, 2008-01-15 at 19:54 -0800, Roland Dreier wrote:
> Am I missing something, or is this still racy, just with a smaller
> window? Couldn't the following still happen?
>
> CPU #1 CPU #2
>
> static inline void ipath_schedule_send(struct ipath_qp *qp)
> {
> if (!test_bit(IPATH_S_DESTROYING, &qp->s_busy))
> // bit not set yet, continue into if statement...
>
> // in ipath_destroy_qp() on other CPU:
>
> set_bit(IPATH_S_DESTROYING,
> &qp->s_busy);
>
> /* Stop the sending tasklet. */
> tasklet_kill(&qp->s_task);
> // tasklet_kill does nothing,
> // not scheduled yet...
>
> tasklet_hi_schedule(&qp->s_task);
> // uh-oh...
I think you are right. I will have to think about this some more.
> In fact testing qp->s_busy is potentially just as much use-after-free
> as scheduling the tasklet itself...
This should be safe in the receive interrupt handling since it keeps a
reference to the QP but there might be some other races possible
with posting sends and timeouts. I will think some more...
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
