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

[Jan Stancek <jstancek@redhat.com>]

----- 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.

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