[stgt] [PATCH 1/1] nonblocking epoll_wait loop, sched events, ISER/IB polling

[FUJITA Tomonori]

On Mon, 22 Sep 2008 16:52:28 -0400
Pete Wyckoff <pw at padd.com> wrote:

> ogerlitz at voltaire.com wrote on Sun, 21 Sep 2008 10:06 +0300:
> > Pete Wyckoff wrote:
> >>> +static void iser_poll_cq_normal(struct iser_device *dev) +{
> >>> +        int ret;
> >>> +
> >>> +        ret = iser_poll_cq(dev,8);
> >>> +        if (ret < 0)
> >>> +		exit(1);
> >>
> >> Please eprintf() then exit.  
> > I see now that the iscsi rdma code has many exit() calls, where the  
> > iscsi tcp has none and tgtd.c has one (after the epoll_wait, the rest  
> > are in the init time). Sounds like an issue orthogonal to this patch,  
> > but production wise, I don't think anyone wants their iscsi target  
> > process to disappear just b/c something went wrong...
> 
> Yes, you're absolutely right.  My suggestion above was just to
> figure out "what went wrong" before the exit.  But if we could
> instead recover gracefully, that would be much better.
> Unfortunately most of the exit()s reveal "bugs" in the code, in
> particular, unhandled issues due to resource exhaustion.

I think that iser code should do better in resource exhaustion
situations instead of just calling exit().


>  The others
> come from "can't happen" situations that could indicate a hardware
> or firmware fault.  Not sure how to recover gracefully there.

This is kinda BUG_ON(). We should print all we can get here and call
exit().
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html