From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31E653358A0 for ; Tue, 16 Dec 2025 19:44:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765914277; cv=none; b=A6Byep2Gbxx2R4Hz9U6KqnuQQ2XTrLYzcKusSMwbmzbrOLOJzh1wPcV5/8jI/SHsrgDirDpdwSTUDTO72OexAvJPZVlRsThJhAkHFhN5qu5fDUfYvSj4sdbUh6tuaMGdrm6VN9YgX9HY+GFxArlzpAbCeCejh8GDI8q1S0eDcdc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765914277; c=relaxed/simple; bh=6ifwb4jD2Yvr22/ylYYmmJ7+tU8lVupBVEbgDsUoIjM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=L59/emd9QeBz3zN/nojkcqQBN6z70YZxUqNtVJ8wX68h+MXsnANUuLoc4Nd+ydLjb/wQ0OlFXTcDQXAWuTlR3RyN5U5Osqppeq5JY5zgeM2X7z7PaPsN/8cQe3eoxnPeC61SaARiLljSqa1pQ3omlIp8AvWY4YLUCo8rIy9m/zk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JPNpLkhX; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=MRDNHF16; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JPNpLkhX"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="MRDNHF16" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765914274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OWZMfsrJ1GHpp0Gacc8vZFboQMCus5dZjsnuyY0r3Lc=; b=JPNpLkhXtjUEtBKfaJLQeq1psG/lEuZvzcJ0uMnCUTlcmNE0gHQe8AbDpONWbiYESdSZub F7zy4nLbmW4k9hHoddlymQa6OyXneQu6uz4ojKMcC3gP3xV84N3AdWNTJ1CMwMf/kmuJDF wZbSiRB9XDhv3Op6apQSqWGGigubSA4= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-312-pexhBvi0PTKxL37JJwzUAA-1; Tue, 16 Dec 2025 14:44:32 -0500 X-MC-Unique: pexhBvi0PTKxL37JJwzUAA-1 X-Mimecast-MFC-AGG-ID: pexhBvi0PTKxL37JJwzUAA_1765914272 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-4ee0995fa85so156065071cf.1 for ; Tue, 16 Dec 2025 11:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1765914272; x=1766519072; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OWZMfsrJ1GHpp0Gacc8vZFboQMCus5dZjsnuyY0r3Lc=; b=MRDNHF16pfU16aj2dNI5YNBzdZc3u50lYBLRQgXCF2EROCNVcVaH80PIeXYvQv1797 c7xhnxFj40v9HPlssmSrm84dTZFWPiX7FgUDoeCRpoTnOuS6a4xlSQbVXNajXyJrFfQJ Z+jqMs/sOxx02bXGz60lVcUKW/1TYh6Voq57AETueEJWGIxzS++VhHuwlxvvzj6ugOHz D/xNRVIHPutU9kbawlZSGeoHXTMTDZ04XwgGWIm4ehIBt6ZUzpEVrGU/32xo46hFMqIf b4UL6BPjqKl9LWk5P2pq33u5eoh1SjQ1XlqInzE69RZ14ToztVgxMlJQRrETui4FxEXB VtgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765914272; x=1766519072; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OWZMfsrJ1GHpp0Gacc8vZFboQMCus5dZjsnuyY0r3Lc=; b=EwOt+uk8Anrc3054z+6DBa5CYywMrOq+B8adReypUgJlJG0KVAGwJ/ic8pne0CD8+M KUql9eXk7JKINk2WxEeSKAIPDe36AyyYDMwY8xmMenAaO7LdShAF1mO6X9s8KiuzkBWq /JLLCqq5wMCCiyOppEnEnYsQyyinYk32gwUxlONSdW7xWm9gjqTVcbsMB40qsfTYHDr8 fC2oMR7z+InzbC0tUJiHH+ooZcuh7xeUAnwX3osny4cpJcj3oswHWL4W4GWLAwJJ+GCV +sLLCT3tRIkJIDrLKAoYsgBl9YeAWxECy0rmI8bB+AiUyde1KhpVBn5F8xSzoHZhGg6s 6JyA== X-Forwarded-Encrypted: i=1; AJvYcCX0cGTrPma7vJ5f5skm4ZpIcMWEGWnVKnpj1eRAYSPvV1lteq3Lh7nlZ4oWSOULfl/w2d/rtXlZQoBj1Ic=@vger.kernel.org X-Gm-Message-State: AOJu0Yw22KGrUqVfHEgcUYbsk6Tr+/lDG83K/HwsDLm4FKGVFZvnlg/D mQ7GXyMPNfAYSc6MPYtz3TzESY5NKq6b07Vd67e5hZeTVssJAVzJg+ulJW4mqar0xfjA1Zztyzb UaOXsn1dFjvMAaJ8EIYmlyBvKxHG1vfdTqmX5uzv0ru9F1w2i08VRgveFH8C0BXarhg== X-Gm-Gg: AY/fxX75WYmssLBHO5TnCbepWHqQEiazI3JaLBAM3ExqWSdurIAHHNhP9algAcFiap9 LynwbRKrA40m7B+4jMye5lRzWRVr8nvawaO9+JkYnz+EUK179//3RD+B1vw04RW9tQb4vMhFnhe kCw/zlvi2S7UbBA9fjK6KqBae2KC0h4jdL1zsgAcjpbCRp9XAT4mphLsu5YRZvb5InJhe48wesJ AQTwSpENLL3rp9U0gahy8SZi77yl+OfddS63VPX0OKcRFROXQK1PaiR7p4lVZfIOBuorfI/RCOI JP0YOLvOZdDw1K7wg1vwhBMe1au3b/Iw6yiDGYuqJFQApq+H7W2pqziKuW8SqPn8wO4WCL06mvv 5ZlU= X-Received: by 2002:a05:622a:5911:b0:4ed:b4ae:f5bb with SMTP id d75a77b69052e-4f1d05fda57mr230282321cf.65.1765914272154; Tue, 16 Dec 2025 11:44:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IGrrpjRFCD1x1zKDvh6gBnxEwhK0Ukm+SrqYrMtn8W42xybAzgzISZS5MGyj4ryNBGs0WxcZA== X-Received: by 2002:a05:622a:5911:b0:4ed:b4ae:f5bb with SMTP id d75a77b69052e-4f1d05fda57mr230281951cf.65.1765914271709; Tue, 16 Dec 2025 11:44:31 -0800 (PST) Received: from x1.local ([142.188.210.156]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4f345902748sm23150411cf.0.2025.12.16.11.44.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 11:44:31 -0800 (PST) Date: Tue, 16 Dec 2025 14:44:29 -0500 From: Peter Xu To: Jason Gunthorpe Cc: kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nico Pache , Zi Yan , Alex Mastro , David Hildenbrand , Alex Williamson , Zhi Wang , David Laight , Yi Liu , Ankit Agrawal , Kevin Tian , Andrew Morton Subject: Re: [PATCH v2 2/4] mm: Add file_operations.get_mapping_order() Message-ID: References: <20251204151003.171039-1-peterx@redhat.com> <20251204151003.171039-3-peterx@redhat.com> <20251216144427.GF6079@nvidia.com> <20251216171944.GG6079@nvidia.com> <20251216185850.GH6079@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20251216185850.GH6079@nvidia.com> On Tue, Dec 16, 2025 at 02:58:50PM -0400, Jason Gunthorpe wrote: > On Tue, Dec 16, 2025 at 12:36:13PM -0500, Peter Xu wrote: > > On Tue, Dec 16, 2025 at 01:19:44PM -0400, Jason Gunthorpe wrote: > > > On Tue, Dec 16, 2025 at 10:42:39AM -0500, Peter Xu wrote: > > > > Also see __thp_get_unmapped_area() processed such pgoff, it allocates VA > > > > with len_pad (not len), and pad the retval at last. > > > > > > > > Please let me know if it didn't work like it, then it might be a bug. > > > > > > It should all be documented then in the kdoc for the new ops, in this > > > kind of language that the resulting VA flows from pgoff > > > > IMHO that's one of the major benefits of this API, so that there's no need > > to mention impl details like this. > > It needs to be clearly explained exactly how pgoff and the returned > order are related because it impacts how the drivers need to manage > their pgoff space. Here "pgoff" plays two roles: (1) as a range, (pgoff, len) on top of the fd, decides which device blob to be mapped. This is relevant to the driver, for sure.. (2) as an offset, pgoff is relevant when we want to make sure mmap() request's VA will be aligned in a way so that we can maximize huge mappings. This has, IMHO, nothing to do with the driver, and that's what I want to make the new API transparent of. I agree drivers need to know pgoff for (1) in terms of get_mapping_order(), not (2). > > > Here the point is, the driver should only care about the size of mapping, > > nothing else like how exactly the alignments will be calculated, and how > > that interacts with pgoff. The kernel mm manages that. It's done exactly > > like what anon thp does already when len is pmd aligned. > > The driver owns the pgoff number space, it has to care about how that > relates to the PTEs. > > > Or maybe I misunderstood what you're suggesting to document? If so, please > > let me know; some example would be greatly helpful. > > Just document the 'VA % order = pgoff % order' equation in the kdoc > for the new op. When it's "related to PTEs", it's talking about (2) above, so that's really what I want to avoid mentioning. Docuemnt anything about VA is just confusing on its own especially when "int get_mapping_order(fd, pgoff, len)" doesn't even have anything in param or retval that is relevant to the virtual address space.. If you think missing such info is harder for reviews, I can definitely add a rich comment when repost explaining how __thp_get_unmapped_area() works here. We can also pause this a bit and wait for Matthew's review on the API, where he showed concerns. If there's major reason this API is rejected, we don't need to bother this part of detail either. Thanks, -- Peter Xu