On Mon, 2012-12-31 at 13:21 +0000, Eric Wong wrote: > This patch seems to fix my issue with ppoll() being stuck on my > SMP machine: http://article.gmane.org/gmane.linux.file-systems/70414 > > The change to sock_poll_wait() in > commit 626cf236608505d376e4799adb4f7eb00a8594af > (poll: add poll_requested_events() and poll_does_not_wait() functions) > seems to have allowed additional cases where the SMP memory barrier > is not issued before checking for readiness. > > In my case, this affects the select()-family of functions > which register descriptors once and set _qproc to NULL before > checking events again (after poll_schedule_timeout() returns). > The set_mb() barrier in poll_schedule_timeout() appears to be > insufficient on my SMP x86-64 machine (as it's only an xchg()). > > This may also be related to the epoll issue described by > Andreas Voellmy in http://thread.gmane.org/gmane.linux.kernel/1408782/ Hmm, the change seems not very logical to me. If it helps, I would like to understand the real issue. commit 626cf236608505d376e4799adb4f7eb00a8594af should not have this side effect, at least for poll()/select() functions. The epoll() changes I am not yet very confident. I suspect a race already existed before this commit, it would be nice to track it properly. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
