From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:36244 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726860AbeHYCmb (ORCPT ); Fri, 24 Aug 2018 22:42:31 -0400 Date: Sat, 25 Aug 2018 00:05:49 +0100 From: Al Viro To: Eric Wong Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini Subject: Re: [RFC] pipe: prevent compiler reordering in pipe_poll Message-ID: <20180824230549.GP6515@ZenIV.linux.org.uk> References: <20180824225431.tpaxuck7idgnj3b7@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180824225431.tpaxuck7idgnj3b7@dcvr> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Aug 24, 2018 at 10:54:31PM +0000, Eric Wong wrote: > The pipe_poll function does not use locks, and adding an entry > to the waitqueue is not guaranteed to happen before pipe->nrbufs > (or other fields) are read, leading to missed wakeups. > > Looking at Ruby CI build logs and backtraces, I've noticed > occasional instances where processes are stuck in select(2) or > ppoll(2) with a pipe. > > I don't have access to the systems where this is happening to > test/reproduce the problem, and haven't been able to reproduce > it locally on less-powerful hardware, either. However, it seems > like a problem based on similar comments in > fs/eventfd.c::eventfd_poll made by Paolo. You are misinterpreting those comments. That load *can't* migrate to anything earlier than taking queue lock, since that acts as an acquire barrier. READ_ONCE in eventfd_poll() is not to prevent compiler reordering - it's to prevent insane compiler doing multiple loads on possibly changing variable (ctx->count there).