From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756297AbbJ1Vht (ORCPT ); Wed, 28 Oct 2015 17:37:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56756 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756248AbbJ1Vhn (ORCPT ); Wed, 28 Oct 2015 17:37:43 -0400 From: Jeff Moyer To: Davidlohr Bueso Cc: Jens Axboe , Steven Rostedt , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] blktrace: re-write setting q->blk_trace References: <20151027030545.GH27292@linux-uzut.site> <20151027031452.GI27292@linux-uzut.site> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Wed, 28 Oct 2015 17:37:41 -0400 In-Reply-To: <20151027031452.GI27292@linux-uzut.site> (Davidlohr Bueso's message of "Mon, 26 Oct 2015 20:14:52 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Davidlohr Bueso writes: > This is really about simplifying the double xchg patterns into > a single cmpxchg, with the same logic. Other than the immediate > cleanup, there are some subtleties this change deals with: > > (i) While the load of the old bt is fully ordered wrt everything, > ie: > > old_bt = xchg(&q->blk_trace, bt); [barrier] > if (old_bt) > (void) xchg(&q->blk_trace, old_bt); [barrier] > > blk_trace could still be changed between the xchg and the old_bt > load. Note that this description is merely theoretical and afaict > very small, but doing everything in a single context with cmpxchg > closes this potential race. > > (ii) Ordering guarantees are obviously kept with cmpxchg. Hi David, The patch itself looks ok, but it doesn't seem to apply to a recent kernel tree. It appears as though it is white-space damaged. Would you mind re-sending it? Thanks! Jeff