diff options
author | 2025-05-21 17:33:36 +0800 | |
---|---|---|
committer | 2025-05-26 17:38:27 +0200 | |
commit | 0a9b2c9fd1688c7ecbff0702855577a3f8eef1df (patch) | |
tree | 5b1752fbf1546169d266098d652dd98f31c5e598 /scripts/gdb/linux/vmalloc.py | |
parent | Merge branch 'add-the-capability-to-consume-sram-for-hwfd-descriptor-queue-in-airoha_eth-driver' (diff) | |
download | wireguard-linux-0a9b2c9fd1688c7ecbff0702855577a3f8eef1df.tar.xz wireguard-linux-0a9b2c9fd1688c7ecbff0702855577a3f8eef1df.zip |
net: mctp: use nlmsg_payload() for netlink message data extraction
Jakub suggests:
> I have a different request :) Matt, once this ends up in net-next
> (end of this week) could you refactor it to use nlmsg_payload() ?
> It doesn't exist in net but this is exactly why it was added.
This refactors the additions to both mctp_dump_addrinfo(), and
mctp_rtm_getneigh() - two cases where we're calling nlh_data() on an
an incoming netlink message, without a prior nlmsg_parse().
For the neigh.c case, we cannot hit the failure where the nlh does not
contain a full ndmsg at present, as the core handler
(net/core/neighbour.c, neigh_get()) has already validated the size
through neigh_valid_req_get(), and would have failed the get operation
before the MCTP hander is called.
However, relying on that is a bit fragile, so apply the nlmsg_payload
refector here too.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20250521-mctp-nlmsg-payload-v2-1-e85df160c405@codeconstruct.com.au
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'scripts/gdb/linux/vmalloc.py')
0 files changed, 0 insertions, 0 deletions