Re: [LTP] Regarding shmat01 syscall test

Jan Stancek
2012-10-24T08:21:01Z

----- Original Message -----
> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp-list@lists.sourceforge.net, "Om Prakash PAL" <omprakash.pal@stericsson.com>
> Sent: Wednesday, 24 October, 2012 9:51:59 AM
> Subject: Re: [LTP] Regarding shmat01 syscall test
>
> On 10/24/2012 03:49 PM, Jan Stancek wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com>
> >> To: "Jan Stancek" <jstancek@redhat.com>
> >> Cc: ltp-list@lists.sourceforge.net, "Om Prakash PAL"
> >> <omprakash.pal@stericsson.com>
> >> Sent: Wednesday, 24 October, 2012 9:03:16 AM
> >> Subject: Re: [LTP] Regarding shmat01 syscall test
> >>
> >> On 10/24/2012 02:43 PM, Jan Stancek wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com>
> >>>> To: "Om Prakash PAL" <omprakash.pal@stericsson.com>
> >>>> Cc: ltp-list@lists.sourceforge.net
> >>>> Sent: Wednesday, 24 October, 2012 2:45:47 AM
> >>>> Subject: Re: [LTP] Regarding shmat01 syscall test
> >>>>
> >>>> On 10/23/2012 06:05 PM, Om Prakash PAL wrote:
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Wanlong Gao [mailto:gaowanlong@cn.fujitsu.com]
> >>>>> Sent: Tuesday, October 23, 2012 3:07 PM
> >>>>> To: Om Prakash PAL
> >>>>> Cc: ltp-list@lists.sourceforge.net
> >>>>> Subject: Re: [LTP] Regarding shmat01 syscall test
> >>>>>
> >>>>> On 10/23/2012 05:24 PM, Om Prakash PAL wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I am working on syscall test: shmat01.c
> >>>>>>
> >>>>>> I have some confusion:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> In setup() : it is allocating shared memory by shmget() and
> >>>>>> then
> >>>>>> attaching by shmat() and after that detaching the attached
> >>>>>> address (i.e. shmdt())
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> if (shmdt((const void *)base_addr) == -1) {
> >>>>>>
> >>>>>> tst_brkm(TBROK, cleanup, "Couldn't detach
> >>>>>> shared
> >>>>>> memory");
> >>>>>>
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> And again in main function it is using same "base_addr" as
> >>>>>> attaching address,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> addr = shmat(*(TC[i].shmid), base_addr+TC[i].offset,
> >>>>>>
> >>>>>> TC[i].flags);
> >>>>>>
> >>>>>> how can we ensure(100%) that base_addr (virtual) will be free
> >>>>>> till
> >>>>>> this point for attaching?.
> >>>>>
> >>>>> Maybe we can't, but I didn't see any fail on this. Did you see
> >>>>> any
> >>>>> testing failure here?
> >>>>>
> >>>>> Yes, I got some failure and the reason of failure is : the
> >>>>> address
> >>>>> at which we want to attach is busy.
> >>>>
> >>>> OK, please feel free to send a patch, or can you tell us how to
> >>>> reproduce it?
> >>>
> >>> I recall I could reproduce it, if I added single printf:
> >>> http://article.gmane.org/gmane.linux.ltp/16480
> >>
> >> Do you get a solution? Send out a patch?
> >
> > No, I haven't send any patch.
> >
> > About solution:
> > I'm thinking, that instead of probing with shmat, we can mmap large
> > chunk of memory,
> > and then set base_addr somewhere in the middle and unmap the chunk.
> > That is, using address that get_unmapped_area() is unlikely to
> > pick.
>
> This idea seems good, bug how can you decide the size of this "chunk
> of memory"?

Good question. How about starting with some large value, say 512M,
and keep dividing by 2 until mmap succeeds?

Regards,
Jan

>
> Thanks,
> Wanlong Gao
>
> >
> > Regards,
> > Jan
> >
> >>
> >>
> >> Thanks,
> >> Wanlong Gao
> >>
> >>>
> >>> Regards,
> >>> Jan
> >>>
> >>
> >>
> >