[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Alexey Kodanev]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Li Wang]

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>

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Alexey Kodanev]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Alexey Kodanev]

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;
+       }
 }
...

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Li Wang]

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>

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[xuyang2018.jy]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Alexey Kodanev]

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...

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Petr Vorel]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Cyril Hrubis]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[xuyang2018.jy]

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
>

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Alexey Kodanev]

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
>>

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Petr Vorel]

> 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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Alexey Kodanev]

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
> 
> 

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Cyril Hrubis]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Petr Vorel]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[xuyang2018.jy]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[xuyang2018.jy]

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

> ...

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Li Wang]

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>

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[xuyang2018.jy]

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

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[xuyang2018.jy]

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
>

[LTP] [PATCH] shmget03: fix test when some shm segments already exist

[Li Wang]

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>