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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 74E57C352A2 for ; Thu, 6 Feb 2020 13:49:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 38FAA218AC for ; Thu, 6 Feb 2020 13:49:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="WxKpQD2B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38FAA218AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF55C6B0003; Thu, 6 Feb 2020 08:49:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA5F26B0006; Thu, 6 Feb 2020 08:49:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B953C6B0007; Thu, 6 Feb 2020 08:49:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id A0DD16B0003 for ; Thu, 6 Feb 2020 08:49:07 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5312040CA for ; Thu, 6 Feb 2020 13:49:07 +0000 (UTC) X-FDA: 76459833534.13.field47_89c6c2674c204 X-HE-Tag: field47_89c6c2674c204 X-Filterd-Recvd-Size: 4681 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 13:49:06 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id h4so5580874qkm.0 for ; Thu, 06 Feb 2020 05:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DHRzcCOcfhrmm5JpAoZVwghERoHF/KR/QX0GjakaiY0=; b=WxKpQD2B98cdrxgC9OvO6+mIVpPXvVeJrYrVmY0OlZv2vV2fXHLe4PLl5mf8+3nJMT IPM1VH/h6vtD42zhYwCWdWlGhNWnbfHeNvjey5zFroF7v2t8nb3lBvtMRkrZ4+KTBp4u NkIHEWK0zuwAexD1fcLzoz132snN/Pzuu54lgqNCNsVKg/erHbhtleJeMB5PHzTlvvsj WWrP/liZAa7+D/k6D10Lbs8JIF3ZZMi7tIZqJD/gEZPf5lt6OxuTyfHbz4OxTd9NrumF oC5Sd7azc3dGSJcUJe6gDNxvpFXerXiGNJmqWIMlJJuFrrKx/aFiY3s2SnteV9G1KJJO bUMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DHRzcCOcfhrmm5JpAoZVwghERoHF/KR/QX0GjakaiY0=; b=lyU1HPNs5vYIyWjPlZHVjLXBvEOIxInNqAJidodfvIfZOl8WyYRRC9xrMjDkALGAdz 0m4LPmDxfF4ViBMNuARbm1asvvO+b9mxd2+2dvF/1YdM7edCff76Pt00T5IWcaCgUU2f YE9E0I9OBX51QnH+iQjhKQrc1AeahryOixD98ux9vCHJZQx5Bym5ANXrKB9oMpkim51i A5w7En3FqLYdBKDOQ3o5sVlIFxceWy+g9LrJH1UGZthcDEP842yCWXbWwp6uzIhXYhkt kQTFahb1Di7J9Ui3/Ya7Gykwrkq+IPEBIBxyWwcO9Eyw7vRuJEaABnSHS6MdbER3Ne9V nWcQ== X-Gm-Message-State: APjAAAXyqjZh80argT0RTe5HyUit1B19vR7aBiw/ZNJTI0RAjme2uzkX 42Uo0qx0lZbsc+Q25RTbD+65cw== X-Google-Smtp-Source: APXvYqwHDepDOaH9EZPj408YgHc3HjGdELtaEwNLPpM3ZqeQ6EYbs2s5K9LVqLU+A4Du9gvhYhIKxA== X-Received: by 2002:ae9:e211:: with SMTP id c17mr2474765qkc.133.1580996945931; Thu, 06 Feb 2020 05:49:05 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id f28sm1396397qkk.130.2020.02.06.05.49.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Feb 2020 05:49:05 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1izhWi-0002o4-KW; Thu, 06 Feb 2020 09:49:04 -0400 Date: Thu, 6 Feb 2020 09:49:04 -0400 From: Jason Gunthorpe To: Matthew Wilcox 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: <20200206134904.GD25297@ziepe.ca> References: <20200204142514.15826-1-jack@suse.cz> <20200204142514.15826-9-jack@suse.cz> <20200205184344.GB28298@ziepe.ca> <20200205215904.GT8731@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200205215904.GT8731@bombadil.infradead.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Bogosity: Ham, tests=bogofilter, spamicity=0.110880, 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 01:59:04PM -0800, Matthew Wilcox wrote: > > How is RCU mark reading used anyhow? > > We iterate over pages in the page cache with, eg, the dirty bit set. > This bug will lead to the loop terminating early and failing to find > dirty pages that it should. But the inhernetly weak sync of marks and pointers means that iteration will miss some dirty pages and return some clean pages. It is all OK for some reason? > > Actually the clearing of marks by xa_store(, NULL) is creating a very > > subtle bug in drivers/infiniband/core/device.c :( Can you add a Fixes > > line too: > > > > ib_set_client_data() is assuming the marks for the entry will not > > change, but if the caller passed in NULL they get wrongly reset, and > > three call sites pass in NULL: > > drivers/infiniband/ulp/srpt/ib_srpt.c > > net/rds/ib.c > > net/smc/smc_ib.c > > Fixes: 0df91bb67334 ("RDMA/devices: Use xarray to store the client_data") > > There's no bug here. > > If you're actually storing NULL in the array, then the marks would go > away. That's inherent -- imagine you have an array with a single entry > at 64. Then you store NULL there. That causes the node to be deleted, > and the marks must necessarily disappear with it -- there's nowhere to > store them! Ah, it is allocating! These little behavior differences are tricky to remember over with infrequent use :( Jason