From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752895AbcD0TDb (ORCPT ); Wed, 27 Apr 2016 15:03:31 -0400 Received: from mail-yw0-f196.google.com ([209.85.161.196]:33884 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752641AbcD0TD3 (ORCPT ); Wed, 27 Apr 2016 15:03:29 -0400 Date: Wed, 27 Apr 2016 15:03:27 -0400 From: Tejun Heo To: Linus Torvalds Cc: Linux Kernel Mailing List , Roman Pen , Peter Hurley , Jens Axboe Subject: Re: [GIT PULL] workqueue fixes for v4.6-rc5 Message-ID: <20160427190327.GP7822@mtj.duckdns.org> References: <20160427161146.GO7822@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 27, 2016 at 11:49:35AM -0700, Linus Torvalds wrote: > On Wed, Apr 27, 2016 at 9:11 AM, Tejun Heo wrote: > > > > Unfortunately, we were missing a smp_rmb() after clearing PENDING for > > execution, so nothing guaranteed visibility of the changes that a > > queueing loser has made, which manifested as a reproducible blk-mq > > stall. > > That explanation makes no sense. A smp_rmb() after a store makes no > sense what-so-ever. > > Happily, the code itself does and has a big comment. It's not a > "smp_rmb()", it's a full memory barrier. Which *does* make sense as > serializing a store wrt a following load. Heh, yeah, brainfart. smp_mb(), obviously. Thanks. -- tejun