Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Wanlong Gao <gaowanlong@cn.fujitsu.com>]

On 07/21/2014 05:33 PM, Jan Stancek wrote:
> 
> 
> ----- Original Message -----
>> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com>
>> To: "Jan Stancek" <jstancek@redhat.com>, "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com>
>> Cc: ltp-list@lists.sourceforge.net, "Artem Savkov" <asavkov@redhat.com>
>> Sent: Monday, 21 July, 2014 11:09:47 AM
>> Subject: Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)
>>
>> On 07/21/2014 05:04 PM, Jan Stancek wrote:
>>>
>>>
>>> ----- Original Message -----
>>>>> From: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com>
>>>>> To: ltp-list@lists.sourceforge.net
>>>>> Sent: Tuesday, 15 July, 2014 12:13:49 PM
>>>>> Subject: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for
>>>>> getcwd(2)
>>>>>
>>>>> Note: this test has already been in xfstests generic/028 test case,
>>>>> I just port it to LTP.
>>>>>
>>>>> Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a
>>>>> race
>>>>> condition that causes getcwd(2) to return "/" instead of correct path.
>>>>>     232d2d6 dcache: Translating dentry into pathname without
>>>>>             taking rename_lock
>>>>>
>>>>> And these two kernel commits have fixed this bug:
>>>>>   ede4cebce16f5643c61aedd6d88d9070a1d23a68
>>>>>      prepend_path() needs to reinitialize dentry/vfsmount/mnt on
>>>>>      restarts
>>>>>   f6500801522c61782d4990fa1ad96154cb397cd4
>>>>>      f650080 __dentry_path() fixes
>>>>>
>>>>> This test is to check whether this bug exists in the running kernel,
>>>>> or whether this bug has been fixed.
>>>>>
>>>>> Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
>>> Hi,
>>>
>>> looks good to me.
>>>
>>>>> I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6
>>>>> and 3.16.0-rc4+.
>>>>> RHEL7.0GA has this kernel bug, so this test case fails.
>>> I can confirm this, with note that I've seen it happen only on systems with
>>> 2+ CPUs.
>>
>> If this note is truth, we should judge the nr_cpus in this case to make sure
>> it always
>> gives the right result.
> 
> My observation is that it's at least easier to reproduce on 2+ CPUs:
> 
> # time taskset -c 0 ./getcwd04 
> getcwd04    1  TPASS  :  Bug is not reproduced!
> 
> real	0m5.002s
> user	0m0.506s
> sys	0m4.494s
> 
> # time taskset -c 0,1 ./getcwd04 
> getcwd04    1  TFAIL  :  initial current work directory is /tmp/getg6foNN/testdir, now is /. Bug is reproduced!
> 
> real	0m0.002s
> user	0m0.000s
> sys	0m0.002s
> 
> 
> I'm not sure what you are suggesting we do, other than to make note somewhere.
> 
> It's a test for race condition, so if it tried its best to reproduce and
> ended with "Bug is not reproduced!", that looks like right result to me.

I mean if we can't reproduce the bug on the system with less-than-2-cpus,
we may need to give a note? Since this not means the kernel doesn't have
this bug but not reproduced on this specific hardware, right?

Thanks,
Wanlong Gao

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


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list