On 2016/11/09 at 11:06, Pratyush Anand wrote: > > > On Wednesday 09 November 2016 08:18 AM, Xunlei Pang wrote: >>> > Moreover, do we really need to trace module_put? You have filter for module loading applications, and pids for different module load instances would be different, so even if module_put is not tracked, it should work, no? >> We need to keep it, lets take an example to illustrate, "insmod mymodule" will hit "module_load" then "module_put" >> (even for insert failed cases), then other possible alloc_pages events, init function of the module is called between >> "module_load" and the following "module_put" trace point, we only care about alloc_pages events captured in between. > > I do not have any strong feeling, so I am oK with what is there currently implemented in this patch. > > It was just to make it a bit more simple. > - We will have trace event generated only for the module insertion process. > - There would be a different PID for each insertion This may not be true, AFAIK "systemd-udevd" can load multiple modules in the same task(same pid). So we need to know when the process will finish for each loading. Regards, Xunlei > - "The other possible alloc_pages events" described above would still belong to same insmod operation (from userspace). And we will not have any new page allocation until a new insmod or siblings start (so a new PID). Therefore, why to set/unset.Just track with PID. > -- > To unsubscribe from this list: send the line "unsubscribe initramfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
