* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
@ 2021-07-06 10:57 Alexey Kodanev
2021-07-06 12:49 ` Li Wang
0 siblings, 1 reply; 21+ messages in thread
From: Alexey Kodanev @ 2021-07-06 10:57 UTC (permalink / raw)
To: ltp
It's unlikely, but still possible that some of them could be
created during the test as well, so the patch only checks
errno.
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
---
testcases/kernel/syscalls/ipc/shmget/shmget03.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/testcases/kernel/syscalls/ipc/shmget/shmget03.c b/testcases/kernel/syscalls/ipc/shmget/shmget03.c
index efbc465e1..6796efc91 100644
--- a/testcases/kernel/syscalls/ipc/shmget/shmget03.c
+++ b/testcases/kernel/syscalls/ipc/shmget/shmget03.c
@@ -42,13 +42,17 @@ static void setup(void)
queues = SAFE_MALLOC(maxshms * sizeof(int));
for (num = 0; num < maxshms; num++) {
res = shmget(shmkey + num, SHM_SIZE, IPC_CREAT | IPC_EXCL | SHM_RW);
- if (res == -1)
- tst_brk(TBROK | TERRNO, "shmget failed unexpectedly");
+ if (res == -1) {
+ if (errno == ENOSPC)
+ break;
+ tst_brk(TBROK | TERRNO,
+ "shmget failed unexpectedly, num %d", num);
+ }
queues[queue_cnt++] = res;
}
- tst_res(TINFO, "The maximum number of memory segments (%d) has been reached",
- maxshms);
+ tst_res(TINFO, "The max number of memory segments (%d) has been reached, used by test %d",
+ maxshms, queue_cnt);
}
static void cleanup(void)
--
2.25.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-06 10:57 [LTP] [PATCH] shmget03: fix test when some shm segments already exist Alexey Kodanev
@ 2021-07-06 12:49 ` Li Wang
2021-07-06 13:43 ` Alexey Kodanev
0 siblings, 1 reply; 21+ messages in thread
From: Li Wang @ 2021-07-06 12:49 UTC (permalink / raw)
To: ltp
Hi Alexey,
On Tue, Jul 6, 2021 at 6:59 PM Alexey Kodanev <aleksei.kodanev@bell-sw.com>
wrote:
> It's unlikely, but still possible that some of them could be
> created during the test as well, so the patch only checks
> errno.
>
Thanks for fixing this, seems the msgget03 has this problem as well.
https://github.com/linux-test-project/ltp/issues/842
> Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
>
Reviewed-by: Li Wang <liwang@redhat.com>
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210706/d67fbe02/attachment.htm>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-06 12:49 ` Li Wang
@ 2021-07-06 13:43 ` Alexey Kodanev
2021-07-06 14:18 ` Alexey Kodanev
0 siblings, 1 reply; 21+ messages in thread
From: Alexey Kodanev @ 2021-07-06 13:43 UTC (permalink / raw)
To: ltp
Hi Li,
On 06.07.2021 15:49, Li Wang wrote:
> Hi Alexey,
>
> On Tue, Jul 6, 2021 at 6:59 PM Alexey Kodanev <aleksei.kodanev@bell-sw.com <mailto:aleksei.kodanev@bell-sw.com>> wrote:
>
> It's unlikely, but still possible that some of them could be
> created during the test as well, so the patch only checks
> errno.
>
>
> Thanks for fixing this, seems the msgget03 has this problem as well.
> https://github.com/linux-test-project/ltp/issues/842 <https://github.com/linux-test-project/ltp/issues/842>
Yes, it is the same, it can be easily reproduced:
$ ./msgget03
tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
msgget03.c:50: TINFO: The maximum number of message queues (32000) reached
msgget03.c:29: TPASS: msgget(1627491660, 1536) : ENOSPC (28)
$ ipcmk -Q
Message queue id: 32768
$ ./msgget03
tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
msgget03.c:46: TBROK: msgget failed unexpectedly: ENOSPC (28)
We can fix it similarly.
>
>
> Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com <mailto:aleksei.kodanev@bell-sw.com>>
>
> ?Reviewed-by: Li Wang <liwang@redhat.com <mailto:liwang@redhat.com>>
>
> --
> Regards,
> Li Wang
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-06 13:43 ` Alexey Kodanev
@ 2021-07-06 14:18 ` Alexey Kodanev
2021-07-07 1:26 ` Li Wang
2021-07-07 1:50 ` xuyang2018.jy
0 siblings, 2 replies; 21+ messages in thread
From: Alexey Kodanev @ 2021-07-06 14:18 UTC (permalink / raw)
To: ltp
On 06.07.2021 16:43, Alexey Kodanev wrote:
> Hi Li,
> On 06.07.2021 15:49, Li Wang wrote:
>> Hi Alexey,
>>
>> On Tue, Jul 6, 2021 at 6:59 PM Alexey Kodanev <aleksei.kodanev@bell-sw.com <mailto:aleksei.kodanev@bell-sw.com>> wrote:
>>
>> It's unlikely, but still possible that some of them could be
>> created during the test as well, so the patch only checks
>> errno.
>>
>>
>> Thanks for fixing this, seems the msgget03 has this problem as well.
>> https://github.com/linux-test-project/ltp/issues/842 <https://github.com/linux-test-project/ltp/issues/842>
>
> Yes, it is the same, it can be easily reproduced:
>
> $ ./msgget03
> tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
> msgget03.c:50: TINFO: The maximum number of message queues (32000) reached
> msgget03.c:29: TPASS: msgget(1627491660, 1536) : ENOSPC (28)
>
> $ ipcmk -Q
> Message queue id: 32768
>
> $ ./msgget03
> tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
> msgget03.c:46: TBROK: msgget failed unexpectedly: ENOSPC (28)
>
>
> We can fix it similarly.
>
It's also possible that some resources will be freed during
the tests... perhaps, moving the loop to verify_*() is the
better option?
diff --git a/testcases/kernel/syscalls/ipc/msgget/msgget03.c b/testcases/kernel/syscalls/ipc/msgget/msgget03.c
index 76cf82cd3..5b760b1d6 100644
--- a/testcases/kernel/syscalls/ipc/msgget/msgget03.c
+++ b/testcases/kernel/syscalls/ipc/msgget/msgget03.c
@@ -26,29 +26,29 @@ static key_t msgkey;
static void verify_msgget(void)
{
- TST_EXP_FAIL2(msgget(msgkey + maxmsgs, IPC_CREAT | IPC_EXCL), ENOSPC,
- "msgget(%i, %i)", msgkey + maxmsgs, IPC_CREAT | IPC_EXCL);
+ int num, res;
+
+ for (num = 0; num <= maxmsgs; ++num) {
+ res = msgget(msgkey + num, IPC_CREAT | IPC_EXCL);
+ if (res == -1) {
+ if (errno == ENOSPC) {
+ tst_res(TPASS | TERRNO, "created queues %d", num);
+ return;
+ }
+ tst_brk(TFAIL | TERRNO,
+ "msgget failed unexpectedly, num %d", num);
+ }
+ queues[queue_cnt++] = res;
+ }
}
...
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-06 14:18 ` Alexey Kodanev
@ 2021-07-07 1:26 ` Li Wang
2021-07-07 1:59 ` xuyang2018.jy
2021-07-07 1:50 ` xuyang2018.jy
1 sibling, 1 reply; 21+ messages in thread
From: Li Wang @ 2021-07-07 1:26 UTC (permalink / raw)
To: ltp
Alexey Kodanev <aleksei.kodanev@bell-sw.com> wrote:
>
> It's also possible that some resources will be freed during
> the tests... perhaps, moving the loop to verify_*() is the
> better option?
>
Yes, good point, that would be more precise for ENOSPC testing.
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210707/89e22f1e/attachment.htm>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-06 14:18 ` Alexey Kodanev
2021-07-07 1:26 ` Li Wang
@ 2021-07-07 1:50 ` xuyang2018.jy
2021-07-07 2:21 ` Li Wang
1 sibling, 1 reply; 21+ messages in thread
From: xuyang2018.jy @ 2021-07-07 1:50 UTC (permalink / raw)
To: ltp
Hi Alexey,Li
> On 06.07.2021 16:43, Alexey Kodanev wrote:
>> Hi Li,
>> On 06.07.2021 15:49, Li Wang wrote:
>>> Hi Alexey,
>>>
>>> On Tue, Jul 6, 2021 at 6:59 PM Alexey Kodanev<aleksei.kodanev@bell-sw.com<mailto:aleksei.kodanev@bell-sw.com>> wrote:
>>>
>>> It's unlikely, but still possible that some of them could be
>>> created during the test as well, so the patch only checks
>>> errno.
>>>
>>>
>>> Thanks for fixing this, seems the msgget03 has this problem as well.
>>> https://github.com/linux-test-project/ltp/issues/842<https://github.com/linux-test-project/ltp/issues/842>
>>
>> Yes, it is the same, it can be easily reproduced:
>>
>> $ ./msgget03
>> tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
>> msgget03.c:50: TINFO: The maximum number of message queues (32000) reached
>> msgget03.c:29: TPASS: msgget(1627491660, 1536) : ENOSPC (28)
>>
>> $ ipcmk -Q
>> Message queue id: 32768
>>
>> $ ./msgget03
>> tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
>> msgget03.c:46: TBROK: msgget failed unexpectedly: ENOSPC (28)
>>
>>
>> We can fix it similarly.
>>
>
> It's also possible that some resources will be freed during
> the tests... perhaps, moving the loop to verify_*() is the
> better option?
>
> diff --git a/testcases/kernel/syscalls/ipc/msgget/msgget03.c b/testcases/kernel/syscalls/ipc/msgget/msgget03.c
> index 76cf82cd3..5b760b1d6 100644
> --- a/testcases/kernel/syscalls/ipc/msgget/msgget03.c
> +++ b/testcases/kernel/syscalls/ipc/msgget/msgget03.c
> @@ -26,29 +26,29 @@ static key_t msgkey;
>
> static void verify_msgget(void)
> {
> - TST_EXP_FAIL2(msgget(msgkey + maxmsgs, IPC_CREAT | IPC_EXCL), ENOSPC,
> - "msgget(%i, %i)", msgkey + maxmsgs, IPC_CREAT | IPC_EXCL);
> + int num, res;
> +
> + for (num = 0; num<= maxmsgs; ++num) {
> + res = msgget(msgkey + num, IPC_CREAT | IPC_EXCL);
> + if (res == -1) {
> + if (errno == ENOSPC) {
> + tst_res(TPASS | TERRNO, "created queues %d", num);
> + return;
> + }
> + tst_brk(TFAIL | TERRNO,
> + "msgget failed unexpectedly, num %d", num);
> + }
> + queues[queue_cnt++] = res;
> + }
> }
If we use this old format, then we can not ensure whether we trigger the
ENOSPC errer correctly when reaching the expected nums.
So to avoid the existed memory segments error, I think we should alter
get_used_queus api to count the existed memory segments by adding a
file argument.
ps:get_used_queus seems never be used.
code maybe as below:
diff --git a/include/libnewipc.h b/include/libnewipc.h
index 075364f85..76de70fee 100644
--- a/include/libnewipc.h
+++ b/include/libnewipc.h
@@ -49,9 +49,9 @@ key_t getipckey(const char *file, const int lineno);
#define GETIPCKEY() \
getipckey(__FILE__, __LINE__)
-int get_used_queues(const char *file, const int lineno);
-#define GET_USED_QUEUES() \
- get_used_queues(__FILE__, __LINE__)
+int get_used_queues(const char *file, const int lineno, const char
*proc_file);
+#define GET_USED_QUEUES(proc_file) \
+ get_used_queues(__FILE__, __LINE__, proc_file)
void *probe_free_addr(const char *file, const int lineno);
#define PROBE_FREE_ADDR() \
diff --git a/libs/libltpnewipc/libnewipc.c b/libs/libltpnewipc/libnewipc.c
index d0974bbe0..533a21140 100644
--- a/libs/libltpnewipc/libnewipc.c
+++ b/libs/libltpnewipc/libnewipc.c
@@ -48,13 +48,13 @@ key_t getipckey(const char *file, const int lineno)
return key;
}
-int get_used_queues(const char *file, const int lineno)
+int get_used_queues(const char *file, const int lineno, const char
*proc_file )
{
FILE *fp;
int used_queues = -1;
char buf[BUFSIZE];
- fp = safe_fopen(file, lineno, NULL, "/proc/sysvipc/msg", "r");
+ fp = safe_fopen(file, lineno, NULL, proc_file, "r");
while (fgets(buf, BUFSIZE, fp) != NULL)
used_queues++;
@@ -62,8 +62,8 @@ int get_used_queues(const char *file, const int lineno)
fclose(fp);
if (used_queues < 0) {
- tst_brk(TBROK, "can't read /proc/sysvipc/msg to get "
- "used message queues@%s:%d", file, lineno);
+ tst_brk(TBROK, "can't read %s to get used message queues "
+ "at %s:%d", proc_file, file, lineno);
}
--- a/testcases/kernel/syscalls/ipc/shmget/shmget03.c
+++ b/testcases/kernel/syscalls/ipc/shmget/shmget03.c
@@ -22,7 +22,7 @@
#include "libnewipc.h"
static int *queues;
-static int maxshms, queue_cnt;
+static int maxshms, queue_cnt, existed_cnt;
static key_t shmkey;
static void verify_shmget(void)
@@ -36,11 +36,14 @@ static void setup(void)
int res, num;
shmkey = GETIPCKEY();
+ existed_cnt = GET_USED_QUEUES("/proc/sysvipc/shm");
+ tst_res(TINFO, "Current environment has %d existed shared emory
segments",
+ existed_cnt);
SAFE_FILE_SCANF("/proc/sys/kernel/shmmni", "%i", &maxshms);
- queues = SAFE_MALLOC(maxshms * sizeof(int));
- for (num = 0; num < maxshms; num++) {
+ queues = SAFE_MALLOC((maxshms - existed_cnt) * sizeof(int));
+ for (num = 0; num < maxshms - existed_cnt; num++) {
res = shmget(shmkey + num, SHM_SIZE, IPC_CREAT |
IPC_EXCL | SHM_RW);
if (res == -1)
tst_brk(TBROK | TERRNO, "shmget failed
unexpectedly");
Best Regards
Yang Xu
> ...
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-07 1:26 ` Li Wang
@ 2021-07-07 1:59 ` xuyang2018.jy
2021-07-07 14:12 ` Alexey Kodanev
2021-07-08 11:02 ` Petr Vorel
0 siblings, 2 replies; 21+ messages in thread
From: xuyang2018.jy @ 2021-07-07 1:59 UTC (permalink / raw)
To: ltp
Hi Li, Alexey
> Alexey Kodanev <aleksei.kodanev@bell-sw.com
> <mailto:aleksei.kodanev@bell-sw.com>> wrote:
>
>
> It's also possible that some resources will be freed during
> the tests... perhaps, moving the loop to verify_*() is the
> better option?
>
>
> Yes, good point, that would be more precise for ENOSPC testing.
AFAIK, ltp doesn't support parallel test now. I think parallel test
maybe a future plan that is why we use docparase to collect each case's
used resources(so we can convert many groups, like pid, memory, disk
space..., then we can run pid group and memory groups test case parallelly).
This is my understanding. If wrong, please correct me.
Best Regards
Yang Xu
>
>
> --
> Regards,
> Li Wang
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-07 1:50 ` xuyang2018.jy
@ 2021-07-07 2:21 ` Li Wang
2021-07-07 4:30 ` xuyang2018.jy
0 siblings, 1 reply; 21+ messages in thread
From: Li Wang @ 2021-07-07 2:21 UTC (permalink / raw)
To: ltp
Hi Xu,
xuyang2018.jy@fujitsu.com <xuyang2018.jy@fujitsu.com> wrote:
> If we use this old format, then we can not ensure whether we trigger the
> ENOSPC errer correctly when reaching the expected nums.
>
> So to avoid the existed memory segments error, I think we should alter
> get_used_queus api to count the existed memory segments by adding a
> file argument.
>
Just as Alex pointed, if there are some resources be freed after invoking
get_used_queus, then the value of existed_cnt will be imprecise, how do
you think that affects the test result?
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210707/4126b872/attachment.htm>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-07 2:21 ` Li Wang
@ 2021-07-07 4:30 ` xuyang2018.jy
2021-07-08 2:24 ` xuyang2018.jy
0 siblings, 1 reply; 21+ messages in thread
From: xuyang2018.jy @ 2021-07-07 4:30 UTC (permalink / raw)
To: ltp
Hi Li
> Hi Xu,
>
> xuyang2018.jy@fujitsu.com <mailto:xuyang2018.jy@fujitsu.com>
> <xuyang2018.jy@fujitsu.com <mailto:xuyang2018.jy@fujitsu.com>> wrote:
>
> If we use this old format, then we can not ensure whether we trigger
> the
> ENOSPC errer correctly when reaching the expected nums.
>
> So to avoid the existed memory segments error, I think we should alter
> get_used_queus api to count the existed memory segments by adding a
> file argument.
>
>
> Just as Alex pointed, if there are some resources be freedafter invoking
> get_used_queus, then the value of existed_cntwill be imprecise, how do
> you think that affects the test result?
We can move this count api and the create phase into verify* function,
but still exist the chance to free resource after invoking get_used_queues.
We can't avoid it because /proc/sys/kernel/shmmni is designed for all
user instead of the calling process.
I think it is common in ltp because user also can set a different value
after we use ltp api to set proc value.
But if we only use for loop to trigger the ENOSPC error, it goes against
the test's aim(see old shmget03.c, it also does the same thing as I do,
it doesn't trigger error because it uses a big value than default 4096).
Since this case only wastes a little time when run, I don't think we
should avoid rare race to give up to test the ENOSPC error when reaching
the expected num.
Also, Let's listen advise from other maintainers.
@Cyril,Petr
Best Regards
Yang Xu
>
>
> --
> Regards,
> Li Wang
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-07 1:59 ` xuyang2018.jy
@ 2021-07-07 14:12 ` Alexey Kodanev
2021-07-08 11:02 ` Petr Vorel
1 sibling, 0 replies; 21+ messages in thread
From: Alexey Kodanev @ 2021-07-07 14:12 UTC (permalink / raw)
To: ltp
On 07.07.2021 04:59, xuyang2018.jy@fujitsu.com wrote:
> Hi Li, Alexey
>> Alexey Kodanev <aleksei.kodanev@bell-sw.com
>> <mailto:aleksei.kodanev@bell-sw.com>> wrote:
>>
>>
>> It's also possible that some resources will be freed during
>> the tests... perhaps, moving the loop to verify_*() is the
>> better option?
>>
>>
>> Yes, good point, that would be more precise for ENOSPC testing.
> AFAIK, ltp doesn't support parallel test now. I think parallel test
> maybe a future plan that is why we use docparase to collect each case's
> used resources(so we can convert many groups, like pid, memory, disk
> space..., then we can run pid group and memory groups test case parallelly).
>
> This is my understanding. If wrong, please correct me.
The problem is that these shared resources might be acquired/released
not only by ltp tests. And changing limits in proc is not the same...
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-07 4:30 ` xuyang2018.jy
@ 2021-07-08 2:24 ` xuyang2018.jy
2021-07-08 8:27 ` Li Wang
0 siblings, 1 reply; 21+ messages in thread
From: xuyang2018.jy @ 2021-07-08 2:24 UTC (permalink / raw)
To: ltp
Hi Li
How about using CLONE_NEWIPC to test this, so we can avoid this race
situation.
Best Regards
Yang Xu
> Hi Li
>> Hi Xu,
>>
>> xuyang2018.jy@fujitsu.com<mailto:xuyang2018.jy@fujitsu.com>
>> <xuyang2018.jy@fujitsu.com<mailto:xuyang2018.jy@fujitsu.com>> wrote:
>>
>> If we use this old format, then we can not ensure whether we trigger
>> the
>> ENOSPC errer correctly when reaching the expected nums.
>>
>> So to avoid the existed memory segments error, I think we should alter
>> get_used_queus api to count the existed memory segments by adding a
>> file argument.
>>
>>
>> Just as Alex pointed, if there are some resources be freedafter invoking
>> get_used_queus, then the value of existed_cntwill be imprecise, how do
>> you think that affects the test result?
>
> We can move this count api and the create phase into verify* function,
> but still exist the chance to free resource after invoking get_used_queues.
>
> We can't avoid it because /proc/sys/kernel/shmmni is designed for all
> user instead of the calling process.
>
> I think it is common in ltp because user also can set a different value
> after we use ltp api to set proc value.
>
> But if we only use for loop to trigger the ENOSPC error, it goes against
> the test's aim(see old shmget03.c, it also does the same thing as I do,
> it doesn't trigger error because it uses a big value than default 4096).
>
> Since this case only wastes a little time when run, I don't think we
> should avoid rare race to give up to test the ENOSPC error when reaching
> the expected num.
>
> Also, Let's listen advise from other maintainers.
> @Cyril,Petr
>
> Best Regards
> Yang Xu
>
>>
>>
>> --
>> Regards,
>> Li Wang
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-08 2:24 ` xuyang2018.jy
@ 2021-07-08 8:27 ` Li Wang
0 siblings, 0 replies; 21+ messages in thread
From: Li Wang @ 2021-07-08 8:27 UTC (permalink / raw)
To: ltp
On Thu, Jul 8, 2021 at 10:24 AM xuyang2018.jy@fujitsu.com <
xuyang2018.jy@fujitsu.com> wrote:
> Hi Li
>
> How about using CLONE_NEWIPC to test this, so we can avoid this race
> situation.
>
Maybe yes, but that sounds a bit like a new test.
If let me choose from Alex suggestion or this CLONE_NEWIPC,
I think both are OK, because it just an error return check,
not a big deal.
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210708/ce66ae30/attachment.htm>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-07 1:59 ` xuyang2018.jy
2021-07-07 14:12 ` Alexey Kodanev
@ 2021-07-08 11:02 ` Petr Vorel
2021-07-08 12:02 ` Cyril Hrubis
1 sibling, 1 reply; 21+ messages in thread
From: Petr Vorel @ 2021-07-08 11:02 UTC (permalink / raw)
To: ltp
Hi Xu, all,
> Hi Li, Alexey
> > Alexey Kodanev <aleksei.kodanev@bell-sw.com
> > <mailto:aleksei.kodanev@bell-sw.com>> wrote:
> > It's also possible that some resources will be freed during
> > the tests... perhaps, moving the loop to verify_*() is the
> > better option?
> > Yes, good point, that would be more precise for ENOSPC testing.
> AFAIK, ltp doesn't support parallel test now. I think parallel test
> maybe a future plan that is why we use docparase to collect each case's
> used resources(so we can convert many groups, like pid, memory, disk
> space..., then we can run pid group and memory groups test case parallelly).
Yes, parallel support is not supported atm. Richie and Cyril has done some work
on runltp-ng to support it. Yes, first it's needed to add support in resources
(docparse), see Cyril's old block post [1].
Kind regards,
Petr
[1] https://people.kernel.org/metan/towards-parallel-kernel-test-runs
> This is my understanding. If wrong, please correct me.
> Best Regards
> Yang Xu
> > --
> > Regards,
> > Li Wang
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-08 11:02 ` Petr Vorel
@ 2021-07-08 12:02 ` Cyril Hrubis
2021-07-12 2:31 ` xuyang2018.jy
0 siblings, 1 reply; 21+ messages in thread
From: Cyril Hrubis @ 2021-07-08 12:02 UTC (permalink / raw)
To: ltp
Hi!
> > > Yes, good point, that would be more precise for ENOSPC testing.
> > AFAIK, ltp doesn't support parallel test now. I think parallel test
> > maybe a future plan that is why we use docparase to collect each case's
> > used resources(so we can convert many groups, like pid, memory, disk
> > space..., then we can run pid group and memory groups test case parallelly).
> Yes, parallel support is not supported atm. Richie and Cyril has done some work
> on runltp-ng to support it. Yes, first it's needed to add support in resources
> (docparse), see Cyril's old block post [1].
Besides most of the SHM tests will crash and burn if executed in
parallel. The SysV IPC shares a global namespace and because of that we
can't really write tests without assuming that we are the only one
manipulating them when the test is executed.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-08 12:02 ` Cyril Hrubis
@ 2021-07-12 2:31 ` xuyang2018.jy
2021-07-12 7:46 ` Alexey Kodanev
0 siblings, 1 reply; 21+ messages in thread
From: xuyang2018.jy @ 2021-07-12 2:31 UTC (permalink / raw)
To: ltp
Hi All
> Hi!
>>>> Yes, good point, that would be more precise for ENOSPC testing.
>>> AFAIK, ltp doesn't support parallel test now. I think parallel test
>>> maybe a future plan that is why we use docparase to collect each case's
>>> used resources(so we can convert many groups, like pid, memory, disk
>>> space..., then we can run pid group and memory groups test case parallelly).
>> Yes, parallel support is not supported atm. Richie and Cyril has done some work
>> on runltp-ng to support it. Yes, first it's needed to add support in resources
>> (docparse), see Cyril's old block post [1].
>
> Besides most of the SHM tests will crash and burn if executed in
> parallel. The SysV IPC shares a global namespace and because of that we
> can't really write tests without assuming that we are the only one
> manipulating them when the test is executed.
I guess we should reach a consensus that how to fix this problem
1)use for loop to trigger this error
2)use CLONE_NEWIPC to trigger this error
3)Or we are the only one that use shm and we can add a api to count the
existed_cnt
ps: I don't want to leave this problem too long time.
Best Regards
Yang Xu
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-12 2:31 ` xuyang2018.jy
@ 2021-07-12 7:46 ` Alexey Kodanev
2021-07-12 8:41 ` Petr Vorel
0 siblings, 1 reply; 21+ messages in thread
From: Alexey Kodanev @ 2021-07-12 7:46 UTC (permalink / raw)
To: ltp
On 12.07.2021 05:31, xuyang2018.jy@fujitsu.com wrote:
> Hi All
>> Hi!
>>>>> Yes, good point, that would be more precise for ENOSPC testing.
>>>> AFAIK, ltp doesn't support parallel test now. I think parallel test
>>>> maybe a future plan that is why we use docparase to collect each case's
>>>> used resources(so we can convert many groups, like pid, memory, disk
>>>> space..., then we can run pid group and memory groups test case parallelly).
>>> Yes, parallel support is not supported atm. Richie and Cyril has done some work
>>> on runltp-ng to support it. Yes, first it's needed to add support in resources
>>> (docparse), see Cyril's old block post [1].
>>
>> Besides most of the SHM tests will crash and burn if executed in
>> parallel. The SysV IPC shares a global namespace and because of that we
>> can't really write tests without assuming that we are the only one
>> manipulating them when the test is executed.
> I guess we should reach a consensus that how to fix this problem
> 1)use for loop to trigger this error
> 2)use CLONE_NEWIPC to trigger this error
Perhaps it can be done at the higher level, e.g. in the ltp tests
runner if some tests request it with a newipc flag...
> 3)Or we are the only one that use shm and we can add a api to count the
> existed_cnt
>
> ps: I don't want to leave this problem too long time.
>
> Best Regards
> Yang Xu
>>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-12 7:46 ` Alexey Kodanev
@ 2021-07-12 8:41 ` Petr Vorel
2021-07-12 8:46 ` Alexey Kodanev
0 siblings, 1 reply; 21+ messages in thread
From: Petr Vorel @ 2021-07-12 8:41 UTC (permalink / raw)
To: ltp
> On 12.07.2021 05:31, xuyang2018.jy@fujitsu.com wrote:
> > Hi All
> >> Hi!
> >>>>> Yes, good point, that would be more precise for ENOSPC testing.
> >>>> AFAIK, ltp doesn't support parallel test now. I think parallel test
> >>>> maybe a future plan that is why we use docparase to collect each case's
> >>>> used resources(so we can convert many groups, like pid, memory, disk
> >>>> space..., then we can run pid group and memory groups test case parallelly).
> >>> Yes, parallel support is not supported atm. Richie and Cyril has done some work
> >>> on runltp-ng to support it. Yes, first it's needed to add support in resources
> >>> (docparse), see Cyril's old block post [1].
> >> Besides most of the SHM tests will crash and burn if executed in
> >> parallel. The SysV IPC shares a global namespace and because of that we
> >> can't really write tests without assuming that we are the only one
> >> manipulating them when the test is executed.
> > I guess we should reach a consensus that how to fix this problem
> > 1)use for loop to trigger this error
> > 2)use CLONE_NEWIPC to trigger this error
> Perhaps it can be done at the higher level, e.g. in the ltp tests
> runner if some tests request it with a newipc flag...
Well, we have at least two runners (runltp which uses ltp-pan, runltp-ng) and we
also support running tests without runner, it'd be nice to solve this in LTP
API.
Kind regards,
Petr
> > 3)Or we are the only one that use shm and we can add a api to count the
> > existed_cnt
> > ps: I don't want to leave this problem too long time.
> > Best Regards
> > Yang Xu
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-12 8:41 ` Petr Vorel
@ 2021-07-12 8:46 ` Alexey Kodanev
2021-07-14 9:33 ` Cyril Hrubis
0 siblings, 1 reply; 21+ messages in thread
From: Alexey Kodanev @ 2021-07-12 8:46 UTC (permalink / raw)
To: ltp
On 12.07.2021 11:41, Petr Vorel wrote:
>> On 12.07.2021 05:31, xuyang2018.jy@fujitsu.com wrote:
>>> Hi All
>>>> Hi!
>>>>>>> Yes, good point, that would be more precise for ENOSPC testing.
>>>>>> AFAIK, ltp doesn't support parallel test now. I think parallel test
>>>>>> maybe a future plan that is why we use docparase to collect each case's
>>>>>> used resources(so we can convert many groups, like pid, memory, disk
>>>>>> space..., then we can run pid group and memory groups test case parallelly).
>>>>> Yes, parallel support is not supported atm. Richie and Cyril has done some work
>>>>> on runltp-ng to support it. Yes, first it's needed to add support in resources
>>>>> (docparse), see Cyril's old block post [1].
>
>>>> Besides most of the SHM tests will crash and burn if executed in
>>>> parallel. The SysV IPC shares a global namespace and because of that we
>>>> can't really write tests without assuming that we are the only one
>>>> manipulating them when the test is executed.
>>> I guess we should reach a consensus that how to fix this problem
>>> 1)use for loop to trigger this error
>>> 2)use CLONE_NEWIPC to trigger this error
>
>> Perhaps it can be done at the higher level, e.g. in the ltp tests
>> runner if some tests request it with a newipc flag...
> Well, we have at least two runners (runltp which uses ltp-pan, runltp-ng) and we
> also support running tests without runner, it'd be nice to solve this in LTP
> API.
I didn't mean these runners, I was thinking about fork_testrun() in tst_test.c.
>
> Kind regards,
> Petr
>
>>> 3)Or we are the only one that use shm and we can add a api to count the
>>> existed_cnt
>
>>> ps: I don't want to leave this problem too long time.
>
>>> Best Regards
>>> Yang Xu
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-12 8:46 ` Alexey Kodanev
@ 2021-07-14 9:33 ` Cyril Hrubis
2021-07-14 10:00 ` Petr Vorel
0 siblings, 1 reply; 21+ messages in thread
From: Cyril Hrubis @ 2021-07-14 9:33 UTC (permalink / raw)
To: ltp
Hi!
> >> Perhaps it can be done at the higher level, e.g. in the ltp tests
> >> runner if some tests request it with a newipc flag...
> > Well, we have at least two runners (runltp which uses ltp-pan, runltp-ng) and we
> > also support running tests without runner, it'd be nice to solve this in LTP
> > API.
>
> I didn't mean these runners, I was thinking about fork_testrun() in tst_test.c.
We will need to have some kind of flag that would tell the testrunner
that the test is using/modifying SysV IPC anyways as without namespaces
these tests cannot run in parallel at all.
So I would say that we should:
* Write these tests in a way that they expect that they are the only
process that modifies these resources during the testrun
* Mark all these tests with .sysv_ipc flag in the tst_test structure
* Then we can easily add support for running them in a separate
namespace in the test library
Does that sound reasonable?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-14 9:33 ` Cyril Hrubis
@ 2021-07-14 10:00 ` Petr Vorel
2021-07-14 10:17 ` xuyang2018.jy
0 siblings, 1 reply; 21+ messages in thread
From: Petr Vorel @ 2021-07-14 10:00 UTC (permalink / raw)
To: ltp
Hi,
...
> We will need to have some kind of flag that would tell the testrunner
> that the test is using/modifying SysV IPC anyways as without namespaces
> these tests cannot run in parallel at all.
> So I would say that we should:
> * Write these tests in a way that they expect that they are the only
> process that modifies these resources during the testrun
> * Mark all these tests with .sysv_ipc flag in the tst_test structure
> * Then we can easily add support for running them in a separate
> namespace in the test library
> Does that sound reasonable?
+1
Kind regards,
Petr
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH] shmget03: fix test when some shm segments already exist
2021-07-14 10:00 ` Petr Vorel
@ 2021-07-14 10:17 ` xuyang2018.jy
0 siblings, 0 replies; 21+ messages in thread
From: xuyang2018.jy @ 2021-07-14 10:17 UTC (permalink / raw)
To: ltp
Hi Cyril, Petr
> Hi,
>
> ...
>> We will need to have some kind of flag that would tell the testrunner
>> that the test is using/modifying SysV IPC anyways as without namespaces
>> these tests cannot run in parallel at all.
>
>> So I would say that we should:
>
>> * Write these tests in a way that they expect that they are the only
>> process that modifies these resources during the testrun
>
>> * Mark all these tests with .sysv_ipc flag in the tst_test structure
>
>> * Then we can easily add support for running them in a separate
>> namespace in the test library
>
>> Does that sound reasonable?
> +1
+1
Since now ltp test libary uses fork_testrun, I wonder whether we should
add clone_testrun. So test's setup/test/cleanup function are all in new
namespace.
Maybe we should support two ways for running test cases in
lib/tst_test(fork and clone)?
And we can add clone and flag argument(the value can be
CLONE_NEWIPC/CLONE_NEWNET/CLONENEWPID or more ) in tst_test struct.
ps: Just a initial idea
Best Regards
Yang Xu
> Kind regards,
> Petr
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-07-14 10:17 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-06 10:57 [LTP] [PATCH] shmget03: fix test when some shm segments already exist Alexey Kodanev
2021-07-06 12:49 ` Li Wang
2021-07-06 13:43 ` Alexey Kodanev
2021-07-06 14:18 ` Alexey Kodanev
2021-07-07 1:26 ` Li Wang
2021-07-07 1:59 ` xuyang2018.jy
2021-07-07 14:12 ` Alexey Kodanev
2021-07-08 11:02 ` Petr Vorel
2021-07-08 12:02 ` Cyril Hrubis
2021-07-12 2:31 ` xuyang2018.jy
2021-07-12 7:46 ` Alexey Kodanev
2021-07-12 8:41 ` Petr Vorel
2021-07-12 8:46 ` Alexey Kodanev
2021-07-14 9:33 ` Cyril Hrubis
2021-07-14 10:00 ` Petr Vorel
2021-07-14 10:17 ` xuyang2018.jy
2021-07-07 1:50 ` xuyang2018.jy
2021-07-07 2:21 ` Li Wang
2021-07-07 4:30 ` xuyang2018.jy
2021-07-08 2:24 ` xuyang2018.jy
2021-07-08 8:27 ` Li Wang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.