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:   Mon, 7 Nov 2022 12:20:08 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Oded Gabbay <ogabbay@kernel.org>
Cc:     David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        John Hubbard <jhubbard@nvidia.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
        Jiho Chu <jiho.chu@samsung.com>,
        Daniel Stone <daniel@fooishbar.org>,
        Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
        Jeffrey Hugo <quic_jhugo@quicinc.com>,
        Christoph Hellwig <hch@infradead.org>,
        Kevin Hilman <khilman@baylibre.com>,
        Jagan Teki <jagan@amarulasolutions.com>,
        Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
        Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>,
        Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>,
        Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [RFC PATCH v3 0/3] new subsystem for compute accelerator devices
Message-ID: <Y2kwOO9GOUF9DsJj@nvidia.com>
References: <20221106210225.2065371-1-ogabbay@kernel.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221106210225.2065371-1-ogabbay@kernel.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wO+0WUjhVa53Oi31Gnqx3YnmLFXwMs3pXGBlUoXH3kd7WDVMz8Q8iwUazl2f?=
 =?us-ascii?Q?yVclDAOxiGeUqdFxIqC63qIA/YANujdH9MFlzWD3iC/2zjQBayvWcXCyrcQA?=
 =?us-ascii?Q?RkjKxAZdMIvnpTznqpNOVVyNQ1LeFOTpLGFcJRpwzm0JzTxVQbiiTfneXXMv?=
 =?us-ascii?Q?NmV2CNj9d9tqnqZwUtsTK07Ggd4jIKBffXLqCWCDcGzX4bqGGHDl6VpgGHvR?=
 =?us-ascii?Q?nWLzWN0uOc5BvjfD4eBAHeGfUgLHi516yjvidjR5zhQC3BLKHPOR+j/K2Reh?=
 =?us-ascii?Q?W8J6cir2YOzKFCnnqfyPeyIjUM0QZUMJ8eiPC2qSIt30SAAh2v8Asx6qFutm?=
 =?us-ascii?Q?qw9/mNCKD7VdoQETXRFeTd8Oy+TIq0eYWAen5bGvIuVVZ5TKsNudXViVN2E0?=
 =?us-ascii?Q?gH4PBANmcYB7Ft6RgSMLxaaFhA9VRQkcHoPnB6s0/5E/htdC3U6IfSsQ3tiN?=
 =?us-ascii?Q?yB0mTEBfxurC6yZ4axnNp7XHCns9u19aTWwK9fad1FdbXjVedz5dUYsGXI45?=
 =?us-ascii?Q?t/gjcUVfoyZWc/Yv+C3fceRGcyMJzaX+w5CacYDV2gkPS59o93h9MIXtZI0F?=
 =?us-ascii?Q?skwmLrtEswJnsosjIl/Ekv6NM4Vo1gR/F0CXzKEL7yNWThTj1Z3adEMsm+Df?=
 =?us-ascii?Q?dFkzt7Oikdjbxps6OxyqCm+WX0QH9yF5c/41iVukqn9hF+rlXQtHLaqBPF5r?=
 =?us-ascii?Q?1Z/QJtJR9jG4/UMOMARoNWqD7uzHu4YdriDjCuRO07rbLLqRGLfmghF04qjR?=
 =?us-ascii?Q?2898fTTREbVt6GYHjqnc7STtjZMF4ZRVTRan8DJMWn9dm3FabVSzafHK/wGd?=
 =?us-ascii?Q?dSyxrTwV7udkwIY6PYjCfUWIwZFZ+83NTGm+L84a2lKZXP6S3O2lIW6AXDFb?=
 =?us-ascii?Q?k+fwZQhmmuUpj83TplWu29/ikGh6bMOgswUVPl2lC9yJr1ojhTlKueQOUxTy?=
 =?us-ascii?Q?MuWm2SDD+SyPM9doOks5MbeBYJn5R+GALFWR6FUi5mG3JHX6Jse2GpqH0A9q?=
 =?us-ascii?Q?JMEDnG1vxxfspTq5MTq4ua4m5HMyOfG8Hei1+HcFqjCvVAipZh5gQHbkDRhT?=
 =?us-ascii?Q?h845kDIHkB1HX5RzLQRSd7ofIkIkcVrMhkHnk3jzbT6d/S9kSNB8SUCG8nqI?=
 =?us-ascii?Q?NDvEUOeBa8C20IeRu83tasLtGU8anQaAup1WaA4KRb7UY9iSoVLt/kA7dQqQ?=
 =?us-ascii?Q?8gGaNidrSsaSZRwDx7s/3aGDFa1dI7EcqbM8ltv6/JX3TthKDiiUQfhIb2kf?=
 =?us-ascii?Q?n+KgpO1wBfImCNwHF4aJW6ZIvGO9rC7DWNZdNk4xTM9rcOeQ5BWOjLzFt1J/?=
 =?us-ascii?Q?1s75w+wJyWg6ZdQZzpwxjj7WYoWvanj4p8/bLejk/sIW7phfJCri64Zm6hC2?=
 =?us-ascii?Q?CL8U1QYBPzo25FEO1A+rH2Bs0mpf0cwn2QiSWEcmKEKjWva2RrtfJAcFriF5?=
 =?us-ascii?Q?nXv84LXRhjz6bIptcuyKxLljBxwG5P+zAd+DH+bPZvYjyNuoMi+moX101z+G?=
 =?us-ascii?Q?W68uRcl6DZUqw9io1h5fPMTh2Utr6ZvP6x/nPQF8vO/Qro7BlL261W6XPoJC?=
 =?us-ascii?Q?fIUxim1qpMsh9tX1SSs=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cf8746a0-08f0-44d1-5bfa-08dac0dbf0e2
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2022 16:20:09.9332
 (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: 7yrfkvwQjRArrWcl8X0aI9nUJRwBO/6dZiOaHV3COu4qDl6HmRttZE+TJHGFDSOW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6797
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no 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 Sun, Nov 06, 2022 at 11:02:22PM +0200, Oded Gabbay wrote:
> Another important change is that I have reverted back to use IDR for minor
> handling instead of xarray. This is because I have found that xarray doesn't
> handle well the scenario where you allocate a NULL entry and then exchange it
> with a real pointer. It appears xarray still considers that entry a "zero"
> entry. This is unfortunate because DRM works that way (first allocates a NULL
> entry and then replaces the entry with a real pointer).

This is what XA_ZERO_ENTRY is for.

Some APIs, like xa_alloc automatically promote NULL to XA_ZERO_ENTRY,
others require it to be explicit.

If you use the usual pattern of xa_alloc(NULL), xa_store(!NULL) then
you should be fine, as far as I know. So long as the xarray was tagged
as allocating.

Jason