From nobody Tue Apr 14 10:31:41 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 4fw0v26MKrz6ZZJn; Tue, 14 Apr 2026 10:31:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fw0v25gqvz3S9N; Tue, 14 Apr 2026 10:31:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1776162702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=66wBet8nT5SN+6PqDxSTMlepCraMxwiXSJxDs4tk7zs=; b=TiwZI617TlErF8y/tTG6Sg2PxLZRKEC+rQY7imeuErr5aZSli91DuSbZfSECxL7OtHvcjT lfVx1b+PJi8geZl+3owkNRXObwZolvWAbkxG7raw/Hlg08fpe73TGIsa5u/VX33JSBVkF4 55KzEqdVjyqQlgff6e7P+qrKhFuUI0AldNRUwmq/4HAiD1Fo2JQRFCPUvM5DSZsRs5PHGn UvGg/pJa4+VzZSB8GiPFfOvUCB6yHGgB43R8T1QdeilVIhzcVzySw4YMgQC8H5lIeYNBG4 qM5KLkm8NdfLeIxLPDqra0OF9Xk1kp/m0oLd5b84rCz4bVwyWLxF6NuJeFOAwQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1776162702; a=rsa-sha256; cv=none; b=MMX25M8wMl8vuJzVBq/j7Qkvl1uxFbJAY1KrUanYRUFiLVw18N/2NnC0QwivsLsqCLpVXW 77t2bP58eTICrKv6uCbdCaYAOPwOLkQzgkOuUHbnbMqEHE2qKy9ElKYzIu/GaRBHMoY4WX qV5peQ+LC2a35Dq52ZyNHVckBzfKuxWbBPHrLnnigBoOpUBEjhqpyRsj/wTNX7KN+gdZ9O ayQUc5vafs8h1yRPVC+Ft6soUZW3ctDKWpMe5oFgdIp/TKQNPDP8bkA+Jp6hc2W4ocGSOy zGFcXDyvEjQkhLf9+Eob/MSbLyM99hX7ebci104xQg1IlgJNbXWDxCKNG/n65g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1776162702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=66wBet8nT5SN+6PqDxSTMlepCraMxwiXSJxDs4tk7zs=; b=ba1J+wU8v3WnlzpTrxktIMSJymYp8o5G+ZwEcb80zBEAd4SUxstpXgKT1qAZ42mx3HJGy+ MTZArersks9X0Cv3bPND2vvZJuM6SfAle+z5rZkkGQXNUT0wbQkhxO+pgLfoL3QO6/6tZw ZU5OUFcwAAOr9OyXz8AeS8WvZpI5TydZ2S1UasFge/t/Qg4Ee1O4bc4v8nWG5f883Y9Nl+ IbNuJptnXbfGqU5/Ha5MBsmtFKh0L+RLLnS0hyHzUfC4D9sa2Ax57J2nH3J/sgIdaPsKZC q+2ROiOFoY6tze800jpNXdvOKtgdxwKz4fJtucQISAKUdjcLYtCq3DIjRfgFbg== Received: from [IPV6:2601:5c0:4202:5670:a430:510:6dbb:a5ca] (unknown [IPv6:2601:5c0:4202:5670:a430:510:6dbb:a5ca]) (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 did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4fw0v23kKrz199Q; Tue, 14 Apr 2026 10:31:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <680f1cb7-f8f6-4d40-af31-83e2ea0205d6@FreeBSD.org> Date: Tue, 14 Apr 2026 06:31:41 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: git: 66b5296f1b29 - main - ctld: Add support for NVMe over Fabrics Content-Language: en-US To: Alan Somers Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202508062010.576KA2Mk062184@gitrepo.freebsd.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/13/26 13:36, Alan Somers wrote: > On Mon, Apr 13, 2026 at 10:56 AM John Baldwin wrote: >> >> On 4/13/26 11:51, Alan Somers wrote: >>> On Wed, Aug 6, 2025 at 2:10 PM John Baldwin wrote: >>>> >>>> The branch main has been updated by jhb: >>>> >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=66b5296f1b29083634e2875ff08c32e7b6b866a8 >>>> >>>> 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 controllers and >>>> iSCSI targets, there are sufficient differences that NVMe support uses >>>> an alternate configuration syntax. >>>> >>>> - In authentication groups, permitted NVMeoF hosts can be allowed 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 "portal-group" >>>> context for iSCSI. In this section, the "listen" keyword accepts a >>>> transport as well as an address to permit other types of transports >>>> 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 controller >>>> similar to the "target" context for iSCSI. One key difference 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 NVMe", name); >>>> + return nullptr; >>>> + } >>>> + >>>> + /* >>>> + * Normalize the name to lowercase to match iSCSI. >>>> + */ >>>> + std::string t_name(name); >>>> + for (char &c : t_name) >>>> + c = tolower(c); >>> ... >>> >>> This makes it impossible to define an uppercase or mixed case target >>> 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=257 -O >>> cfiscsi_target=iqn.2018-10.myhost:TESTVOL1 >>> >>> Should we warn the user if they specify an uppercase target name, or >>> 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 created 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 = 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 = target_find(conf, name); >> if (targ != NULL) { >> log_warnx("duplicated target \"%s\"", name); >> return (NULL); >> } >> if (valid_iscsi_name(name, log_warnx) == false) { >> return (NULL); >> } >> targ = new target(); >> targ->t_name = checked_strdup(name); >> >> /* >> * RFC 3722 requires us to normalize the name to lowercase. >> */ >> len = strlen(name); >> for (i = 0; i < len; i++) >> targ->t_name[i] = tolower(targ->t_name[i]); >> >> targ->t_conf = 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_find() >> with the non-normalized name to check for duplicates, and now we check >> for duplicates after normalizing the name. I'm not sure how that worked >> in the past in practice as you would have had two targets with the same >> 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 suspect >> that was more by accident and probably didn't work properly in practice >> (e.g. the kernel handoff ioctl used the normalized name when invoking >> CTL_ISCSI, so connections to both "names" probably were always mapped to >> only one of the connections, and finding a port during login processing >> 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 would > 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 accept > 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 warrants a Fixes tag. -- John Baldwin