From nobody Mon Apr 13 16:56:37 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 4fvYTf48G8z6ZQmQ; Mon, 13 Apr 2026 16:56:38 +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 4fvYTf3cQ5z3HCn; Mon, 13 Apr 2026 16:56:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1776099398; 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=cymmBp0CvKOJnVJFkTWB99sCtTICR7yh9qGoNJfCHrA=; b=ud8whnMSCquWhVH9HibzQ1kkPDPRUx3GhFVW4nKxewsYRMD3XeaQ87lgg5ME0ix9RwQy5l BXHouDgMeWsoRk5pTPqFNgiPcaJ5aLiOylpcD5tHLilW0QeDYZejy+SQ3sm/vGjrL1tjsx ewrTWxoTmiY/NUvWXyWff1XIE9760oggtZnCCy3Vgdwoh6dD5kVKaJCT2misIdeyKKt3tG 3jhV9BJljDKPJeg4mW6eYiv4dhAPygvv4FKzJ9hLRFrCvIKR5M1aufUxQMxvFJkMfgh1Sc iT9d1BNZq2NBq34+X9rH1z0a2u35GZm3h+kxyYL8Lficg37Y3kyYweP4NHz+dg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1776099398; a=rsa-sha256; cv=none; b=gpJrE97tBfjxEsHVCS/2WC9QLed6pHbUfgpmUb67HngTKyRDo8cV9MH3QCa17oJ1ms2eUu CPVH7Gp9CovbxVHyg/q5JfIhMS8+w3NYdd889MVCpcYOlsP+24RWmrte6lbfNFiVWXLkKz hFllMxzyxVIoPsweD3Nx2ZlNZrMocu5E+kyGceM3j2LeSkEazO15l3n7O+AXJxdP1TaujN hyRiFzxhJsLgTyEyjIOxJVSKSQsocvnQPrOSGwlH6MAFHOvpSJBdAjaKbe3T/1nYvGBOEg 0V6riUiEOyFNk9tXh1IKK1PmCj8J3BYeMVOR2crBe3YXd1rKjPJTOAYSL0Cgxw== 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=1776099398; 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=cymmBp0CvKOJnVJFkTWB99sCtTICR7yh9qGoNJfCHrA=; b=DcTAIdEA4ktrroww+FI5gU4PkPFqFesdrkS9MB/p+4EKV8EHCqdKcUJUYG3nC0/NznfTIZ I0WtYbfrN1kgslrMyrxpgt68jpyAu/a1FEM9uoSIAGaz0yhxcXk0GX86Y6NfvzQV44Q2ut di/hTcAAYk29gH1q+HRGb3FwCKS339fjJ34n7YeJY3RyaZmw7L7LUapGesCsG/Xr7xrfYT 95GiSxtkwCKuuTqCmS59q1aYjDoreM0zw1O1IcqMVdcO7dKU+8lEMu25sKdxC1KvKrDXyL /63iAszAtu8OJdivTKJ6BwXeIOs9vmqtaJAiJnhxGzE0rovNnr7hfEwbeMMmBA== Received: from [IPV6:2601:5c0:4202:5670:7939:bbf5:92d0:fbb9] (unknown [IPv6:2601:5c0:4202:5670:7939:bbf5:92d0:fbb9]) (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 4fvYTf1b0rzmwm; Mon, 13 Apr 2026 16:56:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 13 Apr 2026 12:56:37 -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 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. -- John Baldwin