From owner-freebsd-bugs@freebsd.org Mon Jan 13 20:23:26 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8F3321EB911 for ; Mon, 13 Jan 2020 20:23:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47xQ5V3M7pz48KN for ; Mon, 13 Jan 2020 20:23:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 732851EB910; Mon, 13 Jan 2020 20:23:26 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 72EDC1EB90F for ; Mon, 13 Jan 2020 20:23:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47xQ5V2R5tz48KM for ; Mon, 13 Jan 2020 20:23:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4EE9BA37D for ; Mon, 13 Jan 2020 20:23:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00DKNQOb026653 for ; Mon, 13 Jan 2020 20:23:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00DKNQHu026635 for bugs@FreeBSD.org; Mon, 13 Jan 2020 20:23:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 243318] GEOM /dev/diskid '%20' in names Date: Mon, 13 Jan 2020 20:23:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity cc version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 20:23:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243318 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Some People |Affects Many People CC| |cem@freebsd.org Version|12.1-RELEASE |CURRENT --- Comment #1 from Conrad Meyer --- The device node comes from GEOM label. g_label_disk_ident taste gets the string from g_io_getattr GEOM::ident and does not modify it. It is then returned to g_label.c::g_label_taste,=20 386 g_labels[i]->ld_taste(cp, label, sizeof(label)); 387 g_label_mangle_name(label, sizeof(label)); 388 g_topology_lock(); 389 if (label[0] =3D=3D '\0') 390 continue; 391 g_label_create(NULL, mp, pp, label, g_labels[i]->ld_dir, 392 pp->mediasize); g_label_mangle_name is what converts spaces into valid /dev names (no space= s): 178 g_label_mangle_name(char *label, size_t size) 179 { 180 struct sbuf *sb; 181 const u_char *c; 182 183 sb =3D sbuf_new(NULL, NULL, size, SBUF_FIXEDLEN); 184 for (c =3D label; *c !=3D '\0'; c++) { 185 if (!isprint(*c) || isspace(*c) || *c =3D=3D'"' || *c = =3D=3D '%') 186 sbuf_printf(sb, "%%%02X", *c); 187 else 188 sbuf_putc(sb, *c); Where does GEOM::ident come from? Only two places: md(4) (not this case) a= nd cam_xpt (this case): xpt_getattr: 1233 struct ccb_dev_advinfo cdai; 1239 memset(&cdai, 0, sizeof(cdai)); 1240 xpt_setup_ccb(&cdai.ccb_h, path, CAM_PRIORITY_NORMAL); 1241 cdai.ccb_h.func_code =3D XPT_DEV_ADVINFO; 1242 cdai.flags =3D CDAI_FLAG_NONE; 1243 cdai.bufsiz =3D len; 1244 cdai.buf =3D buf; 1245 1246 if (!strcmp(attr, "GEOM::ident")) 1247 cdai.buftype =3D CDAI_TYPE_SERIAL_NUM; Ok. There are 4 CAM transports that handle CDAI_TYPE_SERIAL_NUM: ata, mmc, nvme, and scsi. This is scsi. 2512 scsi_dev_advinfo(union ccb *start_ccb) 2513 { 2514 struct cam_ed *device; ... 2534 case CDAI_TYPE_SERIAL_NUM: 2543 memcpy(cdai->buf, device->serial_num, amt); So... what's setting it in device->serial_num? cam/scsi/scsi_xpt.c:: probestart() PROBE_SERIAL_NUM -> probedone PROBE_SERIAL_NUM: We try to trim off leading spaces: 1574 case PROBE_SERIAL_NUM: 1575 { ... 1603 start =3D strspn(serial_buf->serial_= num, " "); 1604 slen =3D serial_buf->length - start; ... 1613 memcpy(path->device->serial_num, 1614 &serial_buf->serial_num[start= ], slen); 1615 path->device->serial_num_len =3D sle= n; 1616 path->device->serial_num[slen] =3D '= \0'; But not trailing spaces, AFAICT. So, it seems to me like we should probably trim trailing spaces at some lay= er.=20 It could be done in CAM, since the serial number probably does end in liter= al spaces (fixed size field). It could be done in g_label, but that would imp= act all g_label devices. (I'm not sure that's a bad thing.) If you label your= GPT partition "foo ", is it really helpful to have /dev/gpt/foo%20%20%20%20= ? I suspect not. --=20 You are receiving this mail because: You are the assignee for the bug.=