> I am looking at a multithreaded application here, and I believe that > the race is between thread A calling the rpoll() for POLLIN event and > thread B calling the shutdown(SHUT_RDWR) for reading and writing of > the (r)socket almost immediately afterwards.
I modified a test program, and I can reproduce the hang as you describe -- calling rpoll() then rshutdown() from another thread. These calls end up calling rpoll->poll followed by rshutdown->read. The read completes, which completes rshutdown, but the poll continues to wait for an event. In the kernel, poll ends up in uverbs.c::ib_uverbs_event_poll, and read in uverbs.c::ib_uverbs_event_read(). The behavior of poll/read seems reasonable, so I don't think this is a kernel issue. I'm still trying to figure out a simple solution to fixing this. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
