Message ID | 20230217134422.14116-4-dakr@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp893752wrn; Fri, 17 Feb 2023 05:48:17 -0800 (PST) X-Google-Smtp-Source: AK7set8atKxDaLibv8lMmSt85RMdoPM1eQ2/drRKGxyZFYUGH0d5WcfUWY5zbOWS+7zWUd8sQyvj X-Received: by 2002:a17:90b:3507:b0:233:f447:1271 with SMTP id ls7-20020a17090b350700b00233f4471271mr11642185pjb.43.1676641697165; Fri, 17 Feb 2023 05:48:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676641697; cv=none; d=google.com; s=arc-20160816; b=JTXiXq+ee7m4Bu4x2bQlYsi/k+yCbGGxuk06nY03k3QfTS5ywEpWLk95DyTg2Vtqve bEWgffO4MwmilD3Ik2jP+vxW++zVxbwSt/9EdKKa8ZUGhEPXrQYYQYrLlW0+g7ybnecJ UW6/6x/1QY+1DXi3AS1WNfYcwL/R8ttu7PEiWrfxt+cjucQIrOhVUNLcRPqHFp69cQh3 IMdnAy4Tgvwk0aJ/f3i4Vv++P0dVavuQbySL0fYZqkmTU8+IFRZmWnocT20G/XvoHKi1 kr89qC9Bkt3UcQNYJ0hLLQUnMjPqxvaFghqkjmNszmnTsYDlh0G2cKNKgpVYI3XfCtj4 kzGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ysk0aOdzp2igGOtHeZoTd2E71aY9qQ/NU2yUGbV3q7I=; b=MebNBEgHDvl0sWxeodDLtSzWkGvHQvAVe3IVtNNkMDyDhKpMnxn5bIxFYr5C3d+Ap4 ui2b3dUTSARssgsRw7gzHwaW5NIC072swLFRyvtLe7SNozRedPKUss498URKtuau11qH cG+1xdKg6D9FFcPmuDZPG+maOFpmpHu9oWOZ66x5Vc34/4wM68D6pHkrsnDU5gMftms0 8XggBi6NXAJRiyRltDLTiYsq/sRI/YLqAjndHVcW8S8q46K1u719QBTHXoo4RWPPJ9he 93VRregd1+BRaLFWh88Qm+QIJ/hLoosuNOejSFcBym0AEiNN95AP7eaGS6pJ09WokwuV K0gA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PMCDPjjT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lk12-20020a17090b33cc00b0023451b54b2fsi5660867pjb.165.2023.02.17.05.48.05; Fri, 17 Feb 2023 05:48:17 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PMCDPjjT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229902AbjBQNpx (ORCPT <rfc822;aimixsaka@gmail.com> + 99 others); Fri, 17 Feb 2023 08:45:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229768AbjBQNpa (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 17 Feb 2023 08:45:30 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6607C13D65 for <linux-kernel@vger.kernel.org>; Fri, 17 Feb 2023 05:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676641483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ysk0aOdzp2igGOtHeZoTd2E71aY9qQ/NU2yUGbV3q7I=; b=PMCDPjjTA/rrNGC4Vylab7IVxFwRiyFhD8G72minNrGtbNkC3/7L1zKz41lIALSi7RaCJF V88vnFD2EJdvIo8nsmfj4TXP4dj9BytB9FjNLzSHF+s/hS6X0Hkcxs+b/RdH0JFTxySc+e ZufSTYlUEtWXTZeOcSVQAZOC0N1ui7o= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-673-M4VkDKjFNnmdZfWubZMmgA-1; Fri, 17 Feb 2023 08:44:42 -0500 X-MC-Unique: M4VkDKjFNnmdZfWubZMmgA-1 Received: by mail-ed1-f69.google.com with SMTP id d9-20020a056402400900b004ad062fee5eso1727798eda.17 for <linux-kernel@vger.kernel.org>; Fri, 17 Feb 2023 05:44:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ysk0aOdzp2igGOtHeZoTd2E71aY9qQ/NU2yUGbV3q7I=; b=7Ly/Xh5XfWS/eu8q+6erM7HnTDp0DMa5vtjijm32CEanJu/8Tc45Z0i4jRI+glUe+g zOoEvGfkgXckCei4DOiyk/VpDJ/H0yQD5kTSZxLn6+K2GlqqaFgrek84p7urLV+S+jGX LkY4NZG+7Zeo+csVzmhsz+TeYwjWeXMaeM7TmHOfgr3SYIIm1RGnLVp/OSGyVTDpHxv8 mXIWdjtG+AGlUhxakLeaMFjSkK85wkPGL6klbEna3nU0WRe2wYPPa0XpHmL3OCNdoldl /YrinjtkHEz3c+12ZIMn68w2hOZ/sTJSGjskk9gRX/H31MqUp71ua2MtuaFGLWZC6PxC 7i5A== X-Gm-Message-State: AO0yUKX1JIbxNPRb9i3XpYFEe2cnFrO1SBDEVsbD1tOHLvR67p2NBHTB pJjEnRcWnHTKq8iiU/9MjrRlGY2el0wlZOZy0dzGMWApnUoCAKj6vxaDLdCp0Qapmx4RABayQHP OHmZJf/Tg3yTiHrx60i7kxdgs X-Received: by 2002:a17:907:d309:b0:8b1:2dda:b60d with SMTP id vg9-20020a170907d30900b008b12ddab60dmr5401603ejc.20.1676641481149; Fri, 17 Feb 2023 05:44:41 -0800 (PST) X-Received: by 2002:a17:907:d309:b0:8b1:2dda:b60d with SMTP id vg9-20020a170907d30900b008b12ddab60dmr5401592ejc.20.1676641481019; Fri, 17 Feb 2023 05:44:41 -0800 (PST) Received: from cassiopeiae.. ([2a02:810d:4b3f:de78:642:1aff:fe31:a19f]) by smtp.gmail.com with ESMTPSA id r10-20020a1709063d6a00b00882f9130eafsm2167138ejf.26.2023.02.17.05.44.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Feb 2023 05:44:40 -0800 (PST) From: Danilo Krummrich <dakr@redhat.com> To: 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, matthew.brost@intel.com, boris.brezillon@collabora.com, alexdeucher@gmail.com, ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org, jason@jlekstrand.net Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Danilo Krummrich <dakr@redhat.com> Subject: [PATCH drm-next v2 03/16] maple_tree: split up MA_STATE() macro Date: Fri, 17 Feb 2023 14:44:09 +0100 Message-Id: <20230217134422.14116-4-dakr@redhat.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230217134422.14116-1-dakr@redhat.com> References: <20230217134422.14116-1-dakr@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758086243837785472?= X-GMAIL-MSGID: =?utf-8?q?1758086243837785472?= |
Series |
DRM GPUVA Manager & Nouveau VM_BIND UAPI
|
|
Commit Message
Danilo Krummrich
Feb. 17, 2023, 1:44 p.m. UTC
Split up the MA_STATE() macro such that components using the maple tree
can easily inherit from struct ma_state and build custom tree walk
macros to hide their internals from users.
Example:
struct sample_iter {
struct ma_state mas;
struct sample_mgr *mgr;
struct sample_entry *entry;
};
\#define SAMPLE_ITER(name, __mgr) \
struct sample_iter name = { \
.mas = __MA_STATE(&(__mgr)->mt, 0, 0),
.mgr = __mgr,
.entry = NULL,
}
\#define sample_iter_for_each_range(it__, start__, end__) \
for ((it__).mas.index = start__, (it__).entry = mas_find(&(it__).mas, end__ - 1); \
(it__).entry; (it__).entry = mas_find(&(it__).mas, end__ - 1))
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
---
include/linux/maple_tree.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
* Danilo Krummrich <dakr@redhat.com> [230217 08:44]: > Split up the MA_STATE() macro such that components using the maple tree > can easily inherit from struct ma_state and build custom tree walk > macros to hide their internals from users. > > Example: > > struct sample_iter { > struct ma_state mas; > struct sample_mgr *mgr; > struct sample_entry *entry; > }; > > \#define SAMPLE_ITER(name, __mgr) \ > struct sample_iter name = { \ > .mas = __MA_STATE(&(__mgr)->mt, 0, 0), > .mgr = __mgr, > .entry = NULL, > } I see this patch is to allow for anonymous maple states, this looks good. I've a lengthy comment about the iterator that I'm adding here to head off anyone that may copy your example below. > > \#define sample_iter_for_each_range(it__, start__, end__) \ > for ((it__).mas.index = start__, (it__).entry = mas_find(&(it__).mas, end__ - 1); \ > (it__).entry; (it__).entry = mas_find(&(it__).mas, end__ - 1)) I see you've added something like the above in your patch set as well. I'd like to point out that the index isn't the only state information that needs to be altered here, and in fact, this could go very wrong. The maple state has a node and an offset within that node. If you set the index to lower than the current position of your iterator and call mas_find() then what happens is somewhat undefined. I expect you will get the wrong value (most likely either the current value or the very next one that the iterator is already pointing to). I believe you have been using a fresh maple state for each iterator in your patches, but I haven't had a deep look into your code yet. We have methods of resetting the iterator and set the range (mas_set() and mas_set_range()) which are safe for what you are doing, but they will start the walk from the root node to the index again. So, if you know what you are doing is safe, then the way you have written it will work, but it's worth mentioning that this could occur. It is also worth pointing out that it would be much safer to use a function to do the above so you get type safety.. and I was asked to add this to the VMA interface by Linus [1], which is on its way upstream [2]. 1. https://lore.kernel.org/linux-mm/CAHk-=wg9WQXBGkNdKD2bqocnN73rDswuWsavBB7T-tekykEn_A@mail.gmail.com/ 2. https://lore.kernel.org/linux-mm/20230120162650.984577-1-Liam.Howlett@oracle.com/ > > Signed-off-by: Danilo Krummrich <dakr@redhat.com> > --- > include/linux/maple_tree.h | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/include/linux/maple_tree.h b/include/linux/maple_tree.h > index e594db58a0f1..ca04c900e51a 100644 > --- a/include/linux/maple_tree.h > +++ b/include/linux/maple_tree.h > @@ -424,8 +424,8 @@ struct ma_wr_state { > #define MA_ERROR(err) \ > ((struct maple_enode *)(((unsigned long)err << 2) | 2UL)) > > -#define MA_STATE(name, mt, first, end) \ > - struct ma_state name = { \ > +#define __MA_STATE(mt, first, end) \ > + { \ > .tree = mt, \ > .index = first, \ > .last = end, \ > @@ -435,6 +435,9 @@ struct ma_wr_state { > .alloc = NULL, \ > } > > +#define MA_STATE(name, mt, first, end) \ > + struct ma_state name = __MA_STATE(mt, first, end) > + > #define MA_WR_STATE(name, ma_state, wr_entry) \ > struct ma_wr_state name = { \ > .mas = ma_state, \ > -- > 2.39.1 >
On Fri, Feb 17, 2023 at 02:44:09PM +0100, Danilo Krummrich wrote: > \#define SAMPLE_ITER(name, __mgr) \ > struct sample_iter name = { \ > .mas = __MA_STATE(&(__mgr)->mt, 0, 0), This is usually called MA_STATE_INIT() > #define sample_iter_for_each_range(it__, start__, end__) \ > for ((it__).mas.index = start__, (it__).entry = mas_find(&(it__).mas, end__ - 1); \ > (it__).entry; (it__).entry = mas_find(&(it__).mas, end__ - 1)) This is a bad iterator design. It's usually best to do this: struct sample *sample; SAMPLE_ITERATOR(si, min); sample_iter_for_each(&si, sample, max) { frob(mgr, sample); } I don't mind splitting apart MA_STATE_INIT from MA_STATE, and if you do that, we can also use it in VMA_ITERATOR.
On 2/17/23 20:45, Matthew Wilcox wrote: > On Fri, Feb 17, 2023 at 02:44:09PM +0100, Danilo Krummrich wrote: >> \#define SAMPLE_ITER(name, __mgr) \ >> struct sample_iter name = { \ >> .mas = __MA_STATE(&(__mgr)->mt, 0, 0), > > This is usually called MA_STATE_INIT() Yep, that's better. > >> #define sample_iter_for_each_range(it__, start__, end__) \ >> for ((it__).mas.index = start__, (it__).entry = mas_find(&(it__).mas, end__ - 1); \ >> (it__).entry; (it__).entry = mas_find(&(it__).mas, end__ - 1)) > > This is a bad iterator design. It's usually best to do this: > > struct sample *sample; > SAMPLE_ITERATOR(si, min); > > sample_iter_for_each(&si, sample, max) { > frob(mgr, sample); > } > The reason why I don't set index (and max) within SAMPLE_ITER() is that the range to iterate might not yet be known at that time, so I thought it could just be set in sample_iter_for_each_range(). However, I see that this might prevail users to assume that it's safe to iterate a range based on the same iterator instance multiple times though. Instead users should maybe move the tree walk to another function once the range is known. The reason for the payload structure to be part of the iterator is that I have two maple trees in the GPUVA manager and hence two different payload types. Within the iterator structure they're just within a union allowing me to implement the tree walk macro just once rather than twice. Anyway, I feel like your approach looks cleaner, hence I'll change it. > I don't mind splitting apart MA_STATE_INIT from MA_STATE, and if you > do that, we can also use it in VMA_ITERATOR. >
On 2/17/23 19:34, Liam R. Howlett wrote: > * Danilo Krummrich <dakr@redhat.com> [230217 08:44]: >> Split up the MA_STATE() macro such that components using the maple tree >> can easily inherit from struct ma_state and build custom tree walk >> macros to hide their internals from users. >> >> Example: >> >> struct sample_iter { >> struct ma_state mas; >> struct sample_mgr *mgr; >> struct sample_entry *entry; >> }; >> >> \#define SAMPLE_ITER(name, __mgr) \ >> struct sample_iter name = { \ >> .mas = __MA_STATE(&(__mgr)->mt, 0, 0), >> .mgr = __mgr, >> .entry = NULL, >> } > > I see this patch is to allow for anonymous maple states, this looks > good. > > I've a lengthy comment about the iterator that I'm adding here to head > off anyone that may copy your example below. > >> >> \#define sample_iter_for_each_range(it__, start__, end__) \ >> for ((it__).mas.index = start__, (it__).entry = mas_find(&(it__).mas, end__ - 1); \ >> (it__).entry; (it__).entry = mas_find(&(it__).mas, end__ - 1)) > > I see you've added something like the above in your patch set as well. > I'd like to point out that the index isn't the only state information > that needs to be altered here, and in fact, this could go very wrong. > > The maple state has a node and an offset within that node. If you set > the index to lower than the current position of your iterator and call > mas_find() then what happens is somewhat undefined. I expect you will > get the wrong value (most likely either the current value or the very > next one that the iterator is already pointing to). I believe you have > been using a fresh maple state for each iterator in your patches, but I > haven't had a deep look into your code yet. Yes, I'm aware that I'd need to reset the whole iterator in order to re-use it. Regarding the other considerations of the iterator design please see my answer to Matthew. > > We have methods of resetting the iterator and set the range (mas_set() > and mas_set_range()) which are safe for what you are doing, but they > will start the walk from the root node to the index again. > > So, if you know what you are doing is safe, then the way you have > written it will work, but it's worth mentioning that this could occur. > > It is also worth pointing out that it would be much safer to use a > function to do the above so you get type safety.. and I was asked to add > this to the VMA interface by Linus [1], which is on its way upstream [2]. > > 1. https://lore.kernel.org/linux-mm/CAHk-=wg9WQXBGkNdKD2bqocnN73rDswuWsavBB7T-tekykEn_A@mail.gmail.com/ > 2. https://lore.kernel.org/linux-mm/20230120162650.984577-1-Liam.Howlett@oracle.com/ You mean having wrappers like sample_find() instead of directly using mas_find()? > >> >> Signed-off-by: Danilo Krummrich <dakr@redhat.com> >> --- >> include/linux/maple_tree.h | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/maple_tree.h b/include/linux/maple_tree.h >> index e594db58a0f1..ca04c900e51a 100644 >> --- a/include/linux/maple_tree.h >> +++ b/include/linux/maple_tree.h >> @@ -424,8 +424,8 @@ struct ma_wr_state { >> #define MA_ERROR(err) \ >> ((struct maple_enode *)(((unsigned long)err << 2) | 2UL)) >> >> -#define MA_STATE(name, mt, first, end) \ >> - struct ma_state name = { \ >> +#define __MA_STATE(mt, first, end) \ >> + { \ >> .tree = mt, \ >> .index = first, \ >> .last = end, \ >> @@ -435,6 +435,9 @@ struct ma_wr_state { >> .alloc = NULL, \ >> } >> >> +#define MA_STATE(name, mt, first, end) \ >> + struct ma_state name = __MA_STATE(mt, first, end) >> + >> #define MA_WR_STATE(name, ma_state, wr_entry) \ >> struct ma_wr_state name = { \ >> .mas = ma_state, \ >> -- >> 2.39.1 >> >
* Danilo Krummrich <dakr@redhat.com> [230220 09:38]: > On 2/17/23 19:34, Liam R. Howlett wrote: > > * Danilo Krummrich <dakr@redhat.com> [230217 08:44]: > > > Split up the MA_STATE() macro such that components using the maple tree > > > can easily inherit from struct ma_state and build custom tree walk > > > macros to hide their internals from users. > > > > > > Example: > > > > > > struct sample_iter { > > > struct ma_state mas; > > > struct sample_mgr *mgr; > > > struct sample_entry *entry; > > > }; > > > > > > \#define SAMPLE_ITER(name, __mgr) \ > > > struct sample_iter name = { \ > > > .mas = __MA_STATE(&(__mgr)->mt, 0, 0), > > > .mgr = __mgr, > > > .entry = NULL, > > > } > > > > I see this patch is to allow for anonymous maple states, this looks > > good. > > > > I've a lengthy comment about the iterator that I'm adding here to head > > off anyone that may copy your example below. > > > > > > > > \#define sample_iter_for_each_range(it__, start__, end__) \ > > > for ((it__).mas.index = start__, (it__).entry = mas_find(&(it__).mas, end__ - 1); \ > > > (it__).entry; (it__).entry = mas_find(&(it__).mas, end__ - 1)) > > > > I see you've added something like the above in your patch set as well. > > I'd like to point out that the index isn't the only state information > > that needs to be altered here, and in fact, this could go very wrong. > > > > The maple state has a node and an offset within that node. If you set > > the index to lower than the current position of your iterator and call > > mas_find() then what happens is somewhat undefined. I expect you will > > get the wrong value (most likely either the current value or the very > > next one that the iterator is already pointing to). I believe you have > > been using a fresh maple state for each iterator in your patches, but I > > haven't had a deep look into your code yet. > > Yes, I'm aware that I'd need to reset the whole iterator in order to re-use > it. Okay, good. The way you have it written makes it unsafe to just call without knowledge of the state and that will probably end poorly over the long run. If it's always starting from MAS_START then it's probably safer to just initialize when you want to use it to the correct start address. > > Regarding the other considerations of the iterator design please see my > answer to Matthew. > > > > > We have methods of resetting the iterator and set the range (mas_set() > > and mas_set_range()) which are safe for what you are doing, but they > > will start the walk from the root node to the index again. > > > > So, if you know what you are doing is safe, then the way you have > > written it will work, but it's worth mentioning that this could occur. > > > > It is also worth pointing out that it would be much safer to use a > > function to do the above so you get type safety.. and I was asked to add > > this to the VMA interface by Linus [1], which is on its way upstream [2]. > > > > 1. https://lore.kernel.org/linux-mm/CAHk-=wg9WQXBGkNdKD2bqocnN73rDswuWsavBB7T-tekykEn_A@mail.gmail.com/ > > 2. https://lore.kernel.org/linux-mm/20230120162650.984577-1-Liam.Howlett@oracle.com/ > > You mean having wrappers like sample_find() instead of directly using > mas_find()? I'm not sure you need to go that low level, but I would ensure I have a store/load function that ensures the correct type being put in/read from are correct on compile - especially since you seem to have two trees to track two different sets of things. That iterator is probably safe since the type is defined within itself. > > > > > > > > > Signed-off-by: Danilo Krummrich <dakr@redhat.com> > > > --- > > > include/linux/maple_tree.h | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/include/linux/maple_tree.h b/include/linux/maple_tree.h > > > index e594db58a0f1..ca04c900e51a 100644 > > > --- a/include/linux/maple_tree.h > > > +++ b/include/linux/maple_tree.h > > > @@ -424,8 +424,8 @@ struct ma_wr_state { > > > #define MA_ERROR(err) \ > > > ((struct maple_enode *)(((unsigned long)err << 2) | 2UL)) > > > -#define MA_STATE(name, mt, first, end) \ > > > - struct ma_state name = { \ > > > +#define __MA_STATE(mt, first, end) \ > > > + { \ > > > .tree = mt, \ > > > .index = first, \ > > > .last = end, \ > > > @@ -435,6 +435,9 @@ struct ma_wr_state { > > > .alloc = NULL, \ > > > } > > > +#define MA_STATE(name, mt, first, end) \ > > > + struct ma_state name = __MA_STATE(mt, first, end) > > > + > > > #define MA_WR_STATE(name, ma_state, wr_entry) \ > > > struct ma_wr_state name = { \ > > > .mas = ma_state, \ > > > -- > > > 2.39.1 > > > > > >
diff --git a/include/linux/maple_tree.h b/include/linux/maple_tree.h index e594db58a0f1..ca04c900e51a 100644 --- a/include/linux/maple_tree.h +++ b/include/linux/maple_tree.h @@ -424,8 +424,8 @@ struct ma_wr_state { #define MA_ERROR(err) \ ((struct maple_enode *)(((unsigned long)err << 2) | 2UL)) -#define MA_STATE(name, mt, first, end) \ - struct ma_state name = { \ +#define __MA_STATE(mt, first, end) \ + { \ .tree = mt, \ .index = first, \ .last = end, \ @@ -435,6 +435,9 @@ struct ma_wr_state { .alloc = NULL, \ } +#define MA_STATE(name, mt, first, end) \ + struct ma_state name = __MA_STATE(mt, first, end) + #define MA_WR_STATE(name, ma_state, wr_entry) \ struct ma_wr_state name = { \ .mas = ma_state, \