From nobody Tue Apr 14 15:59:07 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fw89C0ypdz6Z2jY for ; Tue, 14 Apr 2026 15:59:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fw89B626cz3L0B for ; Tue, 14 Apr 2026 15:59:26 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; arc=pass ("google.com:s=arc-20240605:i=1"); dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-6720c7968e4so941314a12.0 for ; Tue, 14 Apr 2026 08:59:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776182360; cv=none; d=google.com; s=arc-20240605; b=W+d/E/hHApg4pIhbR88QbWOqr/3iJdjwYO98ydmOqCOLiFplEGAInsVOBcEquahpTy G3UfbeDVjpYAgZmIWy6YKvbEA01NDJ+gLbxjmzJfqD9CiCetPfDUBKK9PYoREXdB4Q9J 99RyYqGVdWFQCjMMkuE8W7n3QI4PAJhIImT5BVBb44IQIuS2rswTFamKPmrFWY7WK8n+ cyzoEwTNKZpF6fW3F5eyq3PfVkAkjTJbtWPUtMyjOZdDOy9ivcQCwg4hPwKQNbiyIN9Z 5vYBKJbub8GNoxPXo07PHVgiVFVdRmNPHdnpJe1BecLCDoosCKu1vn73EijgjehfIeYP bkTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version; bh=jxf8/aEjDiN6rsg4Ncu9YJaPGBL6iHR77KBxNbLhgK4=; fh=mBjLe6y8L4LDNBqsya+A4auh5O1M8r2cRaZ3M2ADm7o=; b=XCE4wMV6WKFDZK4Djkj4JZnYDKu3Lq4o36P6kHfnyKmecpOnT+r4/ITbA67RW66O1b 4WdG21gewxC6Tiv5uPdd7XtDWqqotZkCRPmiV4KQq4fetNjP6+tewv9OvNZncYDBheoW zDTI5rgjvAXuCUNwjQSJCOozM8p6KAWf/MEm+GzQ0FK7Y8x0R7NjX2pL0GzlqPP/Wa/S yii7BWItRDyefZyHlnWV6NurXV9hVdL/IBIL8tyezCrPyrKwQ5rpZK0VtoyvnToUTvqc l38wvB/toKRGTdNIJNIlU0cCb3SJq0asHoTPVU5AaAYK3DEHlYx9eZmHl+TJ35M4l2XN 2Xcw==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776182360; x=1776787160; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jxf8/aEjDiN6rsg4Ncu9YJaPGBL6iHR77KBxNbLhgK4=; b=cOcqI2n4fJwKjGi4tH3tC4f/Onl7Rhz09kP6M2kL682bY7jjydn9RWKTILCCH0jl9v ueOOKCXrODT5BTuwp3GBJtI+zxpCWLsuh3TFApXtI+AglAhMcnTIqzPZGMBfFWl26lRL tjwuMccEMVLDDKxeoPztDKwARgpZ7imo9/DAAJjZg+t4AOEOvYoQV6mo6HElt1F2GfW/ vcB3tqSv8OBLSN8PRrbVonwCekt6HES4Ou5iGORkgIMdi4msDHn1yVS0rBbgOHO5SGSt JmoPNu4wrO0z1SyfIx0vQdv2pSkvwkGrx9TrRDl4fTL1jph5CkI2sJiH5Y+xO3szmcKi HjeQ== X-Forwarded-Encrypted: i=1; AFNElJ/S5sJmlI1ETxJ1nkCSuMcOXEFo6YBIeqgeM0Z7Dahifdu8AeIguPEKQ246fEyLAMr8B2cehjh2zv1DeC9mzrhsCgpH@freebsd.org X-Gm-Message-State: AOJu0YzKclv9UasX8Q1LxvYdbyG/T2p17pRfbokeBImgBmpDogoFb7pu VQhSPUvwaije1raZ6EBI+6gJI7xjqrJIMdp9kbrV3OprNGM1P9WpE7p96InpI0V0/5LuMO13zAH gBilzu4evotxm7wKYoQfiU1DB3aYARSk= X-Gm-Gg: AeBDieswFFQ+ykJVNVgeEAb3GMnDNRGvQxWwb2RPIaUBAwtbcb1bRHRsk6fqTZKPjSk OvC1VmMCZSepL1fLl9pNKjqNyPszQ8C6ZlvFTtQi5GuOJJtYtNx43uptuyVjBQkNwZea9px23gO +O63QsY72PF+Oi5ROm7ubocJqdn/x2osPwFcjIBgUQYqJ1VSUL0JcvJfOLEKnTiZA7pF7AX5cbx wVoop2gv0nfONJaMZWDaynas+ydjt0e1wFdF/4YxL+4Bm5HTWh16kSw7lp6d8MKEX9iuIY23sOL OxvcbdsQEQOZg0KXxYLQZGx9/Xk1jbruoKyKdu2HHI88L1sSYyFTRxn6yW2J5s1d9o7tVKo0uBh z2vo= X-Received: by 2002:a05:6402:454a:b0:66e:6f38:47ef with SMTP id 4fb4d7f45d1cf-670752ab0e7mt7007899a12.8.1776182360033; Tue, 14 Apr 2026 08:59:20 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202508062010.576KA2Mk062184@gitrepo.freebsd.org> <680f1cb7-f8f6-4d40-af31-83e2ea0205d6@FreeBSD.org> In-Reply-To: From: Alan Somers Date: Tue, 14 Apr 2026 09:59:07 -0600 X-Gm-Features: AQROBzDliuCRFuDXQt97Uw597qNeo5cx6cvNwLVliT9gCnYYi-4jf3hVBoLzrBY Message-ID: Subject: Re: git: 66b5296f1b29 - main - ctld: Add support for NVMe over Fabrics Cc: John Baldwin , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [0.11 / 15.00]; MISSING_TO(2.00)[]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_SPAM_LONG(1.00)[0.997]; NEURAL_HAM_SHORT(-0.99)[-0.990]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-all@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.47:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.47:from] X-Rspamd-Queue-Id: 4fw89B626cz3L0B X-Spamd-Bar: / On Tue, Apr 14, 2026 at 6:35=E2=80=AFAM Alan Somers w= rote: > > On Tue, Apr 14, 2026 at 4:31=E2=80=AFAM John Baldwin wr= ote: > > > > On 4/13/26 13:36, Alan Somers wrote: > > > On Mon, Apr 13, 2026 at 10:56=E2=80=AFAM John Baldwin wrote: > > >> > > >> On 4/13/26 11:51, Alan Somers wrote: > > >>> On Wed, Aug 6, 2025 at 2:10=E2=80=AFPM John Baldwin wrote: > > >>>> > > >>>> The branch main has been updated by jhb: > > >>>> > > >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=3D66b5296f1b29083634e= 2875ff08c32e7b6b866a8 > > >>>> > > >>>> commit 66b5296f1b29083634e2875ff08c32e7b6b866a8 > > >>>> Author: John Baldwin > > >>>> AuthorDate: 2025-08-06 19:57:50 +0000 > > >>>> Commit: John Baldwin > > >>>> CommitDate: 2025-08-06 19:59:13 +0000 > > >>>> > > >>>> ctld: Add support for NVMe over Fabrics > > >>>> > > >>>> While the overall structure is similar for NVMeoF controller= s and > > >>>> iSCSI targets, there are sufficient differences that NVMe su= pport uses > > >>>> an alternate configuration syntax. > > >>>> > > >>>> - In authentication groups, permitted NVMeoF hosts can be al= lowed by > > >>>> names (NQNs) via "host-nqn" values (similar to "initiator-= name" for > > >>>> iSCSI). Similarly, "host-address" accepts permitted host = addresses > > >>>> similar to "initiator-portal" for iSCSI. > > >>>> > > >>>> - A new "transport-group" context enumerates transports that= can be > > >>>> used by a group of NVMeoF controllers similar to the "port= al-group" > > >>>> context for iSCSI. In this section, the "listen" keyword = accepts a > > >>>> transport as well as an address to permit other types of t= ransports > > >>>> besides TCP in the future. The "foreign", "offload", and = "redirect" > > >>>> keywords are also not meaningful and thus not supported. > > >>>> > > >>>> - A new "controller" context describes an NVMeoF I/O control= ler > > >>>> similar to the "target" context for iSCSI. One key differ= ence here > > >>>> is that "lun" objects are replaced by "namespace" objects.= However, > > >>>> a "namespace" can reference a named global lun permitting = LUNs to be > > >>>> shared between iSCSI targets and NVMeoF controllers. > > >>>> > > >>>> NB: Authentication via CHAP is not implemented for NVMeoF. > > >>>> > > >>>> Reviewed by: imp > > >>>> Sponsored by: Chelsio Communications > > >>>> Differential Revision: https://reviews.freebsd.org/D48773 > > >>> ... > > >>>> +struct target * > > >>>> +conf::add_controller(const char *name) > > >>>> +{ > > >>>> + if (!nvmf_nqn_valid_strict(name)) { > > >>>> + log_warnx("controller name \"%s\" is invalid for N= VMe", name); > > >>>> + return nullptr; > > >>>> + } > > >>>> + > > >>>> + /* > > >>>> + * Normalize the name to lowercase to match iSCSI. > > >>>> + */ > > >>>> + std::string t_name(name); > > >>>> + for (char &c : t_name) > > >>>> + c =3D tolower(c); > > >>> ... > > >>> > > >>> This makes it impossible to define an uppercase or mixed case targe= t > > >>> name in ctld. I guess the intent was to comply with rfc3722[^1]? > > >>> Even so, it's surprising, because such target names used to work. > > >>> It's also inconsistent, because it's still possible to create an > > >>> uppercase target name using ctladm directly, like this: > > >>> > > >>> ctladm port -c -d iscsi -O cfiscsi_portal_group_tag=3D257 -O > > >>> cfiscsi_target=3Diqn.2018-10.myhost:TESTVOL1 > > >>> > > >>> Should we warn the user if they specify an uppercase target name, o= r > > >>> even fail to create it? > > >>> > > >>> [^1]: https://datatracker.ietf.org/doc/html/rfc3722 > > >> > > >> Note that this function is for NVMe, not iSCSI. iSCSI targets are c= reated in > > >> conf::add_target which has similar code: > > >> > > >> struct target * > > >> conf::add_target(const char *name) > > >> { > > >> if (!valid_iscsi_name(name, log_warnx)) > > >> return (nullptr); > > >> > > >> /* > > >> * RFC 3722 requires us to normalize the name to lowercase. > > >> */ > > >> std::string t_name(name); > > >> for (char &c : t_name) > > >> c =3D tolower(c); > > >> > > >> Prior to the C++ commit, this change was already in place: > > >> > > >> struct target * > > >> target_new(struct conf *conf, const char *name) > > >> { > > >> struct target *targ; > > >> int i, len; > > >> > > >> targ =3D target_find(conf, name); > > >> if (targ !=3D NULL) { > > >> log_warnx("duplicated target \"%s\"", name); > > >> return (NULL); > > >> } > > >> if (valid_iscsi_name(name, log_warnx) =3D=3D false) { > > >> return (NULL); > > >> } > > >> targ =3D new target(); > > >> targ->t_name =3D checked_strdup(name); > > >> > > >> /* > > >> * RFC 3722 requires us to normalize the name to lowercase. > > >> */ > > >> len =3D strlen(name); > > >> for (i =3D 0; i < len; i++) > > >> targ->t_name[i] =3D tolower(targ->t_name[i]); > > >> > > >> targ->t_conf =3D conf; > > >> TAILQ_INSERT_TAIL(&conf->conf_targets, targ, t_next); > > >> > > >> return (targ); > > >> } > > >> > > >> This was present in commit 009ea47eb2d21856af4529aaaca32cd67748daea > > >> which brought in the iSCSI target, so it has always been present > > >> in ctld. > > >> > > >> Also, AFAICT, the names are still accepted, they are just normalized= . > > >> > > >> I guess one difference is that before, target_new() called target_fi= nd() > > >> with the non-normalized name to check for duplicates, and now we che= ck > > >> for duplicates after normalizing the name. I'm not sure how that wo= rked > > >> in the past in practice as you would have had two targets with the s= ame > > >> name (e.g. I wonder what the ctladm portlist output looked like for = this > > >> case and if it would have listed two ports with the same name)? I s= uspect > > >> that was more by accident and probably didn't work properly in pract= ice > > >> (e.g. the kernel handoff ioctl used the normalized name when invokin= g > > >> CTL_ISCSI, so connections to both "names" probably were always mappe= d to > > >> only one of the connections, and finding a port during login process= ing > > >> probably only found the first target, and only if the initiator gave= the > > >> all-lowercase name). > > >> > > >> That is to say, you didn't get an error before, but it didn't work, = and > > >> now it tells you that it doesn't work AFAICT. > > > > > > Excuse me, I spoke a little too soon. You are correct that ctld has > > > been converting target names to lower case before registering them in > > > the kernel for a long time. The change is that previously, if an > > > initiator attempted to connect to an uppercase target name, ctld woul= d > > > accept it. That's because port_find_in_pg used strcasecmp in > > > stable/14. But change 4b1aac931465f39c5c26bfa1d5539a428d340f20 > > > removed strcasecmp, replacing it by the C++ STL's find method on > > > std::unordered_map. > > > > > > So we used to accept connections case-insensitively, and now we accep= t > > > them case-sensitively. To restore the previous behavior, should we > > > add tolower() on the target_name in iscsi_connection::login() ? > > > > Yes, we should normalize there, and that indeed is my fault and warrant= s > > a Fixes tag. > > > > -- > > John Baldwin > > Ok. I'll take care of it. FYI, I opened this bug, just so other users can find the issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D294522