From: Wanlong Gao <gaowanlong@cn.fujitsu.com>
To: Jan Stancek <jstancek@redhat.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] Regarding shmat01 syscall test
Date: Fri, 26 Oct 2012 09:45:31 +0800 [thread overview]
Message-ID: <5089EB3B.2020001@cn.fujitsu.com> (raw)
In-Reply-To: <765493123.5437601.1351066849731.JavaMail.root@redhat.com>
On 10/24/2012 04:20 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: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?
So, can you send out a patch to see if others have an objection?
Thanks,
Wanlong Gao
>
> Regards,
> Jan
>
>>
>> Thanks,
>> Wanlong Gao
>>
>>>
>>> Regards,
>>> Jan
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Wanlong Gao
>>>>
>>>>>
>>>>> Regards,
>>>>> Jan
>>>>>
>>>>
>>>>
>>>
>>
>>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2012-10-26 1:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 9:24 [LTP] Regarding shmat01 syscall test Om Prakash PAL
2012-10-23 9:37 ` Wanlong Gao
2012-10-23 10:05 ` Om Prakash PAL
2012-10-24 0:45 ` Wanlong Gao
2012-10-24 6:43 ` Jan Stancek
2012-10-24 7:03 ` Wanlong Gao
2012-10-24 7:49 ` Jan Stancek
2012-10-24 7:51 ` Wanlong Gao
2012-10-24 8:20 ` Jan Stancek
2012-10-26 1:45 ` Wanlong Gao [this message]
2012-10-26 8:01 ` Jan Stancek
2012-10-26 8:03 ` Wanlong Gao
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=5089EB3B.2020001@cn.fujitsu.com \
--to=gaowanlong@cn.fujitsu.com \
--cc=jstancek@redhat.com \
--cc=ltp-list@lists.sourceforge.net \
/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