Hi, >> > > tapdisk[9180]: segfault at 7f7e3a5c8c10 ip 00007f7e387532d4 sp >> > 00007f7e3a5c8c10 error 4 in libpthread-2.13.so[7f7e38748000+17000] >> > > tapdisk:9180 blocked for more than 120 seconds. >> > > tapdisk D ffff88043fc13540 0 9180 1 0x00000000 You can try generating a core file by changing the ulimit on the running process http://superuser.com/questions/404239/setting-ulimit-on-a-running-process A backtrace would be useful :) > Actually maybe not. What I was reading only applies for large number of bytes written to the pipe, and even then I got confused by the double negatives. Sorry for the noise. Yes, as you discovered but size < PIPE_BUF, they should be atomic even in non-blocking mode. But I could still add assert() there to make sure it is. I did find a bug where it could "leak" requests which may lead to hang. But it shouldn't crash ... Here's an (untested yet) patch in the rbd error path: diff --git a/drivers/block-rbd.c b/drivers/block-rbd.c index 68fbed7..ab2d2c5 100644 --- a/drivers/block-rbd.c +++ b/drivers/block-rbd.c @@ -560,6 +560,9 @@ err: if (c) rbd_aio_release(c); + list_move(&req->queue, &prv->reqs_free); + prv->reqs_free_count++; + return rv; } Cheers, Sylvain -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
