On 10/11/23 16:31, Sergey Mironov wrote: > In version 0.10.0-rc0 (https://github.com/libvirt/libvirt/blob/v0.10.0-rc0/src/security/security_selinux.c ) 11 years ago, > the virSecuritySELinuxSetFileconHelper function appeared, which returned 1 if the optional is true. > Considering that at the moment the virSecuritySELinuxSetFilecon function (by definition) can only return 0 or -1, I suggest removing the "dead code" in the current patch. > > Co-developed-by: sdl.qemu <sdl.qemu@xxxxxxxxxxxxxxxx> > Signed-off-by: Sergey Mironov <mironov@xxxxxxxxxx> > --- > src/security/security_selinux.c | 11 ----------- > 1 file changed, 11 deletions(-) > > diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c > index 7914aba84d..a7abab9cf8 100644 > --- a/src/security/security_selinux.c > +++ b/src/security/security_selinux.c > @@ -1988,17 +1988,6 @@ virSecuritySELinuxSetImageLabelInternal(virSecurityManager *mgr, > ret = virSecuritySELinuxSetFilecon(mgr, path, use_label, remember); > } > > - if (ret == 1 && !disk_seclabel) { > - /* If we failed to set a label, but virt_use_nfs let us > - * proceed anyway, then we don't need to relabel later. */ > - disk_seclabel = virSecurityDeviceLabelDefNew(SECURITY_SELINUX_NAME); > - if (!disk_seclabel) > - return -1; > - disk_seclabel->labelskip = true; > - VIR_APPEND_ELEMENT(src->seclabels, src->nseclabels, disk_seclabel); > - ret = 0; > - } > - > return ret; > } > At this point, the @ret variable can be removed as well. But I can live with that. What I can't live with is the commit message. Firstly, there's no need to link the source file if you mention the actual commit that introduced the function: 12b187fb956bffbc67a090dcda89e66450503a4e and to make the hash more readable, just use git-describe (which in this particular case yields some CVE-* tag, so pass --match=v\* to get v0.10.0-rc0~108). Nit-pick - mentioning the commit when a function was introduced is good, but also, we are probably more interested in what commit turned these lines into a dead code. Because without that the first piece of information makes a great sensation (we have a dead code for 11 years!, which is obviously not true). Then there are more rigid customs we tend to hold: 1) if you look at 'git log --oneline' you'll see that majority (if not all) commits are prefixed with something (usually the module they change). Thus in this case it should have been "selinux: ". 2) Continuing with git log - "selinux: Checking the value ..." does not really describe what's happening. You are dropping the check, not introducing it. I'm sorry if I sound too picky, but these rules help greatly downstream maintainers when they need to figure out what each commit does. Anyway, I'm fixing the commit message and pushing. Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Michal