Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 8 Jul 2023 06:39:14 +0000
From:   Matthew Brost <matthew.brost@intel.com>
To:     Boris Brezillon <boris.brezillon@collabora.com>
CC:     Danilo Krummrich <dakr@redhat.com>, <airlied@gmail.com>,
        <daniel@ffwll.ch>, <tzimmermann@suse.de>, <mripard@kernel.org>,
        <corbet@lwn.net>, <christian.koenig@amd.com>, <bskeggs@redhat.com>,
        <Liam.Howlett@oracle.com>, <alexdeucher@gmail.com>,
        <ogabbay@kernel.org>, <bagasdotme@gmail.com>,
        <willy@infradead.org>, <jason@jlekstrand.net>,
        <dri-devel@lists.freedesktop.org>, <nouveau@lists.freedesktop.org>,
        <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        Donald Robson <donald.robson@imgtec.com>,
        Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA
 mappings
Message-ID: <ZKkEkoHSGwICKwHf@DUT025-TGLU.fm.intel.com>
References: <20230629222651.3196-1-dakr@redhat.com>
 <20230629222651.3196-3-dakr@redhat.com>
 <20230707130010.1bd5d41b@collabora.com>
 <e92219d7-77f7-a40a-39d9-ea7afc5f3687@redhat.com>
 <20230707145241.6ea73643@collabora.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230707145241.6ea73643@collabora.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?oPG22WoMd6QB5Xm3bOcKptEeZzDZhAiYvkkZ6mtMTea5hHx1z5yKPw1KiQ6+?=
 =?us-ascii?Q?awlcRNjZDpstM2kDWnFmFzaciuRVeNLL29NJN8BiuUEOjP+JkOd4YLyzW1PH?=
 =?us-ascii?Q?QjqrJs6EfM6VEwqcoUJJmafyYd4JxMEqB+0z6jtau4lqgPvmHSP/lQysjnzi?=
 =?us-ascii?Q?rB4QR3vTmpdsMcNNYjNXOuywr58Z5RM2rbajFxUCtm+tgRjVBVzHe2T9PjyB?=
 =?us-ascii?Q?VcygfwsMxM/ZmR7/rIJX215KiSPLUMVUGek5hogEb6ekEvmAcmFEji9N0VQs?=
 =?us-ascii?Q?qcIKui63iImoPzcwUcAVokfizortY1mEetq0xPGCMbnD7g2XYS11eQwFmnQu?=
 =?us-ascii?Q?iXiJDJxfXX4OjS2TtzTcDbKY1vKLisPzu/PxqGykkEBbwoTIbk8HpOzVUVft?=
 =?us-ascii?Q?mR1qwEHI3oOvFrBkSfjKGWGmE+E0vLxvy6qxZ8NPyCg4QyHc8R+FiHy4APSO?=
 =?us-ascii?Q?6pKvubd3u5cVOPesHyQNXBbGx0Zki5+fDWGbzpzD5cb7+GTzrjVLbonWBdk6?=
 =?us-ascii?Q?QkUHtjcKzpC5FyG4jf65VbWDente6vbElk/G1cvyUEhvlEidAftB43kBUC7Z?=
 =?us-ascii?Q?3pJL0VOdfB4btyr55U115S2xe68bpjQnacM4F7mcItU+Qjqo3JrZ5EE2ylFm?=
 =?us-ascii?Q?XZIzmFcLejoIu9KcknqX6hmwOQhOWbNwVUtCvotqUQ57CVXpk1QfuPhsnK1Y?=
 =?us-ascii?Q?Ao0Jt6CCvxQrz4bEEadYeDWskCtYe7Q26Tx4Nd/KUxDYlV1jxULONjh92W70?=
 =?us-ascii?Q?K1enNBYhVXHZffC2F847+IVSwZQLxsuNYpYe2mo/Ak7OxPpiXDvJxU/lgwmL?=
 =?us-ascii?Q?+86AyScwg68iP2q1GqZHiHjsvkrf39CIUdkfZlmXhiizFdDSDiE+jfFzT6wK?=
 =?us-ascii?Q?k51tWVK8lYqON2oGks1tum5NIAXovQ4gHXs34C45MUUdChV3uloSNw5/yMmc?=
 =?us-ascii?Q?SZA1wI3NhqUWcac4qsPdUExxBMY9eFuYaZFga7/8iehrdi3HWh4y6/I+7ep1?=
 =?us-ascii?Q?oima/Hflck4gXgHdGAJKnQTpj3uJOd2exHnpqv9ozCErNvY8A1Ys6+cM9hM8?=
 =?us-ascii?Q?beriX/nbs9FDYbWdKeVxBTOtBIGKZkQ6gQDiUXntPWyKFGiOW61Dn74H0TkS?=
 =?us-ascii?Q?Ru6FhEZiV8ap/FDmi/F47UL9I9GTpMmlt09IpVSmGOnTtjbKaDjCeJp47H/w?=
 =?us-ascii?Q?bfrWhU3wgQUJtgmIUPw456B05z/CUFQcDDEfDSYzgoOLUDzrPnq8Hhnq+uCc?=
 =?us-ascii?Q?qJ8vP2rcTb3QXsKLTuMHWeTBOMXcpN9LrT6sGnYB31EHf3AifL19r6/19H64?=
 =?us-ascii?Q?qyE6dMp6A4Vz8/6DyTu5wqMajnwNOZmmn06YhtzmoVqAS+aS7zcAyicL/pb2?=
 =?us-ascii?Q?cOKPRAOG9Yvc8N+sLSzY38v7YQx/sUhk/s1XuQlvA83R9TA0/nli8JxwZs5K?=
 =?us-ascii?Q?mJZD1hp9TonmtryxR0g8SY2bLvtITabog2MVVt+OtLomtXcsGiFw+tgkRmiu?=
 =?us-ascii?Q?2jmGNUwMmJ3/PYrI4eAs1E5AO43jKl3dopC7tPELLzSyaB20TXnxCCIR7kK4?=
 =?us-ascii?Q?KERBfxiC7lEUvrtm7WHPBZ+ygQc9Gsqbfe13T0IEVBN+GaqDRXfWZCbokGy8?=
 =?us-ascii?Q?Vw=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: c4824476-6ef1-45cd-f14e-08db7f7e2251
