From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758915AbYDBTow (ORCPT ); Wed, 2 Apr 2008 15:44:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755487AbYDBTop (ORCPT ); Wed, 2 Apr 2008 15:44:45 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:51865 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755249AbYDBTop (ORCPT ); Wed, 2 Apr 2008 15:44:45 -0400 Date: Wed, 2 Apr 2008 12:44:05 -0700 (PDT) From: Linus Torvalds To: Mikulas Patocka cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org Subject: Re: [PATCH]: Fix SMP-reordering race in mark_buffer_dirty In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2 Apr 2008, Mikulas Patocka wrote: > + /* > + * Make sure that the test for buffer_dirty(bh) is not reordered with > + * previous modifications to the buffer data. > + * -- mikulas > + */ > + smp_mb(); > WARN_ON_ONCE(!buffer_uptodate(bh)); > if (!buffer_dirty(bh) && !test_set_buffer_dirty(bh)) At that point, the better patch is to just *remove* the buffer_dirty() test, and rely on the stronger ordering requirements of test_set_buffer_dirty(). The whole - and only - point of the buffer_dirty() check was to avoid the more expensive test_set_buffer_dirty() call, but it's only more expensive because of the barrier semantics. So if you add a barrier, the point goes away and you should instead remove the optimization. (I also seriously doubt you can actually trigger this in real life, but simplifying the code is probably fine regardless). Linus