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 |