Re: [PATCH v5 1/1] KVM: trigger uevents when creating or destroying a VM

[Radim KrÄmÃÅ]

2017-07-17 18:27+0200, Claudio Imbrenda:
> On Mon, 17 Jul 2017 17:53:51 +0200
> David Hildenbrand <david@xxxxxxxxxx> wrote:
> > > +		tmp = strchrnul(p + 1, '-');> +
> > > *tmp = '\0';
> > > +		add_uevent_var(env, "PID=%s", p);

When we're at it ... PID exists regardless of debugfs, so it would be
nice to provide it unconditionally.
(This interface looks like it was added to discourage the use of debugfs
 directory notifier in simple cases.)

I guess we cannot use task_pid_nr(current) on the KVM_EVENT_DESTROY_VM
path, so saving the PID in struct kvm would be better, IMO (it wastes
memory with larger number of VMs, but the code is harder to break).

> > > +			tmp = dentry_path_raw(kvm->debugfs_dentry,
> > > +					      pathbuf + len,
> > > +					      PATH_MAX - len);
> > > +			if (!IS_ERR(tmp)) {  
> > 
> > Why not
> > 
> > tmp = dentry_path_raw(kvm->debugfs_dentry, pathbuf, PATH_MAX);
> > if (!IS_ERR(tmp)) {
> > 	add_uevent_var(env, "STATS_PATH=s", tmp);
> > }
> > 
> > and avoid len / pvar / memcpy? And keep internal env size checking
> > consistent.
> 
> that would be true, but then we would copy the buffer with the path
> twice, once for dentry_path_raw and once for add_uevent_var.
> 
> the env size is consistent, since that would count the bytes
> effectively present in the buffer, and note that kobject_uevent_env only
> wants a char**, no length, so there are no consistency issues. 
> 
> I agree that your solution looks better (and I had actually considered
> implementing it like that initially), but it can potentially be slower.
> I don't really have any strong preference.
> 
> Paolo: which solution do you like the most? 

I slightly prefer the simpler version as performance of the path is not
that critical.

Please note that the original patch is already in 4.13 (it was ok and my
nitpicking would just make it miss the merge window :]), so the code
improvements need to be a new patch,

thanks.