On 4/18/2019 6:19 PM, Herakliusz Lipiec wrote:
> A sucessfull call to rte_mp_request_sync does not guarantee that there
> are valid messages in the buffer, and this should be checked for before
> accessing data in the message.
>
> Fixes: c9aa56edec8e ("net/tap: access primary process queues from secondary")
> Cc: rasl...@mellanox.com
> Cc: sta...@dpdk.org
> Signed-off-by: Herakliusz Lipiec <herakliusz.lip...@intel.com>
> ---
> drivers/net/tap/rte_eth_tap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index e9fda8cf6..a619a8850 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -2101,7 +2101,7 @@ tap_mp_attach_queues(const char *port_name, struct
> rte_eth_dev *dev)
> request.len_param = sizeof(*request_param);
> /* Send request and receive reply */
> ret = rte_mp_request_sync(&request, &replies, &timeout);
> - if (ret < 0) {
> + if (ret < 0 || replies.n_receieved != 1) {
The API documentation says:
|| * @return
|| * - On success, return 0.
|| * - On failure, return -1, and the reason will be stored in rte_errno.
So if the API returns 0, why the reply is not valid, also if reply is not valid
how can you rely on a value in 'replies'
What do you think updating the 'rte_mp_request_sync()' API to return error
whenever the reply is not valid?
