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>
> Cc: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com>, ltp-list@lists.sourceforge.net, "Artem Savkov"
> <asavkov@redhat.com>
> Sent: Monday, 21 July, 2014 11:40:19 AM
> Subject: Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)
> 
> 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?

Sure. I have no objections on expanding "Bug is not reproduced!" message
in case it runs on single CPU system to give more context.

Regards,
Jan

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