From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B039C3F68F for ; Thu, 6 Feb 2020 04:28:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DED5A20720 for ; Thu, 6 Feb 2020 04:28:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="kN55My+Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DED5A20720 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 489786B0003; Wed, 5 Feb 2020 23:28:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 413936B0006; Wed, 5 Feb 2020 23:28:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DBB86B0007; Wed, 5 Feb 2020 23:28:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 123D36B0003 for ; Wed, 5 Feb 2020 23:28:12 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A3BA21269 for ; Thu, 6 Feb 2020 04:28:11 +0000 (UTC) X-FDA: 76458419982.02.join61_2a4fbfd1ab810 X-HE-Tag: join61_2a4fbfd1ab810 X-Filterd-Recvd-Size: 3140 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 04:28:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=3srDzlj3vxXLns6YOc9QAbtKzzZ9q6dWVHo3WgMGcfE=; b=kN55My+Qc29t3mB+G7VtG28zKU QPddywk7j32t/qKFPhIEecZ/Y1HFbE1bh9fUIoRMGF9XPYVHZDHe+sT90Px7GjsfPP+1+R2TQhQes qbhSurGhedq6RWNWYDB8YptU7dqwOtnmrxB3e9XO0aDPij8InGckr6+3O8WlfDwPbTUkZmVlB+VPX Gimi4W+eCWLmmeYBoctZ5wqlxeu4FoIV8DfteeFCVW6I06a8OxIdKeGEmJ488CwihlRYRN8jiqyRr b+UBXOctrUZl6GZoF10UuYuwdYEgnRtQLJ8+in8kyKibW+cIpY7pUdirbIsR7ZCk//n+O+BXp1mpR 8kDUVSrQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1izYll-0008QL-Gy; Thu, 06 Feb 2020 04:28:01 +0000 Date: Wed, 5 Feb 2020 20:28:01 -0800 From: Matthew Wilcox To: John Hubbard Cc: Jan Kara , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 8/8] xarray: Don't clear marks in xas_store() Message-ID: <20200206042801.GV8731@bombadil.infradead.org> References: <20200204142514.15826-1-jack@suse.cz> <20200204142514.15826-9-jack@suse.cz> <8ea2682b-7240-dca3-b123-2df7d0c994ba@nvidia.com> <20200206022144.GU8731@bombadil.infradead.org> <01e577b2-3349-15bc-32c7-b556e9f08536@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01e577b2-3349-15bc-32c7-b556e9f08536@nvidia.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 05, 2020 at 07:48:57PM -0800, John Hubbard wrote: > You can then set entries using xa_store() and get entries > using xa_load(). xa_store will overwrite any entry with the > new entry and return the previous entry stored at that index. You can > use xa_erase(), instead of calling xa_store() with a > ``NULL`` entry followed by xas_init_marks(). There is no difference between > an entry that has never been stored to and one that has been erased. Those, > in turn, are the same as an entry that has had ``NULL`` stored to it and > also had its marks erased via xas_init_marks(). There's a fundamental misunderstanding here. If you store a NULL, the marks go away. There is no such thing as a marked NULL entry. If you observe such a thing, it can only exist through some kind of permitted RCU race, and the entry must be ignored. If you're holding the xa_lock, there is no way to observe a NULL entry with a search mark set. What Jan is trying to do is allow code that knows what it's doing the ability to say "Skip clearing the marks for performance reasons. The marks are already clear." I'm still mulling over the patches from Jan. There's something I don't like about them, but I can't articulate it in a useful way yet. I'm on board with the general principle, and obviously the xas_for_each_marked() bug needs to be fixed.