sk_setup_caps() was originally called in Commit 90017accff ("sctp:
Add GSO support"), as:
"We have to refresh this in case we are xmiting to more than one
transport at a time"
This actually happens in the loop of sctp_outq_flush_transports(),
and it shouldn't be tied to gso, so move it out of gso part and
before sctp_packet_pack().
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sctp_mtu_payload() is for calculating the frag size before making
chunks from a msg. So we should only add udphdr size to overhead
when udp socks are listening, as only then sctp can handle the
incoming sctp over udp packets and outgoing sctp over udp packets
will be possible.
Note that we can't do this according to transport->encap_port, as
different transports may be set to different values, while the
chunks were made before choosing the transport, we could not be
able to meet all rfc6951#section-5.6 recommends.
v1->v2:
- Add udp_port for sctp_sock to avoid a potential race issue, it
will be used in xmit path in the next patch.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As rfc6951#section-5.4 says:
"After finding the SCTP association (which
includes checking the verification tag), the UDP source port MUST be
stored as the encapsulation port for the destination address the SCTP
packet is received from (see Section 5.1).
When a non-encapsulated SCTP packet is received by the SCTP stack,
the encapsulation of outgoing packets belonging to the same
association and the corresponding destination address MUST be
disabled."
transport encap_port should be updated by a validated incoming packet's
udp src port.
We save the udp src port in sctp_input_cb->encap_port, and then update
the transport in two places:
1. right after vtag is verified, which is required by RFC, and this
allows the existent transports to be updated by the chunks that
can only be processed on an asoc.
2. right before processing the 'init' where the transports are added,
and this allows building a sctp over udp connection by client with
the server not knowing the remote encap port.
3. when processing ootb_pkt and creating the temporary transport for
the reply pkt.
Note that sctp_input_cb->header is removed, as it's not used any more
in sctp.
v1->v2:
- Change encap_port as __be16 for sctp_input_cb.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch is to implement:
rfc6951#section-6.1: Get or Set the Remote UDP Encapsulation Port Number
with the param of the struct:
struct sctp_udpencaps {
sctp_assoc_t sue_assoc_id;
struct sockaddr_storage sue_address;
uint16_t sue_port;
};
the encap_port of sock, assoc or transport can be changed by users,
which also means it allows the different transports of the same asoc
to have different encap_port value.
v1->v2:
- no change.
v2->v3:
- fix the endian warning when setting values between encap_port and
sue_port.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
encap_port is added as per netns/sock/assoc/transport, and the
latter one's encap_port inherits the former one's by default.
The transport's encap_port value would mostly decide if one
packet should go out with udp encapsulated or not.
This patch also allows users to set netns' encap_port by sysctl.
v1->v2:
- Change to define encap_port as __be16 for sctp_sock, asoc and
transport.
v2->v3:
- No change.
v3->v4:
- Add 'encap_port' entry in ip-sysctl.rst.
v4->v5:
- Improve the description of encap_port in ip-sysctl.rst.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As it says in rfc6951#section-5.5:
"When receiving ICMP or ICMPv6 response packets, there might not be
enough bytes in the payload to identify the SCTP association that the
SCTP packet triggering the ICMP or ICMPv6 packet belongs to. If a
received ICMP or ICMPv6 packet cannot be related to a specific SCTP
association or the verification tag cannot be verified, it MUST be
discarded silently. In particular, this means that the SCTP stack
MUST NOT rely on receiving ICMP or ICMPv6 messages. Implementation
constraints could prevent processing received ICMP or ICMPv6
messages."
ICMP or ICMPv6 packets need to be handled, and this is implemented by
udp encap sock .encap_err_lookup function.
The .encap_err_lookup function is called in __udp(6)_lib_err_encap()
to confirm this path does need to be updated. For sctp, what we can
do here is check if the corresponding asoc and transport exist.
Note that icmp packet process for sctp over udp is done by udp sock
.encap_err_lookup(), and it means for now we can't do as much as
sctp_v4/6_err() does. Also we can't do the two mappings mentioned
in rfc6951#section-5.5.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch is to add the udp6 sock part in sctp_udp_sock_start/stop().
udp_conf.use_udp6_rx_checksums is set to true, as:
"The SCTP checksum MUST be computed for IPv4 and IPv6, and the UDP
checksum SHOULD be computed for IPv4 and IPv6"
says in rfc6951#section-5.3.
v1->v2:
- Add pr_err() when fails to create udp v6 sock.
- Add #if IS_ENABLED(CONFIG_IPV6) not to create v6 sock when ipv6 is
disabled.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch is to add the functions to create/release udp4 sock,
and set the sock's encap_rcv to process the incoming udp encap
sctp packets. In sctp_udp_rcv(), as we can see, all we need to
do is fix the transport header for sctp_rcv(), then it would
implement the part of rfc6951#section-5.4:
"When an encapsulated packet is received, the UDP header is removed.
Then, the generic lookup is performed, as done by an SCTP stack
whenever a packet is received, to find the association for the
received SCTP packet"
Note that these functions will be called in the last patch of
this patchset when enabling this feature.
v1->v2:
- Add pr_err() when fails to create udp v4 sock.
v2->v3:
- Add 'select NET_UDP_TUNNEL' in sctp Kconfig.
v3->v4:
- No change.
v4->v5:
- Change to set udp_port to 0 by default.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For the gso of sctp over udp packets, sctp_gso_segment() will be called in
skb_udp_tunnel_segment(), we need to set transport_header to sctp header.
As all the current HWs can't handle both crc checksum and udp checksum at
the same time, the crc checksum has to be done in sctp_gso_segment() by
removing the NETIF_F_SCTP_CRC flag from the features.
Meanwhile, if the HW can't do udp checksum, csum and csum_start has to be
set correctly, and udp checksum will be done in __skb_udp_tunnel_segment()
by calling gso_make_checksum().
Thanks to Paolo, Marcelo and Guillaume for helping with this one.
v1->v2:
- no change.
v2->v3:
- remove the he NETIF_F_SCTP_CRC flag from the features.
- set csum and csum_start in sctp_gso_make_checksum().
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For some protocol's gso, like SCTP, it's using GSO_BY_FRAGS for
gso_size. When using UDP to encapsulate its packet, it will
return error in udp6_ufo_fragment() as skb->len < gso_size,
and it will never go to the gso tunnel processing.
So we should move this check after udp gso tunnel processing,
the same as udp4_ufo_fragment() does.
v1->v2:
- no change.
v2->v3:
- not do any cleanup.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There is a chance that __udp4/6_lib_lookup() returns a udp encap
sock in __udp_lib_err(), like the udp encap listening sock may
use the same port as remote encap port, in which case it should
go to __udp4/6_lib_err_encap() for more validation before
processing the icmp packet.
This patch is to check encap_type in __udp_lib_err() for the
further validation for a encap sock.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
DSA assumes that a bridge which has vlan filtering disabled is not
vlan aware, and ignores all vlan configuration. However, the kernel
software bridge code allows configuration in this state.
This causes the kernel's idea of the bridge vlan state and the
hardware state to disagree, so "bridge vlan show" indicates a correct
configuration but the hardware lacks all configuration. Even worse,
enabling vlan filtering on a DSA bridge immediately blocks all traffic
which, given the output of "bridge vlan show", is very confusing.
Allow the VLAN configuration to be updated on Marvell DSA bridges,
otherwise we end up cutting all traffic when enabling vlan filtering.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/E1kYAU3-00071C-1G@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
make clang-analyzer on x86_64 defconfig caught my attention with:
net/sched/cls_api.c:2964:3: warning: Value stored to 'parent' is never read
[clang-analyzer-deadcode.DeadStores]
parent = 0;
^
net/sched/cls_api.c:2977:4: warning: Value stored to 'parent' is never read
[clang-analyzer-deadcode.DeadStores]
parent = q->handle;
^
Commit 32a4f5ecd7 ("net: sched: introduce chain object to uapi")
introduced tc_dump_chain() and this initial implementation already
contained these unneeded dead stores.
Simplify the code to make clang-analyzer happy.
As compilers will detect these unneeded assignments and optimize this
anyway, the resulting binary is identical before and after this change.
No functional change. No change in object code.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20201028113533.26160-1-lukas.bulwahn@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 931ca7ab7f ("ip*_mc_gsfget(): lift copyout of struct group_filter
into callers") adjusted the type annotations for ip6_mc_msfget() at its
declaration, but missed the type annotations at its definition.
Hence, sparse complains on ./net/ipv6/mcast.c:
mcast.c:550:5: error: symbol 'ip6_mc_msfget' redeclared with different type \
(incompatible argument 3 (different address spaces))
Make ip6_mc_msfget() annotations consistent, which also resolves this
warning from sparse:
mcast.c:607:34: warning: incorrect type in argument 1 (different address spaces)
mcast.c:607:34: expected void [noderef] __user *to
mcast.c:607:34: got struct __kernel_sockaddr_storage *p
No functional change. No change in object code.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20201028115349.6855-1-lukas.bulwahn@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/ipv6/calipso.c:1236: warning: Excess function parameter 'reg' description in 'calipso_req_delattr'
net/ipv6/calipso.c:1236: warning: Function parameter or member 'req' not described in 'calipso_req_delattr'
net/ipv6/calipso.c:435: warning: Excess function parameter 'audit_secid' description in 'calipso_doi_remove'
net/ipv6/calipso.c:435: warning: Function parameter or member 'audit_info' not described in 'calipso_doi_remove'
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028013344.931928-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/ipv6/rpl_iptunnel.c:15: warning: cannot understand function prototype: 'struct rpl_iptunnel_encap '
The header on the file containing the author copyright message uses
kerneldoc /** opener. This confuses the parser when it gets to
struct rpl_iptunnel_encap {
struct ipv6_rpl_sr_hdr srh[0];
};
Similarly:
net//ipv6/rpl.c:10: warning: Function parameter or member 'x' not described in 'IPV6_PFXTAIL_LEN'
where IPV6_PFXTAIL_LEN is a macro definition, not a function.
Convert the header comments to a plain /* comment.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028013123.931816-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net//ipv4/tcp_lp.c:120: warning: Function parameter or member 'sk' not described in 'tcp_lp_cong_avoid'
net//ipv4/tcp_lp.c:135: warning: Function parameter or member 'sk' not described in 'tcp_lp_remote_hz_estimator'
net//ipv4/tcp_lp.c:188: warning: Function parameter or member 'sk' not described in 'tcp_lp_owd_calculator'
net//ipv4/tcp_lp.c:222: warning: Function parameter or member 'rtt' not described in 'tcp_lp_rtt_sample'
net//ipv4/tcp_lp.c:222: warning: Function parameter or member 'sk' not described in 'tcp_lp_rtt_sample'
net//ipv4/tcp_lp.c:265: warning: Function parameter or member 'sk' not described in 'tcp_lp_pkts_acked'
net//ipv4/tcp_lp.c:97: warning: Function parameter or member 'sk' not described in 'tcp_lp_init'
There are still a few kerneldoc warnings after this fix.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028012703.931632-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/dccp/ccids/ccid2.c:190: warning: Function parameter or member 'hc' not described in 'ccid2_update_used_window'
net/dccp/ccids/ccid2.c:190: warning: Function parameter or member 'new_wnd' not described in 'ccid2_update_used_window'
net/dccp/ccids/ccid2.c:360: warning: Function parameter or member 'sk' not described in 'ccid2_rtt_estimator'
net/dccp/ccids/ccid3.c:112: warning: Function parameter or member 'sk' not described in 'ccid3_hc_tx_update_x'
net/dccp/ccids/ccid3.c:159: warning: Function parameter or member 'hc' not described in 'ccid3_hc_tx_update_s'
net/dccp/ccids/ccid3.c:268: warning: Function parameter or member 'sk' not described in 'ccid3_hc_tx_send_packet'
net/dccp/ccids/ccid3.c:667: warning: Function parameter or member 'sk' not described in 'ccid3_first_li'
net/dccp/ccids/ccid3.c:85: warning: Function parameter or member 'hc' not described in 'ccid3_update_send_interval'
net/dccp/ccids/lib/loss_interval.c:85: warning: Function parameter or member 'lh' not described in 'tfrc_lh_update_i_mean'
net/dccp/ccids/lib/loss_interval.c:85: warning: Function parameter or member 'skb' not described in 'tfrc_lh_update_i_mean'
net/dccp/ccids/lib/packet_history.c:392: warning: Function parameter or member 'h' not described in 'tfrc_rx_hist_sample_rtt'
net/dccp/ccids/lib/packet_history.c:392: warning: Function parameter or member 'skb' not described in 'tfrc_rx_hist_sample_rtt'
net/dccp/feat.c:1003: warning: Function parameter or member 'dreq' not described in 'dccp_feat_server_ccid_dependencies'
net/dccp/feat.c:1040: warning: Function parameter or member 'array_len' not described in 'dccp_feat_prefer'
net/dccp/feat.c:1040: warning: Function parameter or member 'array' not described in 'dccp_feat_prefer'
net/dccp/feat.c:1040: warning: Function parameter or member 'preferred_value' not described in 'dccp_feat_prefer'
net/dccp/output.c:151: warning: Function parameter or member 'dp' not described in 'dccp_determine_ccmps'
net/dccp/output.c:242: warning: Function parameter or member 'sk' not described in 'dccp_xmit_packet'
net/dccp/output.c:305: warning: Function parameter or member 'sk' not described in 'dccp_flush_write_queue'
net/dccp/output.c:305: warning: Function parameter or member 'time_budget' not described in 'dccp_flush_write_queue'
net/dccp/output.c:378: warning: Function parameter or member 'sk' not described in 'dccp_retransmit_skb'
net/dccp/qpolicy.c:88: warning: Function parameter or member '' not described in 'dccp_qpolicy_operations'
net/dccp/qpolicy.c:88: warning: Function parameter or member '{' not described in 'dccp_qpolicy_operations'
net/dccp/qpolicy.c:88: warning: Function parameter or member 'params' not described in 'dccp_qpolicy_operations'
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028011412.931250-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net//dcb/dcbnl.c:1836: warning: Function parameter or member 'app' not described in 'dcb_getapp'
net//dcb/dcbnl.c:1836: warning: Function parameter or member 'dev' not described in 'dcb_getapp'
net//dcb/dcbnl.c:1858: warning: Function parameter or member 'dev' not described in 'dcb_setapp'
net//dcb/dcbnl.c:1858: warning: Function parameter or member 'new' not described in 'dcb_setapp'
net//dcb/dcbnl.c:1899: warning: Function parameter or member 'app' not described in 'dcb_ieee_getapp_mask'
net//dcb/dcbnl.c:1899: warning: Function parameter or member 'dev' not described in 'dcb_ieee_getapp_mask'
net//dcb/dcbnl.c:1922: warning: Function parameter or member 'dev' not described in 'dcb_ieee_setapp'
net//dcb/dcbnl.c:1922: warning: Function parameter or member 'new' not described in 'dcb_ieee_setapp'
net//dcb/dcbnl.c:1953: warning: Function parameter or member 'del' not described in 'dcb_ieee_delapp'
net//dcb/dcbnl.c:1953: warning: Function parameter or member 'dev' not described in 'dcb_ieee_delapp'
net//dcb/dcbnl.c:1986: warning: Function parameter or member 'dev' not described in 'dcb_ieee_getapp_prio_dscp_mask_map'
net//dcb/dcbnl.c:1986: warning: Function parameter or member 'p_map' not described in 'dcb_ieee_getapp_prio_dscp_mask_map'
net//dcb/dcbnl.c:2016: warning: Function parameter or member 'dev' not described in 'dcb_ieee_getapp_dscp_prio_mask_map'
net//dcb/dcbnl.c:2016: warning: Function parameter or member 'p_map' not described in 'dcb_ieee_getapp_dscp_prio_mask_map'
net//dcb/dcbnl.c:2045: warning: Function parameter or member 'dev' not described in 'dcb_ieee_getapp_default_prio_mask'
For some of these warnings, change to comments to plain comments,
since no attempt is being made to follow kerneldoc syntax.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028010913.930929-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net//nfc/core.c:1046: warning: Function parameter or member 'tx_headroom' not described in 'nfc_allocate_device'
net//nfc/core.c:1046: warning: Function parameter or member 'tx_tailroom' not described in 'nfc_allocate_device'
net//nfc/core.c:198: warning: Excess function parameter 'protocols' description in 'nfc_start_poll'
net//nfc/core.c:198: warning: Function parameter or member 'im_protocols' not described in 'nfc_start_poll'
net//nfc/core.c:198: warning: Function parameter or member 'tm_protocols' not described in 'nfc_start_poll'
net//nfc/core.c:441: warning: Function parameter or member 'mode' not described in 'nfc_deactivate_target'
net//nfc/core.c:711: warning: Function parameter or member 'dev' not described in 'nfc_alloc_send_skb'
net//nfc/core.c:711: warning: Function parameter or member 'err' not described in 'nfc_alloc_send_skb'
net//nfc/core.c:711: warning: Function parameter or member 'flags' not described in 'nfc_alloc_send_skb'
net//nfc/core.c:711: warning: Function parameter or member 'sk' not described in 'nfc_alloc_send_skb'
net//nfc/digital_core.c:470: warning: Function parameter or member 'im_protocols' not described in 'digital_start_poll'
net//nfc/digital_core.c:470: warning: Function parameter or member 'nfc_dev' not described in 'digital_start_poll'
net//nfc/digital_core.c:470: warning: Function parameter or member 'tm_protocols' not described in 'digital_start_poll'
net//nfc/nci/core.c:1119: warning: Function parameter or member 'tx_headroom' not described in 'nci_allocate_device'
net//nfc/nci/core.c:1119: warning: Function parameter or member 'tx_tailroom' not described in 'nci_allocate_device'
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028005653.930467-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/appletalk/aarp.c:68: warning: Function parameter or member 'dev' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'expires_at' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'hwaddr' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'last_sent' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'next' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'packet_queue' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'status' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'target_addr' not described in 'aarp_entry'
net/appletalk/aarp.c:68: warning: Function parameter or member 'xmit_count' not described in 'aarp_entry'
net/appletalk/ddp.c:1422: warning: Function parameter or member 'dev' not described in 'atalk_rcv'
net/appletalk/ddp.c:1422: warning: Function parameter or member 'orig_dev' not described in 'atalk_rcv'
net/appletalk/ddp.c:1422: warning: Function parameter or member 'pt' not described in 'atalk_rcv'
net/appletalk/ddp.c:1422: warning: Function parameter or member 'skb' not described in 'atalk_rcv'
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028005527.930388-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/openvswitch/flow.c:303: warning: Function parameter or member 'key_vh' not described in 'parse_vlan_tag'
net/openvswitch/flow.c:303: warning: Function parameter or member 'skb' not described in 'parse_vlan_tag'
net/openvswitch/flow.c:303: warning: Function parameter or member 'untag_vlan' not described in 'parse_vlan_tag'
net/openvswitch/vport.c:122: warning: Function parameter or member 'parms' not described in 'ovs_vport_alloc'
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028004849.930094-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Andrew Lunn says:
====================
Markup some printk like functions
W=1 warns of functions which look like printk but don't have
attributes so the compile can check that arguments matches the format
string.
====================
Link: https://lore.kernel.org/r/20201028003849.929490-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/tipc/netlink_compat.c: In function ‘tipc_tlv_sprintf’:
net/tipc/netlink_compat.c:137:2: warning: function ‘tipc_tlv_sprintf’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
137 | n = vscnprintf(buf, rem, fmt, args);
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/dccp/ccid.c: In function ‘ccid_kmem_cache_create’:
net/dccp/ccid.c:85:2: warning: function ‘ccid_kmem_cache_create’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
85 | vsnprintf(slab_name_fmt, CCID_SLAB_NAME_LENGTH, fmt, args);
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that the compiler is performing printf checking, we get the warning:
net/tipc/netlink_compat.c: In function ‘tipc_nl_compat_link_stat_dump’:
net/tipc/netlink_compat.c:591:39: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘void *’ [-Wformat=]
591 | tipc_tlv_sprintf(msg->rep, "\nLink <%s>\n",
| ~^
| |
| char *
| %p
592 | nla_data(link[TIPC_NLA_LINK_NAME]));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void *
There is no nla_string(), so cast to a char *.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201028004333.929816-1-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nikolay Aleksandrov says:
====================
selftests: net: bridge: add tests for IGMPv3
This set adds tests for the bridge's new IGMPv3 support. The tests use
precooked packets which are sent via mausezahn and the resulting state
after each test is checked for proper X,Y sets, (*,G) source list, source
list entry timers, (S,G) existence and flags, packet forwarding and
blocking, exclude group expiration and (*,G) auto-add. The first 3 patches
prepare the existing IGMPv2 tests, then patch 4 adds new helpers which are
used throughout the rest of the v3 tests.
The following new tests are added:
- base case: IGMPv3 report 239.10.10.10 is_include (A)
- include -> allow report
- include -> is_include report
- include -> is_exclude report
- include -> to_exclude report
- exclude -> allow report
- exclude -> is_include report
- exclude -> is_exclude report
- exclude -> to_exclude report
- include -> block report
- exclude -> block report
- exclude timeout (move to include + entry deletion)
- S,G port entry automatic add to a *,G,exclude port
The variable names and set notation are the same as per RFC 3376,
for more information check RFC 3376 sections 4.2.15 and 6.4.1.
MLDv2 tests will be added by a separate patch-set.
====================
Link: https://lore.kernel.org/r/20201027185934.227040-1-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When we have *,G ports in exclude mode and a new S,G,port is added
the kernel has to automatically create an S,G entry for each exclude
port to get proper forwarding.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test that when a group in exclude mode expires it changes mode to
include and the blocked entries are deleted.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y)=Group Timer
Send Q(G,A-Y)
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(G,A*B)
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=GMI
Delete (X-A)
Delete (Y-A)
Group Timer=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Send Q(G,A*B)
Group Timer=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Group Timer=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
state report result action
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
First we test is_include/include mode then we build on that with allow
effectively achieving:
state report result action
INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=GMI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add helpers which will be used in subsequent tests, they are:
- check_sg_entries: check for proper source list and S,G entry
existence
- check_sg_fwding: check for proper traffic forwarding/blocking
- check_sg_state: check for proper blocked/forwarding entry state
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We have to specifically check for udp protocol in addition to the mac
address because in IGMPv3 tests group-specific queries will use the same
mac address.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add support for one more argument which specifies the source address to
use. It will be later used for IGMPv3 S,G entry testing.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
To prepare the bridge_igmp.sh for IGMPv3 we need to rename the
current test to IGMPv2.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
