Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4288573ybv; Sun, 16 Feb 2020 18:38:03 -0800 (PST) X-Google-Smtp-Source: APXvYqwUrC5hq0AdfBdOVTdz4hoemGlxmyHb+88MpbtgAJJ4xdB6vjVq6ytWqQQQxXZa6Sn1RrFt X-Received: by 2002:a9d:6653:: with SMTP id q19mr10932938otm.94.1581907083780; Sun, 16 Feb 2020 18:38:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581907083; cv=none; d=google.com; s=arc-20160816; b=bN9LEIs/KPVWn6wGiWbYW+h1qZlFJBeGuP5VQNFsGnCh+U91iPvfGo9Mxc00Mv9dz2 k6pak3mgw3AcSb6BhPpPgijRaXn0GF2Uj/MRPtJKKUK+euPu6uCcPHvZzl9y8ExlAcTP coC8BM7HScvX6wbFdoXI/kC7lyptnjYPw6/2AW8a9VQBVsbvqPChEUu1ovzKJWqz2VHH hL9h4N8It/69fZ5OF4IJrOXzuPq9VM+8sA/5QdZRIjkPY8le4vgXuLzBZVuTrFAJdnpZ 2AJ3FSV+ggDa/hrxH4gPO4/gEV+pc4lLywoB4IaChh95nhuqQhP+P2a7CkXK9grdcUWN VQXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=ODPzU1+W3xDKOfUEO4avkziFE5uFGeOobPkogMYGmHU=; b=XIEtM80P9PwnF6zEguAjJS3qVBhyihl7zOrXgY7GIkHfXG9iA/Sqxhd8q7cQb4lmPJ +PDsQrlsHKGxBvTrvvh2+QtDKywn6Y3gL5ADCIgAYyridsWI6hk0aI85AG09W25NNGwF sXH/CzaLUm/d+Fe10RR58uhhroXy3MiLDyJklUqIGik01ZGmhbdA9kV7FbRJEJY42z5b qCNP8FK1D6pn2NACDRvwXvZfQNc9vCSxoDb0ZAK3OEGeTfL5Sy2Lod6XwLGn8yVFukNe gKeJ4D14u+bOTFrfqFLah6PtRlZ1NHjtH3m6f/UqOevnp2IsETbWn43DF7/TAJJ9msCh 1z+Q== 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 i20si5791617oie.119.2020.02.16.18.37.51; Sun, 16 Feb 2020 18:38:03 -0800 (PST) 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 S1726766AbgBQChc (ORCPT + 99 others); Sun, 16 Feb 2020 21:37:32 -0500 Received: from shards.monkeyblade.net ([23.128.96.9]:47850 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726656AbgBQChc (ORCPT ); Sun, 16 Feb 2020 21:37:32 -0500 Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id A80BE15383A6E; Sun, 16 Feb 2020 18:37:31 -0800 (PST) Date: Sun, 16 Feb 2020 18:37:31 -0800 (PST) Message-Id: <20200216.183731.2157450869886971370.davem@davemloft.net> To: jhubbard@nvidia.com Cc: akpm@linux-foundation.org, santosh.shilimkar@oracle.com, hans.westgaard.ry@oracle.com, leonro@mellanox.com, kuba@kernel.org, netdev@vger.kernel.org, rds-devel@oss.oracle.com, linux-rdma@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] net/rds: Track user mapped pages through special API From: David Miller In-Reply-To: <20200212030355.1600749-2-jhubbard@nvidia.com> References: <20200212030355.1600749-1-jhubbard@nvidia.com> <20200212030355.1600749-2-jhubbard@nvidia.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 16 Feb 2020 18:37:32 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: John Hubbard Date: Tue, 11 Feb 2020 19:03:55 -0800 > From: Leon Romanovsky > > Convert net/rds to use the newly introduces pin_user_pages() API, > which properly sets FOLL_PIN. Setting FOLL_PIN is now required for > code that requires tracking of pinned pages. > > Note that this effectively changes the code's behavior: it now > ultimately calls set_page_dirty_lock(), instead of set_page_dirty(). > This is probably more accurate. > > As Christoph Hellwig put it, "set_page_dirty() is only safe if we are > dealing with a file backed page where we have reference on the inode it > hangs off." [1] > > [1] https://lore.kernel.org/r/20190723153640.GB720@lst.de > > Cc: Hans Westgaard Ry > Cc: Santosh Shilimkar > Signed-off-by: Leon Romanovsky > Signed-off-by: John Hubbard Applied, thank you.