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 <[email protected]>
---
changes since v1:
-Used TASK_COMM_LEN instead of using numerical value 16.
---
tools/testing/selftests/prctl/Makefile | 2 +-
.../selftests/prctl/set-process-name.c | 62 +++++++++++++++++++
2 files changed, 63 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/prctl/set-process-name.c
diff --git a/tools/testing/selftests/prctl/Makefile b/tools/testing/selftests/prctl/Makefile
index c058b81ee..cfc35d29f 100644
--- a/tools/testing/selftests/prctl/Makefile
+++ b/tools/testing/selftests/prctl/Makefile
@@ -5,7 +5,7 @@ ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
ifeq ($(ARCH),x86)
TEST_PROGS := disable-tsc-ctxt-sw-stress-test disable-tsc-on-off-stress-test \
- disable-tsc-test set-anon-vma-name-test
+ disable-tsc-test set-anon-vma-name-test set-process-name
all: $(TEST_PROGS)
include ../lib.mk
diff --git a/tools/testing/selftests/prctl/set-process-name.c b/tools/testing/selftests/prctl/set-process-name.c
new file mode 100644
index 000000000..3bc5e0e09
--- /dev/null
+++ b/tools/testing/selftests/prctl/set-process-name.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This test covers the PR_SET_NAME functionality of prctl calls
+ */
+
+#include <errno.h>
+#include <sys/prctl.h>
+#include <string.h>
+
+#include "../kselftest_harness.h"
+
+#define CHANGE_NAME "changename"
+#define EMPTY_NAME ""
+#define TASK_COMM_LEN 16
+
+int set_name(char *name)
+{
+ int res;
+
+ res = prctl(PR_SET_NAME, name, NULL, NULL, NULL);
+
+ if (res < 0)
+ return -errno;
+ return res;
+}
+
+int check_is_name_correct(char *check_name)
+{
+ char name[TASK_COMM_LEN];
+ int res;
+
+ res = prctl(PR_GET_NAME, name, NULL, NULL, NULL);
+
+ if (res < 0)
+ return -errno;
+
+ return !strcmp(name, check_name);
+}
+
+int check_null_pointer(char *check_name)
+{
+ char *name = NULL;
+ int res;
+
+ res = prctl(PR_GET_NAME, name, NULL, NULL, NULL);
+
+ return res;
+}
+
+TEST(rename_process) {
+
+ EXPECT_GE(set_name(CHANGE_NAME), 0);
+ EXPECT_TRUE(check_is_name_correct(CHANGE_NAME));
+
+ EXPECT_GE(set_name(EMPTY_NAME), 0);
+ EXPECT_TRUE(check_is_name_correct(EMPTY_NAME));
+
+ EXPECT_GE(set_name(CHANGE_NAME), 0);
+ EXPECT_LT(check_null_pointer(CHANGE_NAME), 0);
+}
+
+TEST_HARNESS_MAIN
--
2.34.1
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 <[email protected]>
>
> ---
> 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
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 <[email protected]> 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 <[email protected]>
> >
> > ---
> > 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
On 6/10/23 07:01, Osama Muhammad wrote:
> 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
>
The best source is Linux mainline.
Take a look at test files that include linux/sched.h
arm64/abi/tpidr2.c is one of them.
Did you install headers before compiling the test?
make headers_install
thanks,
-- Shuah
Hi,
Yes, I did install the latest kernel headers and TASK_COMM_LEN is not
accessible in userspace.
I looked into the test which uses TASK_COMM_LEN but the test defines
it in its own header file.
Example: https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/progs/pyperf.h#L13
TASK_COMM_LEN is defined in include/linux/sched.h, but this header
file is not exposed to userspace.
TASK_COMM_LEN is not defined in /include/uapi/linux/sched.h which is
exposed to userspace kernel headers.
Please find the link to the header file exposed to user space :-
-https://elixir.bootlin.com/linux/v5.15.116/source/include/uapi/linux/sched.h
As for arm64/abi/tpidr2.c It includes linux/sched.h which will be
/include/uapi/linux/sched.h because the user space program is
including it.
So it also cannot use TASK_COMM_LEN directly.
Regards,
Osama
On Tue, 13 Jun 2023 at 02:56, Shuah Khan <[email protected]> wrote:
>
> On 6/10/23 07:01, Osama Muhammad wrote:
> > 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
> >
>
> The best source is Linux mainline.
>
> Take a look at test files that include linux/sched.h
>
> arm64/abi/tpidr2.c is one of them.
>
> Did you install headers before compiling the test?
> make headers_install
>
> thanks,
> -- Shuah
>
>
Hi Shuah,
Any feedback on this patch?.
Thanks,
Osama
On Sat, 17 Jun 2023 at 18:01, Osama Muhammad <[email protected]> wrote:
>
> Hi,
>
> Yes, I did install the latest kernel headers and TASK_COMM_LEN is not
> accessible in userspace.
>
> I looked into the test which uses TASK_COMM_LEN but the test defines
> it in its own header file.
>
> Example: https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/progs/pyperf.h#L13
>
> TASK_COMM_LEN is defined in include/linux/sched.h, but this header
> file is not exposed to userspace.
>
> TASK_COMM_LEN is not defined in /include/uapi/linux/sched.h which is
> exposed to userspace kernel headers.
> Please find the link to the header file exposed to user space :-
> -https://elixir.bootlin.com/linux/v5.15.116/source/include/uapi/linux/sched.h
>
> As for arm64/abi/tpidr2.c It includes linux/sched.h which will be
> /include/uapi/linux/sched.h because the user space program is
> including it.
> So it also cannot use TASK_COMM_LEN directly.
>
> Regards,
> Osama
>
> On Tue, 13 Jun 2023 at 02:56, Shuah Khan <[email protected]> wrote:
> >
> > On 6/10/23 07:01, Osama Muhammad wrote:
> > > 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
> > >
> >
> > The best source is Linux mainline.
> >
> > Take a look at test files that include linux/sched.h
> >
> > arm64/abi/tpidr2.c is one of them.
> >
> > Did you install headers before compiling the test?
> > make headers_install
> >
> > thanks,
> > -- Shuah
> >
> >
On 6/10/23 2:43 AM, Shuah Khan 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 <[email protected]>
>>
>> ---
>> 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.
TASK_COMM_LEN is defined in include/linux/sched.h. It is only to be used by
the kernel.
If we look at include/uapi/linux/sched.h, TASK_COMM_LEN isn't defined. So
this test looks good to me.
>
> thanks,
> -- Shuah
--
BR,
Muhammad Usama Anjum
Hi,
Thank you for the patch. This patch cleanly applies on next-20230627.
Unrelated to this patch:
I'm not sure if this patch was written against linux next. Always try to
send patches against latest next tag from following repo:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
On 6/26/23 11:36 PM, Osama Muhammad wrote:
> Hi Shuah,
>
> Any feedback on this patch?.
>
> Thanks,
> Osama
>
>
> On Sat, 17 Jun 2023 at 18:01, Osama Muhammad <[email protected]> wrote:
>>
>> Hi,
>>
>> Yes, I did install the latest kernel headers and TASK_COMM_LEN is not
>> accessible in userspace.
>>
>> I looked into the test which uses TASK_COMM_LEN but the test defines
>> it in its own header file.
>>
>> Example: https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/progs/pyperf.h#L13
>>
>> TASK_COMM_LEN is defined in include/linux/sched.h, but this header
>> file is not exposed to userspace.
>>
>> TASK_COMM_LEN is not defined in /include/uapi/linux/sched.h which is
>> exposed to userspace kernel headers.
>> Please find the link to the header file exposed to user space :-
>> -https://elixir.bootlin.com/linux/v5.15.116/source/include/uapi/linux/sched.h
>>
>> As for arm64/abi/tpidr2.c It includes linux/sched.h which will be
>> /include/uapi/linux/sched.h because the user space program is
>> including it.
>> So it also cannot use TASK_COMM_LEN directly.
>>
>> Regards,
>> Osama
>>
>> On Tue, 13 Jun 2023 at 02:56, Shuah Khan <[email protected]> wrote:
>>>
>>> On 6/10/23 07:01, Osama Muhammad wrote:
>>>> 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
>>>>
>>>
>>> The best source is Linux mainline.
>>>
>>> Take a look at test files that include linux/sched.h
>>>
>>> arm64/abi/tpidr2.c is one of them.
>>>
>>> Did you install headers before compiling the test?
>>> make headers_install
>>>
>>> thanks,
>>> -- Shuah
>>>
>>>
--
BR,
Muhammad Usama Anjum
Unrelated to this patch:
You can build the user header files by running `make headers` in a kernel
repository to process the kernel header files. They are generated in
<kernel_source>/include/uapi Then run `make -C
tools/testing/selftests/prctl` to build the test etc.
On 6/7/23 8:36 PM, 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 <[email protected]>
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Tested-by: Muhammad Usama Anjum <[email protected]>
>
> ---
> changes since v1:
> -Used TASK_COMM_LEN instead of using numerical value 16.
>
> ---
> tools/testing/selftests/prctl/Makefile | 2 +-
> .../selftests/prctl/set-process-name.c | 62 +++++++++++++++++++
> 2 files changed, 63 insertions(+), 1 deletion(-)
> create mode 100644 tools/testing/selftests/prctl/set-process-name.c
>
> diff --git a/tools/testing/selftests/prctl/Makefile b/tools/testing/selftests/prctl/Makefile
> index c058b81ee..cfc35d29f 100644
> --- a/tools/testing/selftests/prctl/Makefile
> +++ b/tools/testing/selftests/prctl/Makefile
> @@ -5,7 +5,7 @@ ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
>
> ifeq ($(ARCH),x86)
> TEST_PROGS := disable-tsc-ctxt-sw-stress-test disable-tsc-on-off-stress-test \
> - disable-tsc-test set-anon-vma-name-test
> + disable-tsc-test set-anon-vma-name-test set-process-name
> all: $(TEST_PROGS)
>
> include ../lib.mk
> diff --git a/tools/testing/selftests/prctl/set-process-name.c b/tools/testing/selftests/prctl/set-process-name.c
> new file mode 100644
> index 000000000..3bc5e0e09
> --- /dev/null
> +++ b/tools/testing/selftests/prctl/set-process-name.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * This test covers the PR_SET_NAME functionality of prctl calls
> + */
> +
> +#include <errno.h>
> +#include <sys/prctl.h>
> +#include <string.h>
> +
> +#include "../kselftest_harness.h"
> +
> +#define CHANGE_NAME "changename"
> +#define EMPTY_NAME ""
> +#define TASK_COMM_LEN 16
> +
> +int set_name(char *name)
> +{
> + int res;
> +
> + res = prctl(PR_SET_NAME, name, NULL, NULL, NULL);
> +
> + if (res < 0)
> + return -errno;
> + return res;
> +}
> +
> +int check_is_name_correct(char *check_name)
> +{
> + char name[TASK_COMM_LEN];
> + int res;
> +
> + res = prctl(PR_GET_NAME, name, NULL, NULL, NULL);
> +
> + if (res < 0)
> + return -errno;
> +
> + return !strcmp(name, check_name);
> +}
> +
> +int check_null_pointer(char *check_name)
> +{
> + char *name = NULL;
> + int res;
> +
> + res = prctl(PR_GET_NAME, name, NULL, NULL, NULL);
> +
> + return res;
> +}
> +
> +TEST(rename_process) {
> +
> + EXPECT_GE(set_name(CHANGE_NAME), 0);
> + EXPECT_TRUE(check_is_name_correct(CHANGE_NAME));
> +
> + EXPECT_GE(set_name(EMPTY_NAME), 0);
> + EXPECT_TRUE(check_is_name_correct(EMPTY_NAME));
> +
> + EXPECT_GE(set_name(CHANGE_NAME), 0);
> + EXPECT_LT(check_null_pointer(CHANGE_NAME), 0);
> +}
> +
> +TEST_HARNESS_MAIN
--
BR,
Muhammad Usama Anjum
On 6/26/23 12:36, Osama Muhammad wrote:
> Hi Shuah,
>
> Any feedback on this patch?.
>
> Thanks,
> Osama
>
>
Please don't top post when you are responding on kernel
mailing lists. It gets very difficult to follow the
comments in the email thread.
> On Sat, 17 Jun 2023 at 18:01, Osama Muhammad <[email protected]> wrote:
>>
>> Hi,
>>
>> Yes, I did install the latest kernel headers and TASK_COMM_LEN is not
>> accessible in userspace.
>>
>> I looked into the test which uses TASK_COMM_LEN but the test defines
>> it in its own header file.
>>
>> Example: https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/progs/pyperf.h#L13
bfp test does things differently because its dependencies
on run-time environment.
>>
>> TASK_COMM_LEN is defined in include/linux/sched.h, but this header
>> file is not exposed to userspace.
Correct. you can include linux/sched.h like other tests do
Take a look at tools/testing/selftests/clone3
thanks,
-- Shuah
On 7/14/23 10:21, Shuah Khan wrote:
> On 6/26/23 12:36, Osama Muhammad wrote:
>> Hi Shuah,
>>
>> Any feedback on this patch?.
>>
>> Thanks,
>> Osama
>>
>>
>
> Please don't top post when you are responding on kernel
> mailing lists. It gets very difficult to follow the
> comments in the email thread.
>
>> On Sat, 17 Jun 2023 at 18:01, Osama Muhammad <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> Yes, I did install the latest kernel headers and TASK_COMM_LEN is not
>>> accessible in userspace.
>>>
>>> I looked into the test which uses TASK_COMM_LEN but the test defines
>>> it in its own header file.
>>>
>>> Example: https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/progs/pyperf.h#L13
>
> bfp test does things differently because its dependencies
> on run-time environment.
>
>>>
>>> TASK_COMM_LEN is defined in include/linux/sched.h, but this header
>>> file is not exposed to userspace.
>
> Correct. you can include linux/sched.h like other tests do
> Take a look at tools/testing/selftests/clone3
>
You are right about TASK_COMM_LEN not visible to user-space.
This patch has been applied to linux-kselftest next for 6.6-rc1
thanks,
-- Shuah