Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Thu, 16 Nov 2023 11:31:47 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Yunsheng Lin <linyunsheng@huawei.com>
Cc:     Mina Almasry <almasrymina@google.com>,
        Jakub Kicinski <kuba@kernel.org>, davem@davemloft.net,
        pabeni@redhat.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Willem de Bruijn <willemb@google.com>,
        Kaiyuan Zhang <kaiyuanz@google.com>,
        Jesper Dangaard Brouer <hawk@kernel.org>,
        Ilias Apalodimas <ilias.apalodimas@linaro.org>,
        Eric Dumazet <edumazet@google.com>,
        Christian =?utf-8?B?S8O2bmln?= <christian.koenig@amd.com>,
        Matthew Wilcox <willy@infradead.org>,
        Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH RFC 3/8] memory-provider: dmabuf devmem memory provider
Message-ID: <ZVY14zBmi1wgZBiw@nvidia.com>
References: <20231113130041.58124-1-linyunsheng@huawei.com>
 <20231113130041.58124-4-linyunsheng@huawei.com>
 <CAHS8izMjmj0DRT_vjzVq5HMQyXtZdVK=o4OP0gzbaN=aJdQ3ig@mail.gmail.com>
 <20231113180554.1d1c6b1a@kernel.org>
 <0c39bd57-5d67-3255-9da2-3f3194ee5a66@huawei.com>
 <CAHS8izNxkqiNbTA1y+BjQPAber4Dks3zVFNYo4Bnwc=0JLustA@mail.gmail.com>
 <ZVNzS2EA4zQRwIQ7@nvidia.com>
 <ed875644-95e8-629a-4c28-bf42329efa56@huawei.com>
 <ZVTJ0/lm1oUDzzHe@nvidia.com>
 <0a1cdd5a-c4c5-3d77-20a2-2beb8e3a6411@huawei.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0a1cdd5a-c4c5-3d77-20a2-2beb8e3a6411@huawei.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?SalxX0l0mbvb4JaLOjGZmgfHyt55sZ/6z54FDTQOfLjyquJFGzr4yk1YhCOU?=
 =?us-ascii?Q?9TI4sAYlEPnnUgqvRQriH0bQiHkCsYuv9TQAZk01Wwmx5m95l9d0VBxOjhTI?=
 =?us-ascii?Q?AVVxL1Ljfi4dOcAA1Yj/agW+eKhpkvK5fkvMqry9Zz/9+BRmegot2yoMrYRE?=
 =?us-ascii?Q?azqrgnoKC1WJzSfiUMYz2kiIF2JCRS78aZpmpT6zeOlHknsYGxsPpBVerZSp?=
 =?us-ascii?Q?XI4trQ7p0k0Uvggd3Qzkhj5EuEm/e7Yc07pop+8TAMgh0ywPG06UI/TQyjze?=
 =?us-ascii?Q?wItDajRNzEAqQ8AIadpSrjEGrTSX0QexUBoNx0nZZ0ZBRNB54idSAUlp5Kas?=
 =?us-ascii?Q?e+AAmRz5lOPTsI3glSrjdNVvgavjUY9Lx/ZvtSO8WR9EQHZcfGi5QqLHRXQs?=
 =?us-ascii?Q?CO3Cgcf41TWJiVNUoFUvSMWr6PNn/rkHWpiZ34fiRjhzVThCvJN6H6Q29qPs?=
 =?us-ascii?Q?Enxvt1g0CK44bSvuMYFQ4VliGKy6vrgvnO12pxlCAkticEBFN9PEm6LYBl+/?=
 =?us-ascii?Q?qmRMi0qicE4tg0pEGICj9ZSA2sv8w/a6FyUcWBAQ/flu1arVImK5jKmLo3Xi?=
 =?us-ascii?Q?9U6k0KkaW1BktKhSRi9P9FG9rgatINFtZOs8hWh+GLVywmNUtvNdBt6JAFsC?=
 =?us-ascii?Q?gXvO8r2PgQwHc8XqMjDlI+PUzVcAtcFvNrjCHc0l1Ijk6Ff+5jZF5Adu1xy8?=
 =?us-ascii?Q?xW9xAj2fQW459Zrn24EDHbeQAZJ3a/T/H7A/x5n0qoS6EsralEOwEPE7kB06?=
 =?us-ascii?Q?PUC+dPpuQbBjC4+9YekFWH85t0gLfnPa0hW/BZ9bwcYQWz3MBcmlaswCKPAA?=
 =?us-ascii?Q?RRH5OqgSV3mF3D3EGV/jarCJldkizsclQqVeBT0rHCm/251Lz+GKNz2Ulzoo?=
 =?us-ascii?Q?SSbuzl/gA9GAe7d+fTn7bzJXryk8DKOyhUzc6p/CiB5BI7NqOMl63HfRes0V?=
 =?us-ascii?Q?2goqpM7oUet+m+qXUfrK9amnRbCiCCSe38kx57OwVA//Nsb2ISgKTDrV2qtp?=
 =?us-ascii?Q?uADOxJb/OHMAw+ijdt2P7I02ElL+gKvL1uOpNg0XXCHQEVYAWbNJExUng7gQ?=
 =?us-ascii?Q?8tYxufjbK3hkqDISA6Dtd8diFDXRhe+Z73/U7MxjKwAckEwQAwwSHKHnTwma?=
 =?us-ascii?Q?CCJ2I4E7I1L0gC7FlEnQJirfvHlvVt0JIXznHUnficAWO5QXNpun7v1YVna8?=
 =?us-ascii?Q?45/2OCDSIa+oeNnfupUOsTOP5uMrek97zab+zvBeRniGLns9+iBGoBtQz63f?=
 =?us-ascii?Q?SAU+7IBTRk54ikDQTAhKFgDY3qxG0BrUWmN/y8VVT+eR7MUErq4V0qLXx8YY?=
 =?us-ascii?Q?Mlgk4P9ZCAGiGMP4wxFbSGjn4t7gtWLYzEYvjuAlsDzUzOLuk1d/7jRW8YIr?=
 =?us-ascii?Q?2oCOFQckET3ETj6VuGC0rIcyzTRuEqGGR5DQsYWjZ1hOPW+eotvXTv6p1k7z?=
 =?us-ascii?Q?sUuOdsJrnyuYmEd7+lI7x5OCPW3eWi0umM5gVViQFYoSbW67tYqcZNxAJSCH?=
 =?us-ascii?Q?rAOdNBjJScbIIxk/244Tha1WGg+au5xgQ2mUpI3QZVdieK+Z8z9JG8e3tcT/?=
 =?us-ascii?Q?f8MUx22oRs5v3YfFfvhIn2Lu5HatGotnLD5dkkt9?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d2036a7-a806-4355-1717-08dbe6b925e4
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2023 15:31:48.3994
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JFrTSH138ZaUuBrwLePA3Kpo2JQj3fzVaA6pD4EBLFvWj1d7eu5hG3jWd1UtJ6pH
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6280
X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,
	URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Thu, 16 Nov 2023 07:32:59 -0800 (PST)

