From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753240AbcHQU0Z (ORCPT ); Wed, 17 Aug 2016 16:26:25 -0400 Received: from mga04.intel.com ([192.55.52.120]:15487 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752829AbcHQU0X (ORCPT ); Wed, 17 Aug 2016 16:26:23 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,535,1464678000"; d="scan'208";a="1037369756" Date: Wed, 17 Aug 2016 14:25:56 -0600 From: Ross Zwisler To: Jan Kara Cc: Ross Zwisler , linux-kernel@vger.kernel.org, "Theodore Ts'o" , Alexander Viro , Andreas Dilger , Andrew Morton , Dan Williams , Dave Chinner , Jan Kara , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@ml01.01.org Subject: Re: [PATCH 5/7] dax: lock based on slot instead of [mapping, index] Message-ID: <20160817202556.GA13009@linux.intel.com> Mail-Followup-To: Ross Zwisler , Jan Kara , linux-kernel@vger.kernel.org, Theodore Ts'o , Alexander Viro , Andreas Dilger , Andrew Morton , Dan Williams , Dave Chinner , Jan Kara , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org References: <20160815190918.20672-1-ross.zwisler@linux.intel.com> <20160815190918.20672-6-ross.zwisler@linux.intel.com> <20160816092816.GE27284@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160816092816.GE27284@quack2.suse.cz> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 16, 2016 at 11:28:16AM +0200, Jan Kara wrote: > On Mon 15-08-16 13:09:16, Ross Zwisler wrote: > > DAX radix tree locking currently locks entries based on the unique > > combination of the 'mapping' pointer and the pgoff_t 'index' for the entry. > > This works for PTEs, but as we move to PMDs we will need to have all the > > offsets within the range covered by the PMD to map to the same bit lock. > > To accomplish this, lock based on the 'slot' pointer in the radix tree > > instead of [mapping, index]. > > I'm not convinced this is safe. What makes the slot pointer still valid > after you drop tree_lock? At least radix_tree_shrink() or > radix_tree_expand() could move your slot without letting the waiter know > and he would be never woken. > > Honza Yep, you're right, thanks for catching that. Given that we can't rely on 'slot' being stable, my next idea is to use a combination of [mapping, index], but tweak 'index' so that it's always the beginning of the entry. So for 4k entries we'd leave it alone, but for 2MiB entries we'd mask it down to the appropriate 2MiB barrier. Let me hack on that for a bit, unless you've a better idea.