X-MS-Exchange-CrossTenant-AuthSource: PH7PR11MB6522.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2023 06:39:52.4223
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vG/y4li/jpIYoI7V1QY/b6NV+juNJ9coyNbEvCWLFvqsr/AtiJliQuKw+N9iFIkJYWbArRLF2X/DgwbR+/RahA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5462
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jul 07, 2023 at 02:52:41PM +0200, Boris Brezillon wrote:
> On Fri, 7 Jul 2023 14:41:23 +0200
> Danilo Krummrich <dakr@redhat.com> wrote:
> 
> > >> +	     va__ && (va__->va.addr < (end__)) && \
> > >> +	     !list_entry_is_head(va__, &(mgr__)->rb.list, rb.entry); \
> > >> +	     va__ = list_next_entry(va__, rb.entry))  
> > > 
> > > If you define:
> > > 
> > > static inline struct drm_gpuva *
> > > drm_gpuva_next(struct drm_gpuva *va)
> > > {
> > > 	if (va && !list_is_last(&va->rb.entry, &va->mgr->rb.list))
> > > 		return list_next_entry(va, rb.entry);
> > > 
> > > 	return NULL;
> > > } >
> > > the for loop becomes a bit more readable:  
> > 
> > Yes, it would. However, I don't want it to be confused with 
> > drm_gpuva_find_next(). Maybe I should rename the latter to something 
> > like drm_gpuva_find_next_neighbor() then.
> 
> If you want to keep drm_gpuva_find_next(), feel free to rename/prefix
> the drm_gpuva_next() function. I was just posting it as a reference.
> 
> > 
> > > 
> > > 	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)); \
> > > 	     va__ && (va__->va.addr < (end__)); \
> > > 	     va__ = drm_gpuva_next(va__))
> > >   
> > >> +
> > >> +/**
> > >> + * drm_gpuva_for_each_va_range_safe - iternator to safely walk over a range of
> > >> + * &drm_gpuvas
> > >> + * @va__: &drm_gpuva to assign to in each iteration step
> > >> + * @next__: another &drm_gpuva to use as temporary storage
> > >> + * @mgr__: &drm_gpuva_manager to walk over
> > >> + * @start__: starting offset, the first gpuva will overlap this
> > >> + * @end__: ending offset, the last gpuva will start before this (but may
> > >> + * overlap)
> > >> + *
> > >> + * This iterator walks over all &drm_gpuvas in the &drm_gpuva_manager that lie
> > >> + * between @start__ and @end__. It is implemented similarly to
> > >> + * list_for_each_safe(), but is using the &drm_gpuva_manager's internal interval
> > >> + * tree to accelerate the search for the starting &drm_gpuva, and hence is safe
> > >> + * against removal of elements. It assumes that @end__ is within (or is the
> > >> + * upper limit of) the &drm_gpuva_manager. This iterator does not skip over the
> > >> + * &drm_gpuva_manager's @kernel_alloc_node.
> > >> + */
> > >> +#define drm_gpuva_for_each_va_range_safe(va__, next__, mgr__, start__, end__) \
> > >> +	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__)), \
> > >> +	     next__ = va ? list_next_entry(va__, rb.entry) : NULL; \
> > >> +	     va__ && (va__->va.addr < (end__)) && \
> > >> +	     !list_entry_is_head(va__, &(mgr__)->rb.list, rb.entry); \
> > >> +	     va__ = next__, next__ = list_next_entry(va__, rb.entry))  
> > > 
> > > And this is the safe version using the drm_gpuva_next() helper:
> > > 
> > > 	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)), \
> > > 	     next__ = drm_gpuva_next(va__); \
> > > 	     va__ && (va__->va.addr < (end__)); \
> > > 	     va__ = next__, next__ = drm_gpuva_next(va__))
> > > 
> > > Those changes fixed an invalid pointer access I had in the sm_unmap()
> > > path.
> > >   
> > 
> > Sorry you did run into this bug.
> 
> No worries, that's what testing/debugging/reviewing is for. And I'm glad
> someone decided to work on this gpuva stuff so I don't have to code it
> myself, so that's the least I can do.

With Boris's changes this version works in Xe.

With that:

Acked-by: Matthew Brost <matthew.brost@intel.com>
Tested-by: Matthew Brost <matthew.brost@intel.com>