Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2414041ybi; Thu, 4 Jul 2019 10:34:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqyyqwfmidTk/yiW16MG9gV89sxhTS2R85B54v1FF1dtr0MmYq0I7aGbqDdNy1rt8EVuEYXH X-Received: by 2002:a63:a35c:: with SMTP id v28mr29934392pgn.144.1562261674712; Thu, 04 Jul 2019 10:34:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562261674; cv=none; d=google.com; s=arc-20160816; b=oHMs4hG0bpBSNaEk9xrIKwd+1qMPDzpt39HgOrUItY6iF0YeA6fwlMkw9z3LiFfDbK R9ntLbf6CCo/xqs7vhqzrPJHntKZvKMAcW06gWfi/IxmCGbEw/KSsWiqbSCGdfikbmgS jKqMxkbQNcAMphm5JrASpdVh4l365Qm1eKDKgLB144EjQ1KFpLjGJxMDrdlUvb++9FOH nuBzuXjgzy0zo4p96ks61fdH3Q1rQRJh1s0LYhHGRvMWd3w4x0uJy4+YHVg5YdKaKRTK rhdBlmvyh+WRrqWFZJi75SHUiZLWbUXYmu919tG+65IzSZF/tagnR0EkZl1FOZgYr1P1 dd7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=DZTNvYnxhKbPYWbTyGxvgFIJcrrORVViObdmNlViG7g=; b=EnE3oNct3pKDGm62EPQg9/dgK/ZaPmRf1kcLl4mWVsgk/X8+Lqo0GYp5Ctyd7+RW0c esX23kPAPID2ZUPKyvc738uUfK1IhdbNWrqorwSzd4W/4xAWhB56d1YA5VojjSVeBjfV VlS0rGYrHJZjIGyOaU1fabQ2Sy4sWB1kpfVFTdaSN4tpDtOdamm4m31Mwd3DqZKZl5PT xuLsBp+aWGP50Bj3d0eKUSqodUbX8jJbuv/lUdrENW2EJBnSZbjSF6Ip6zIzqjpY0WJ5 7a9E5ZqD7KjJ5UEwICDr2kIWFioSsOcIsLZeCCXBsfGXUy+YfzV8DdblPZiVNxEuw5zd F6FQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31si5923252plk.342.2019.07.04.10.34.05; Thu, 04 Jul 2019 10:34:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727146AbfGDQyw (ORCPT + 99 others); Thu, 4 Jul 2019 12:54:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:42728 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725865AbfGDQyw (ORCPT ); Thu, 4 Jul 2019 12:54:52 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3D1F0AD2A; Thu, 4 Jul 2019 16:54:51 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id D0EFC1E3F56; Thu, 4 Jul 2019 18:54:50 +0200 (CEST) Date: Thu, 4 Jul 2019 18:54:50 +0200 From: Jan Kara To: Matthew Wilcox Cc: Dan Williams , linux-fsdevel , Jan Kara , Boaz Harrosh , stable , Robert Barror , Seema Pandit , linux-nvdimm , Linux Kernel Mailing List Subject: Re: [PATCH] dax: Fix missed PMD wakeups Message-ID: <20190704165450.GH31037@quack2.suse.cz> References: <156213869409.3910140.7715747316991468148.stgit@dwillia2-desk3.amr.corp.intel.com> <20190703121743.GH1729@bombadil.infradead.org> <20190703195302.GJ1729@bombadil.infradead.org> <20190704032728.GK1729@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190704032728.GK1729@bombadil.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 03-07-19 20:27:28, Matthew Wilcox wrote: > On Wed, Jul 03, 2019 at 02:28:41PM -0700, Dan Williams wrote: > > On Wed, Jul 3, 2019 at 12:53 PM Matthew Wilcox wrote: > > > @@ -211,7 +215,8 @@ static void *get_unlocked_entry(struct xa_state *xas) > > > for (;;) { > > > entry = xas_find_conflict(xas); > > > if (!entry || WARN_ON_ONCE(!xa_is_value(entry)) || > > > - !dax_is_locked(entry)) > > > + !dax_is_locked(entry) || > > > + dax_entry_order(entry) < xas_get_order(xas)) > > > > Doesn't this potentially allow a locked entry to be returned for a > > caller that expects all value entries are unlocked? > > It only allows locked entries to be returned for callers which pass in > an xas which refers to a PMD entry. This is fine for grab_mapping_entry() > because it checks size_flag & is_pte_entry. > > dax_layout_busy_page() only uses 0-order. > __dax_invalidate_entry() only uses 0-order. > dax_writeback_one() needs an extra fix: > > /* Did a PMD entry get split? */ > if (dax_is_locked(entry)) > goto put_unlocked; > > dax_insert_pfn_mkwrite() checks for a mismatch of pte vs pmd. > > So I think we're good for all current users. Agreed but it is an ugly trap. As I already said, I'd rather pay the unnecessary cost of waiting for pte entry and have an easy to understand interface. If we ever have a real world use case that would care for this optimization, we will need to refactor functions to make this possible and still keep the interfaces sane. For example get_unlocked_entry() could return special "error code" indicating that there's no entry with matching order in xarray but there's a conflict with it. That would be much less error-prone interface. Honza -- Jan Kara SUSE Labs, CR