From: xuyang2018.jy@fujitsu.com <xuyang2018.jy@fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] shmget03: fix test when some shm segments already exist
Date: Thu, 8 Jul 2021 02:24:10 +0000 [thread overview]
Message-ID: <60E661ED.7000305@fujitsu.com> (raw)
In-Reply-To: <60E52E00.8020105@fujitsu.com>
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
>
next prev parent reply other threads:[~2021-07-08 2:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2021-07-08 8:27 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60E661ED.7000305@fujitsu.com \
--to=xuyang2018.jy@fujitsu.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox