From: Patrisious Haddad <phaddad@nvidia.com>
To: Mark Bloch <mbloch@nvidia.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Arnd Bergmann <arnd@kernel.org>
Cc: Leon Romanovsky <leon@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Tariq Toukan <tariqt@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
Moshe Shemesh <moshe@nvidia.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RDMA/mlx5: hide unused code
Date: Tue, 1 Apr 2025 18:20:09 +0300 [thread overview]
Message-ID: <84bf60b7-2d7e-4549-8e81-bc35efeef069@nvidia.com> (raw)
In-Reply-To: <a754f37e-d9ea-4fba-820e-cc56204d954f@nvidia.com>
On 3/31/2025 12:30 PM, Mark Bloch wrote:
>
> On 28/03/2025 16:15, Jason Gunthorpe wrote:
>> On Fri, Mar 28, 2025 at 02:10:17PM +0100, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>
>>> After a recent rework, a few 'static const' objects have become unused:
>>>
>>> In file included from drivers/infiniband/hw/mlx5/fs.c:27:
>>> drivers/infiniband/hw/mlx5/fs.c:26:28: error: 'mlx5_ib_object_MLX5_IB_OBJECT_STEERING_ANCHOR' defined but not used [-Werror=unused-const-variable=]
>>> include/rdma/uverbs_named_ioctl.h:52:47: note: in expansion of macro 'UVERBS_OBJECT'
>>> 52 | static const struct uverbs_object_def UVERBS_OBJECT(_object_id) = { \
>>> | ^~~~~~~~~~~~~
>>> drivers/infiniband/hw/mlx5/fs.c:3457:1: note: in expansion of macro 'DECLARE_UVERBS_NAMED_OBJECT'
>>> 3457 | DECLARE_UVERBS_NAMED_OBJECT(
>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> drivers/infiniband/hw/mlx5/fs.c:26:28: error: 'mlx5_ib_object_MLX5_IB_OBJECT_FLOW_MATCHER' defined but not used [-Werror=unused-const-variable=]
>>> include/rdma/uverbs_named_ioctl.h:52:47: note: in expansion of macro 'UVERBS_OBJECT'
>>> 52 | static const struct uverbs_object_def UVERBS_OBJECT(_object_id) = { \
>>> | ^~~~~~~~~~~~~
>>> drivers/infiniband/hw/mlx5/fs.c:3429:1: note: in expansion of macro 'DECLARE_UVERBS_NAMED_OBJECT'
>>> 3429 | DECLARE_UVERBS_NAMED_OBJECT(MLX5_IB_OBJECT_FLOW_MATCHER,
>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> These come from a complex set of macros, and it would be possible to
>>> shut up the warnings here by adding __maybe_unused annotations inside
>>> of the macros, it seems cleaner in this case to have a large #ifdef block
>>> around all the unused parts of the file, in order to still be able to
>>> catch unused ones elsewhere.
>> IDK, I'm tempted to revert 36e0d433672f ("RDMA/mlx5: Compile fs.c
>> regardless of INFINIBAND_USER_ACCESS config")
> I believe the issue arises because uverbs_destroy_def_handler() is
> declared in ib_verbs.h, but if uverbs isn't built, there is no
> corresponding implementation of this function.
>
> One possible solution is to provide an empty implementation when USER_ACCESS
> is not set, similar to how rdma_user_mmap_disassociate() is handled.
>
> Alternatively, since uverbs_destroy_def_handler() currently does nothing
> (always returning 0), we could simply define it as a static inline
> function inside ib_verbs.h and resolve the issue that way.
>
> An example of the first approach would be:
>
> diff --git a/drivers/infiniband/hw/mlx5/fs.c b/drivers/infiniband/hw/mlx5/fs.c
> index 251246c73b33..0ff9f18a71e8 100644
> --- a/drivers/infiniband/hw/mlx5/fs.c
> +++ b/drivers/infiniband/hw/mlx5/fs.c
> @@ -3461,7 +3461,6 @@ DECLARE_UVERBS_NAMED_OBJECT(
> &UVERBS_METHOD(MLX5_IB_METHOD_STEERING_ANCHOR_DESTROY));
>
> const struct uapi_definition mlx5_ib_flow_defs[] = {
> -#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
> UAPI_DEF_CHAIN_OBJ_TREE_NAMED(
> MLX5_IB_OBJECT_FLOW_MATCHER),
> UAPI_DEF_CHAIN_OBJ_TREE(
> @@ -3472,7 +3471,6 @@ const struct uapi_definition mlx5_ib_flow_defs[] = {
> UAPI_DEF_CHAIN_OBJ_TREE_NAMED(
> MLX5_IB_OBJECT_STEERING_ANCHOR,
> UAPI_DEF_IS_OBJ_SUPPORTED(mlx5_ib_shared_ft_allowed)),
> -#endif
> {},
> };
>
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index d42eae69d9a8..901353796fbb 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -4790,7 +4790,14 @@ void roce_del_all_netdev_gids(struct ib_device *ib_dev,
>
> struct ib_ucontext *ib_uverbs_get_ucontext_file(struct ib_uverbs_file *ufile);
>
> +#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
> int uverbs_destroy_def_handler(struct uverbs_attr_bundle *attrs);
> +#else
> +static inline int uverbs_destroy_def_handler(struct uverbs_attr_bundle *attrs)
> +{
> + return 0;
> +}
> +#endif
>
> struct net_device *rdma_alloc_netdev(struct ib_device *device, u32 port_num,
> enum rdma_netdev_t type, const char *name,
>
>> I don't think that was so well thought out. The entire file was
>> designed to be USER_ACCESS only because it uses all this mechanism.
But not really the entire file , as you said below half of it is
actually UVERBS , but it has the other half is unrelated to uverbs and
its compilation shouldnt be dependent on it (that half is used by
iproute2 mainly), which is the reason for this change.
(Also separation into two files, IMO isn't really the best way to
resolve it, since in the end they are both still flow steering code
which leaves us with mark solution unless there is objections to it I
was planning to send it next week).
>>
>> #ifdefing away half the file seems ugly.
agreed, which is why I think mark bloch suggestion makes more sense, do
you think it is okay ? or you think there is issues with it ?
>>
>> Jason
next prev parent reply other threads:[~2025-04-01 15:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 13:10 [PATCH] RDMA/mlx5: hide unused code Arnd Bergmann
2025-03-28 13:15 ` Jason Gunthorpe
2025-03-28 13:20 ` Arnd Bergmann
2025-03-31 9:30 ` Mark Bloch
2025-04-01 15:20 ` Patrisious Haddad [this message]
2025-04-01 15:36 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84bf60b7-2d7e-4549-8e81-bc35efeef069@nvidia.com \
--to=phaddad@nvidia.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=jgg@ziepe.ca \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=moshe@nvidia.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox