Hi all, I looked into it and tried to use TASK_COMM_LEN in the test. Even though I included "linux/sched.h '', I was not able to compile the test because it couldn't find it in the header file. I dived deep into the issue and turns out header file mapped in /usr/include/linux/sched.h is actually mapped to /include/uapi/linux/sched.h[1] in linux source, where TASK_COMM_LEN is not even defined. Instead TASK_COMM_LEN is defined in /include/linux/sched.h which is not mapped to any header files in userspace(/(/usr/include/linux). I also tried to find the TASK_COM_LEN in /usr/include/linux/ but I couldn't find it. Following are the search results. grep -rnw '/usr/include/linux/' -e 'TASK_COMM_LEN" RESULTS OF COMMAND :- /usr/include/linux/taskstats.h:38:#define TS_COMM_LEN 32 /* should be >= TASK_COMM_LEN Based on this information, I have two questions: 1. Would this require a fix to move 'TASK_COMM_LEN' macro from /include/linux/sched.h to UAPI headers /include/uapi/linux/sched.h. 2. Is there any other way to access TASK_COMM_LEN in the selftest that I'm not aware of? [1]:-https://elixir.bootlin.com/linux/v5.15.116/source/include/uapi/linux/sched.h Thanks, Osama On Sat, 10 Jun 2023 at 02:43, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote: > > On 6/7/23 09:36, Osama Muhammad wrote: > > This patch will add the new test, which covers the prctl call > > PR_SET_NAME command. The test tries to give a name using the PR_SET_NAME > > call and then confirm it that it changed correctly by using PR_GET_NAME. > > It also tries to rename it with empty name.In the test PR_GET_NAME is > > tested by passing null pointer to it and check its behaviour. > > > > Signed-off-by: Osama Muhammad <osmtendev@xxxxxxxxx> > > > > --- > > changes since v1: > > -Used TASK_COMM_LEN instead of using numerical value 16. > > Please add linux/sched.h here as an include to pull this. > It is good to add an explicit include as opposed taking > a chance on it being included from another include. > > thanks, > -- Shuah
