From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DCA73C2785 for ; Thu, 4 Jun 2026 19:28:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780601311; cv=none; b=uz6dF9jDABayPF/ZIuEHw2A+5L+YWqNVO3oK1qr8PD8cS9xnAkrZ14pmP2egaHUxTComMPplB2aIjtBkL8DBlNJy35/MSAGumBsYPRYqRKNn2/AfKZ5u4/qdrjeTuW3mSYvgr00Bv/mDbNc49aSB8ymSoin9JO7iDA803TykTb4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780601311; c=relaxed/simple; bh=TItzyWNZgOo/nbUaA7wdNW1r8/Z3HDCGHgSAfgA67pQ=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=a7x22NCbh+Yjn25uOxndGvFQdaGlGIQVkbo0W9ajZ/tHe4OPCSgjnL1pYkkSarIL//Rmz9TVNL3mVl1VpdQdz1JpHItO922ufM9UPPfLZhv7GJgBK/8GhHlcuqMhQf6d6uWMiOQW+y8TIU9+sBjXw+8rmGJJsLkkZeo3mjbqvHM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dubeyko.com; spf=pass smtp.mailfrom=dubeyko.com; dkim=pass (2048-bit key) header.d=dubeyko-com.20251104.gappssmtp.com header.i=@dubeyko-com.20251104.gappssmtp.com header.b=lhYnHcYp; arc=none smtp.client-ip=209.85.128.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dubeyko.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=dubeyko.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=dubeyko-com.20251104.gappssmtp.com header.i=@dubeyko-com.20251104.gappssmtp.com header.b="lhYnHcYp" Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-7dc73a56b5aso8819107b3.1 for ; Thu, 04 Jun 2026 12:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20251104.gappssmtp.com; s=20251104; t=1780601309; x=1781206109; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=KCjs80ykOUdYOov1ibREWQaylg8Gs47dTBWxVYP5wQU=; b=lhYnHcYpgcKwjQnM83iuacqgYSTN5axg/MTf2OxyHu1eYm7GtFEWYpLBf2Zjw8qF6R RjWn3ZWdzrjD6DKylKXFtPsQN/DEJ0Xhi0i4nPMgi9zN9VagDe/z9i578FrXFPcxq+/x mENTQ2hOkz4JZDygJk4srfpz7tRrvQEoI7Kpr4MfVI25PjDvXKar0Kyc1KzpMWVAU6q+ 7yvSLK00taCqEjNt01uEQAxyvTCBlPFERJQvF8BUG7yxqy2hQTZzORD/ryvDP4G1e3mY X2h0ZrUNNdT9VxQyG2dimHwFy4mI43Al5fNV5C0tFUy7+XazgFpkp821kC6cAaU+KFnC 3lLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780601309; x=1781206109; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KCjs80ykOUdYOov1ibREWQaylg8Gs47dTBWxVYP5wQU=; b=caQCJeXt1T1T+hMSo4OseBuKs6hdeZlyAuj31joZgfoaWJE6USFnKsdwmy45Tsr+DD 9O84H9qXYBUtHte7c++A8Q8NtjxAnFQuNCqJKktkTvj9+ct46rEPoHG8My6p1w3VG1IW IX3ccmDy8xYjW4wjD8xm5ZoFNg4teNVTO0JOLMVwbUlFDle2yz+pPnhy3TVFDkiLFMq0 yyUi4ShPTPus2H3eqqRbB4R29qwPiUPqoZAf/fkXswcOTer349u5Cg6za6VDB2VE1Jqn pvfU8f8CD+M4E/62HkwTElzsp7nc7+z7tl3isfksoXRJ525R2txB7RAzzJMDJG+PZ8vd IgNw== X-Forwarded-Encrypted: i=1; AFNElJ+853SPJ2SjivoduNiGLQshtwJ7wc9gHhzcFEe7iIRuLpCWqxIsCt7ib6S7+ViYfrqREo6ihZlZiEORxAo=@vger.kernel.org X-Gm-Message-State: AOJu0Yx67V4XVKM2QU+pI9cxLBJp2u7w1lrJo/dtHMaIuhS6agymSIpW 3GGFIDFBGUP1tOXgmYAHEDtt4NDG8rQIu6IXn8OzwOKJ8YYGwe1R5VC5rWABLZOHqac= X-Gm-Gg: Acq92OFf6A8peMdmiJjZzxzLDw9IW8snLXgoGDzg8nlm8a2uCo9i0TjisdEd+7S3gA+ Q/i0V//zMrJEvsxMFRhjSGMaWwkNwNhUja1NrVMjSh2SHJduC1ky2/Geo+NxO5OawpwPkZ6Srgq 8Jnx8pGag61Tj50UcejlM7j0Jl8NeIXB2iOimewgaXEoD3YKJ3yeWqBIQhB5qb/gN0/zznYw6QD UpOwDez4Yx2CNOiijHiMVGrAhOPIn6yD7Kpl33sRCSprLk0UEKZfRopVWs+o5ufLrRSYPPNrpf4 nRQbZmUbej4CykMMXr/k8b5BB8cMNC3OASojqe1hl8HCKuQeY0YDjBxfWHGqMPSDnlqrD/YU6h4 nSGcXL2ZaUJb1p8LeBss2E9eflWvsOQiCFloos05Z91YdAjyO5yYl6ngxbF5MvcNAJA/1HVPR79 DWaEfjjHqB7UFnTsa+6C6k5hV7WmOJyeaAeMwUvBu7pZx5Yr+dKHnlUTdjORCfwsgjeOsuoCEjt dYt8ulFYCsBk+nIbVarrLQbZvtQKzzk4M2kAblc4buJrmC1hlYil7N+Gmvlv81gpwh5t/E= X-Received: by 2002:a05:690c:4b81:b0:79a:6249:a046 with SMTP id 00721157ae682-7ed0a4f27b3mr3429587b3.9.1780601309252; Thu, 04 Jun 2026 12:28:29 -0700 (PDT) Received: from ?IPv6:2600:1700:6476:1430:ae19:b6b2:5990:ed2a? ([2600:1700:6476:1430:ae19:b6b2:5990:ed2a]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7ea20ea819esm39323027b3.10.2026.06.04.12.28.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 12:28:28 -0700 (PDT) Message-ID: <85dea67ad1983eab5b9ca7735d385f6a1e681e85.camel@dubeyko.com> Subject: Re: [PATCH v2] libceph: tolerate addrvecs with multiple entries of the same type From: Viacheslav Dubeyko To: Kefu Chai , ceph-devel@vger.kernel.org Cc: Ilya Dryomov , Alex Markuze , linux-kernel@vger.kernel.org Date: Thu, 04 Jun 2026 12:28:27 -0700 In-Reply-To: <20260604140231.2759025-1-k.chai@proxmox.com> References: <20260423100904.2336750-1-k.chai@proxmox.com> <20260604140231.2759025-1-k.chai@proxmox.com> Autocrypt: addr=slava@dubeyko.com; prefer-encrypt=mutual; keydata=mQINBGgaTLYBEADaJc/WqWTeunGetXyyGJ5Za7b23M/ozuDCWCp+yWUa2GqQKH40dxRIR zshgOmAue7t9RQJU9lxZ4ZHWbi1Hzz85+0omefEdAKFmxTO6+CYV0g/sapU0wPJws3sC2Pbda9/eJ ZcvScAX2n/PlhpTnzJKf3JkHh3nM1ACO3jzSe2/muSQJvqMLG2D71ccekr1RyUh8V+OZdrPtfkDam V6GOT6IvyE+d+55fzmo20nJKecvbyvdikWwZvjjCENsG9qOf3TcCJ9DDYwjyYe1To8b+mQM9nHcxp jUsUuH074BhISFwt99/htZdSgp4csiGeXr8f9BEotRB6+kjMBHaiJ6B7BIlDmlffyR4f3oR/5hxgy dvIxMocqyc03xVyM6tA4ZrshKkwDgZIFEKkx37ec22ZJczNwGywKQW2TGXUTZVbdooiG4tXbRBLxe ga/NTZ52ZdEkSxAUGw/l0y0InTtdDIWvfUT+WXtQcEPRBE6HHhoeFehLzWL/o7w5Hog+0hXhNjqte fzKpI2fWmYzoIb6ueNmE/8sP9fWXo6Av9m8B5hRvF/hVWfEysr/2LSqN+xjt9NEbg8WNRMLy/Y0MS p5fgf9pmGF78waFiBvgZIQNuQnHrM+0BmYOhR0JKoHjt7r5wLyNiKFc8b7xXndyCDYfniO3ljbr0j tXWRGxx4to6FwARAQABtCZWaWFjaGVzbGF2IER1YmV5a28gPHNsYXZhQGR1YmV5a28uY29tPokCVw QTAQoAQQIbAQUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBFXDC2tnzsoLQtrbBDlc2cL fhEB1BQJoGl5PAhkBAAoJEDlc2cLfhEB17DsP/jy/Dx19MtxWOniPqpQf2s65enkDZuMIQ94jSg7B F2qTKIbNR9SmsczjyjC+/J7m7WZRmcqnwFYMOyNfh12aF2WhjT7p5xEAbvfGVYwUpUrg/lcacdT0D Yk61GGc5ZB89OAWHLr0FJjI54bd7kn7E/JRQF4dqNsxU8qcPXQ0wLHxTHUPZu/w5Zu/cO+lQ3H0Pj pSEGaTAh+tBYGSvQ4YPYBcV8+qjTxzeNwkw4ARza8EjTwWKP2jWAfA/ay4VobRfqNQ2zLoo84qDtN Uxe0zPE2wobIXELWkbuW/6hoQFPpMlJWz+mbvVms57NAA1HO8F5c1SLFaJ6dN0AQbxrHi45/cQXla 9hSEOJjxcEnJG/ZmcomYHFneM9K1p1K6HcGajiY2BFWkVet9vuHygkLWXVYZ0lr1paLFR52S7T+cf 6dkxOqu1ZiRegvFoyzBUzlLh/elgp3tWUfG2VmJD3lGpB3m5ZhwQ3rFpK8A7cKzgKjwPp61Me0o9z HX53THoG+QG+o0nnIKK7M8+coToTSyznYoq9C3eKeM/J97x9+h9tbizaeUQvWzQOgG8myUJ5u5Dr4 6tv9KXrOJy0iy/dcyreMYV5lwODaFfOeA4Lbnn5vRn9OjuMg1PFhCi3yMI4lA4umXFw0V2/OI5rgW BQELhfvW6mxkihkl6KLZX8m1zcHitCpWaWFjaGVzbGF2IER1YmV5a28gPFNsYXZhLkR1YmV5a29Aa WJtLmNvbT6JAlQEEwEKAD4WIQRVwwtrZ87KC0La2wQ5XNnC34RAdQUCaBpd7AIbAQUJA8JnAAULCQ gHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA5XNnC34RAdYjFEACiWBEybMt1xjRbEgaZ3UP5i2bSway DwYDvgWW5EbRP7JcqOcZ2vkJwrK3gsqC3FKpjOPh7ecE0I4vrabH1Qobe2N8B2Y396z24mGnkTBbb 16Uz3PC93nFN1BA0wuOjlr1/oOTy5gBY563vybhnXPfSEUcXRd28jI7z8tRyzXh2tL8ZLdv1u4vQ8 E0O7lVJ55p9yGxbwgb5vXU4T2irqRKLxRvU80rZIXoEM7zLf5r7RaRxgwjTKdu6rYMUOfoyEQQZTD 4Xg9YE/X8pZzcbYFs4IlscyK6cXU0pjwr2ssjearOLLDJ7ygvfOiOuCZL+6zHRunLwq2JH/RmwuLV mWWSbgosZD6c5+wu6DxV15y7zZaR3NFPOR5ErpCFUorKzBO1nA4dwOAbNym9OGkhRgLAyxwpea0V0 ZlStfp0kfVaSZYo7PXd8Bbtyjali0niBjPpEVZdgtVUpBlPr97jBYZ+L5GF3hd6WJFbEYgj+5Af7C UjbX9DHweGQ/tdXWRnJHRzorxzjOS3003ddRnPtQDDN3Z/XzdAZwQAs0RqqXrTeeJrLppFUbAP+HZ TyOLVJcAAlVQROoq8PbM3ZKIaOygjj6Yw0emJi1D9OsN2UKjoe4W185vamFWX4Ba41jmCPrYJWAWH fAMjjkInIPg7RLGs8FiwxfcpkILP0YbVWHiNAabQoVmlhY2hlc2xhdiBEdWJleWtvIDx2ZHViZXlr b0BrZXJuZWwub3JnPokCVAQTAQoAPhYhBFXDC2tnzsoLQtrbBDlc2cLfhEB1BQJoVemuAhsBBQkDw mcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEDlc2cLfhEB1GRwP/1scX5HO9Sk7dRicLD/fxo ipwEs+UbeA0/TM8OQfdRI4C/tFBYbQCR7lD05dfq8VsYLEyrgeLqP/iRhabLky8LTaEdwoAqPDc/O 9HRffx/faJZqkKc1dZryjqS6b8NExhKOVWmDqN357+Cl/H4hT9wnvjCj1YEqXIxSd/2Pc8+yw/KRC AP7jtRzXHcc/49Lpz/NU5irScusxy2GLKa5o/13jFK3F1fWX1wsOJF8NlTx3rLtBy4GWHITwkBmu8 zI4qcJGp7eudI0l4xmIKKQWanEhVdzBm5UnfyLIa7gQ2T48UbxJlWnMhLxMPrxgtC4Kos1G3zovEy Ep+fJN7D1pwN9aR36jVKvRsX7V4leIDWGzCdfw1FGWkMUfrRwgIl6i3wgqcCP6r9YSWVQYXdmwdMu 1RFLC44iF9340S0hw9+30yGP8TWwd1mm8V/+zsdDAFAoAwisi5QLLkQnEsJSgLzJ9daAsE8KjMthv hUWHdpiUSjyCpigT+KPl9YunZhyrC1jZXERCDPCQVYgaPt+Xbhdjcem/ykv8UVIDAGVXjuk4OW8la nf8SP+uxkTTDKcPHOa5rYRaeNj7T/NClRSd4z6aV3F6pKEJnEGvv/DFMXtSHlbylhyiGKN2Amd0b4 9jg+DW85oNN7q2UYzYuPwkHsFFq5iyF1QggiwYYTpoVXsw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (by Flathub.org) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-06-04 at 22:02 +0800, Kefu Chai wrote: > 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. >=20 > 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.=C2=A0 Monmaps shaped this way cause: >=20 > =C2=A0 libceph: mon0 (1)10.10.10.15:6789 session established > =C2=A0 libceph: another match of type 1 in addrvec > =C2=A0 libceph: problem decoding monmap, -22 >=20 > 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. >=20 > Match that behavior: use the first matching entry and silently skip > any > subsequent ones.=C2=A0 This is a compatibility fix for existing > deployments > and does not enable dual-stack or multi-subnet address selection. >=20 > Link: https://bugzilla.proxmox.com/show_bug.cgi?id=3D7518 > Signed-off-by: Kefu Chai > --- > Changes since v1: > - Rewrite commit message to frame as compatibility fix; drop dual- > stack/ > =C2=A0 multi-subnet framing and the two ceph tracker links > - Simplify comment in ceph_decode_entity_addrvec() >=20 > Tested by reproducing the Proxmox BZ 7518 scenario against a vstart > cluster whose mon addrvec was edited to contain two v1 + two v2 > entries: >=20 > =C2=A0=C2=A0=C2=A0 ceph mon set-addrs a \ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 '[v2:$ip1:$p2/0,v1:$ip1:$p1/0,= v2:$ip2:$p2/0,v1:$ip2:$p1/0]' >=20 > A Debian VM booted with the patched kernel via 'qemu -kernel' then > ran 'mount -t ceph ...:$p1:/ /mnt -o name=3Dadmin'.=C2=A0 Pre-patch kerne= ls > fail at monmap decode with "another match of type 1 in addrvec" > (-EINVAL).=C2=A0 Post-patch, decode succeeds and the mount proceeds to > the auth / MDS-discovery stages. >=20 > Also verified the decoder logic on the monmap.bin attached to BZ 7518 > using a userspace port of ceph_decode_entity_addrvec(): the pre-patch > form returns -EINVAL on both msgr1 and msgr2 lookups; the post-patch > form returns 0 and picks the first matching entry. >=20 > =C2=A0net/ceph/decode.c | 13 ++++--------- > =C2=A01 file changed, 4 insertions(+), 9 deletions(-) >=20 > diff --git a/net/ceph/decode.c b/net/ceph/decode.c > index bc109a1a4616..18f0a7c71950 100644 > --- a/net/ceph/decode.c > +++ b/net/ceph/decode.c > @@ -87,8 +87,9 @@ ceph_decode_entity_addr(void **p, void *end, struct > ceph_entity_addr *addr) > =C2=A0EXPORT_SYMBOL(ceph_decode_entity_addr); > =C2=A0 > =C2=A0/* > - * Return addr of desired type (MSGR2 or LEGACY) or error. > - * Make sure there is only one match. > + * Return addr of desired type (MSGR2 or LEGACY) or error.=C2=A0 If > multiple > + * entries of the desired type are present, use the first one for > + * compatibility with existing deployments. > =C2=A0 * > =C2=A0 * Assume encoding with MSG_ADDR2. > =C2=A0 */ > @@ -120,13 +121,7 @@ int ceph_decode_entity_addrvec(void **p, void > *end, bool msgr2, > =C2=A0 return ret; > =C2=A0 > =C2=A0 dout("%s i %d addr %s\n", __func__, i, > ceph_pr_addr(&tmp_addr)); > - if (tmp_addr.type =3D=3D my_type) { > - if (found) { > - pr_err("another match of type %d in > addrvec\n", > - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 le32_to_cpu(my_type)); Maybe, we still need to have some debugging output here? What's about dout()? Thanks, Slava. > - return -EINVAL; > - } > - > + if (tmp_addr.type =3D=3D my_type && !found) { > =C2=A0 memcpy(addr, &tmp_addr, sizeof(*addr)); > =C2=A0 found =3D true; > =C2=A0 } > -- > 2.47.3