From mboxrd@z Thu Jan 1 00:00:00 1970 From: xuyang2018.jy@fujitsu.com Date: Thu, 8 Jul 2021 02:24:10 +0000 Subject: [LTP] [PATCH] shmget03: fix test when some shm segments already exist In-Reply-To: <60E52E00.8020105@fujitsu.com> References: <20210706105758.43220-1-aleksei.kodanev@bell-sw.com> <381b8420-3dba-d7c1-027c-e2e2adc719de@bell-sw.com> <60E50890.9040903@fujitsu.com> <60E52E00.8020105@fujitsu.com> Message-ID: <60E661ED.7000305@fujitsu.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it 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 >> > 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 >