summaryrefslogtreecommitdiff
path: root/net/ceph/decode.c
AgeCommit message (Collapse)Author
2026-08-12libceph: tolerate addrvecs with multiple entries of the same typeKefu Chai
ceph_decode_entity_addrvec() rejects any addrvec containing more than one entry that matches the requested msgr type (LEGACY or MSGR2), logging "another match of type N in addrvec" and returning -EINVAL. Some admin tooling (e.g. pveceph mon create from Proxmox VE) generates addrvecs with multiple same-type entries when public_network lists more than one CIDR: it picks one local IP per subnet and emits both a v2 and a v1 entry for each IP. Monmaps shaped this way cause: libceph: mon0 (1)10.10.10.15:6789 session established libceph: another match of type 1 in addrvec libceph: problem decoding monmap, -22 No Ceph code uses the extra entries: since Nautilus, the userspace messenger (AsyncMessenger) unconditionally picks the first address of the requested type and ignores any subsequent matches. Match that behavior: use the first matching entry and silently skip any subsequent ones. This is a compatibility fix for existing deployments and does not enable dual-stack or multi-subnet address selection. [ idryomov: tweak ceph_decode_entity_addrvec() comment ] Cc: stable@vger.kernel.org Fixes: a5cbd5fc22d5 ("libceph, ceph: get and handle cluster maps with addrvecs") Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7518 Signed-off-by: Kefu Chai <k.chai@proxmox.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2021-05-04libceph: allow addrvecs with a single NONE/blank addressIlya Dryomov
Normally, an unused OSD id/slot is represented by an empty addrvec. However, it also appears to be possible to generate an osdmap where an unused OSD id/slot has an addrvec with a single blank address of type NONE. Allow such addrvecs and make the end result be exactly the same as for the empty addrvec case -- leave addr intact. Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Jeff Layton <jlayton@kernel.org>
2020-12-14libceph, ceph: implement msgr2.1 protocol (crc and secure modes)Ilya Dryomov
Implement msgr2.1 wire protocol, available since nautilus 14.2.11 and octopus 15.2.5. msgr2.0 wire protocol is not implemented -- it has several security, integrity and robustness issues and therefore considered deprecated. Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2020-12-14libceph, ceph: get and handle cluster maps with addrvecsIlya Dryomov
In preparation for msgr2, make the cluster send us maps with addrvecs including both LEGACY and MSGR2 addrs instead of a single LEGACY addr. This means advertising support for SERVER_NAUTILUS and also some older features: SERVER_MIMIC, MONENC and MONNAMES. MONNAMES and MONENC are actually pre-argonaut, we just never updated ceph_monmap_decode() for them. Decoding is unconditional, see commit 23c625ce3065 ("libceph: assume argonaut on the server side"). SERVER_MIMIC doesn't bear any meaning for the kernel client. Since ceph_decode_entity_addrvec() is guarded by encoding version checks (and in msgr2 case it is guarded implicitly by the fact that server is speaking msgr2), we assume MSG_ADDR2 for it. Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-07-08libceph: use TYPE_LEGACY for entity addrs instead of TYPE_NONEJeff Layton
Going forward, we'll have different address types so let's use the addr2 TYPE_LEGACY for internal tracking rather than TYPE_NONE. Also, make ceph_pr_addr print the address type value as well. Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: "Yan, Zheng" <zyan@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-07-08libceph: add ceph_decode_entity_addrJeff Layton
Add a function for decoding an entity_addr_t. Once CEPH_FEATURE_MSG_ADDR2 is enabled, the server daemons will start encoding entity_addr_t differently. Add a new helper function that can handle either format. Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: "Yan, Zheng" <zyan@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>