Date: Mon, 13 Jan 2020 20:23:26 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 243318] GEOM /dev/diskid '%20' in names Message-ID: <bug-243318-227-GrSmSFr72f@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-243318-227@https.bugs.freebsd.org/bugzilla/> References: <bug-243318-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243318 Conrad Meyer <cem@freebsd.org> 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 <cem@freebsd.org> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-243318-227-GrSmSFr72f>