On 07/21/2014 05:33 PM, Jan Stancek wrote: > > > ----- Original Message ----- >> From: "Wanlong Gao" <gaowanl...@cn.fujitsu.com> >> To: "Jan Stancek" <jstan...@redhat.com>, "Xiaoguang Wang" >> <wangxg.f...@cn.fujitsu.com> >> Cc: ltp-list@lists.sourceforge.net, "Artem Savkov" <asav...@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.f...@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.f...@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