On Thu, Nov 16, 2023 at 07:10:01PM +0800, Yunsheng Lin wrote:
> On 2023/11/15 21:38, Jason Gunthorpe wrote:
> > On Wed, Nov 15, 2023 at 05:21:02PM +0800, Yunsheng Lin wrote:
> > 
> >>>>> I would expect net stack, page pool, driver still see the 'struct page',
> >>>>> only memory provider see the specific struct for itself, for the above,
> >>>>> devmem memory provider sees the 'struct page_pool_iov'.
> >>>>>
> >>>>> The reason I still expect driver to see the 'struct page' is that driver
> >>>>> will still need to support normal memory besides devmem.
> >>>
> >>> I wouldn't say this approach is unreasonable, but it does have to be
> >>> done carefully to isolate the mm. Keeping the struct page in the API
> >>> is going to make this very hard.
> >>
> >> I would expect that most of the isolation is done in page pool, as far as
> >> I can see:
> > 
> > It is the sort of thing that is important enough it should have
> > compiler help via types to prove that it is being done
> > properly. Otherwise it will be full of mistakes over time.
> 
> Yes, agreed.
> 
> I have done something similar as willy has done for some of
> folio conversion as below:

That is not at all what I mean, I mean you should not use
struct page * types at all in code that flows from the _iov version
except via limited accessors that can be audited and have appropriate
assertions.

Just releasing struct page * that is not a struct page * everywhere
without type safety will never be correct long term.

Jason