Geert Uytterhoeven geert@linux-m68k.org 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