From: Leon Romanovsky <leon@kernel.org>
To: "Håkon Bugge" <haakon.bugge@oracle.com>
Cc: Doug Ledford <dledford@redhat.com>,
Jason Gunthorpe <jgg@mellanox.com>,
linux-rdma@vger.kernel.org,
Mark Haywood <mark.haywood@oracle.com>
Subject: Re: [PATCH RDMA/netlink] RDMA/netlink: Adhere to returning zero on success
Date: Wed, 11 Dec 2019 14:39:55 +0200 [thread overview]
Message-ID: <20191211123955.GS67461@unreal> (raw)
In-Reply-To: <20191211103400.2949140-1-haakon.bugge@oracle.com>
On Wed, Dec 11, 2019 at 11:34:00AM +0100, Håkon Bugge wrote:
> In rdma_nl_rcv_skb(), the local variable err is assigned the return
> value of the supplied callback function, which could be one of
> ib_nl_handle_resolve_resp(), ib_nl_handle_set_timeout(), or
> ib_nl_handle_ip_res_resp(). These three functions all return skb->len
> on success.
>
> rdma_nl_rcv_skb() is merely a copy of netlink_rcv_skb(). The callback
> functions used by the latter have the convention: "Returns 0 on
> success or a negative error code".
>
> In particular, the statement (equal for both functions):
>
> if (nlh->nlmsg_flags & NLM_F_ACK || err)
>
> implies that rdma_nl_rcv_skb() always will ack a message, independent
> of the NLM_F_ACK being set in nlmsg_flags or not.
The more accurate description is that rdma_nl_rcv_skb() always generates
NLMSG_ERROR without relation to NLM_F_ACK flag. The NLM_F_ACK flag is
requested to get acknowledges for the success.
>
> The fix could be to change the above statement, but it is better to
> keep the two *_rcv_skb() functions equal in this respect and instead
> change the callback functions in the rdma subsystem to the correct
> convention.
AFAIR, RTNETLINK has the same implementation as RDMA netlink.
Thanks
next prev parent reply other threads:[~2019-12-11 12:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 10:34 [PATCH RDMA/netlink] RDMA/netlink: Adhere to returning zero on success Håkon Bugge
2019-12-11 10:42 ` Håkon Bugge
2019-12-11 12:39 ` Leon Romanovsky [this message]
2019-12-11 13:13 ` Håkon Bugge
2019-12-11 19:31 ` Håkon Bugge
2019-12-12 11:40 ` Leon Romanovsky
[not found] ` <AD5EE341-4238-439A-A078-299F00C61B85@oracle.com>
[not found] ` <20191212121020.GZ67461@unreal>
[not found] ` <CB8FC366-9983-417D-8280-DD1EB0DCB778@oracle.com>
2019-12-12 12:22 ` Håkon Bugge
[not found] ` <20191212122719.GA67461@unreal>
2019-12-12 12:37 ` Håkon Bugge
2019-12-12 14:14 ` Mark Haywood
2019-12-13 16:51 ` Mark Haywood
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=20191211123955.GS67461@unreal \
--to=leon@kernel.org \
--cc=dledford@redhat.com \
--cc=haakon.bugge@oracle.com \
--cc=jgg@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=mark.haywood@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.