Geert Uytterhoeven <[email protected]> wrote:
> While this is not a real false-positive, I believe it cannot cause harm
> in practice, as AF_RXRPC cannot be used with other transport families
> than IPv4 and IPv6.
Agreed.
> ---
> net/rxrpc/output.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c
> index 004c762c2e8d063c..1473d774d67100c5 100644
> --- a/net/rxrpc/output.c
> +++ b/net/rxrpc/output.c
> @@ -403,8 +403,10 @@ int rxrpc_send_data_packet(struct rxrpc_call *call,
> struct sk_buff *skb,
>
> /* send the packet with the don't fragment bit set if we currently
> * think it's small enough */
> - if (iov[1].iov_len >= call->peer->maxdata)
> + if (iov[1].iov_len >= call->peer->maxdata) {
> + ret = 0;
> goto send_fragmentable;
> + }
>
> down_read(&conn->params.local->defrag_sem);
>
Simply setting 0 is wrong. That would give the impression that the thing
worked if support for a new transport address family was added and came
through this function without full modification (say AF_INET7 becomes a
thing).
A better way to do things would be to add a default case into the
send_fragmentable switch statement that either BUG's or sets -EAFNOSUPPORT.
David
