Hi!
Patch 3 was pushed.
Thank you.
On 09/28/2014 06:53 AM, Xiong Zhou wrote:
> Hi!
>
> ----- Original Message -----
>> From: "Stanislav Kholmanskikh" <stanislav.kholmansk...@oracle.com>
>> To: "Xiong Zhou" <xz...@redhat.com>
>> Cc: ltp-list@lists.sourceforge.net
>> Sent: Friday, September 26, 2014 8:36:00 PM
>> Subject: Re: [LTP] [PATCH v3 1/3] fcntl14: dup code clean up
>>
>> Hi!
>>
>> On 09/26/2014 07:23 AM, Xiong Zhou wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Stanislav Kholmanskikh" <stanislav.kholmansk...@oracle.com>
>>>> To: "Xiong Zhou" <xz...@redhat.com>
>>>> Cc: ltp-list@lists.sourceforge.net
>>>> Sent: Thursday, September 25, 2014 8:07:26 PM
>>>> Subject: Re: [LTP] [PATCH v3 1/3] fcntl14: dup code clean up
>>>>
>>>> Hi!
>>>>
>>>> On 09/25/2014 11:17 AM, Xiong Zhou wrote:
>>>>>
>>>>> And block3 description message fix from "mandatory locking"
>>>>> to "negative whence".
>>>>>
>>>>> Signed-off-by: Xiong Zhou <xz...@redhat.com>
>>>>> ---
>>>>
>>>> Patch 1 and patch 2 of the series are pushed.
>>>> Btw, patch 2 didn't apply to index correctly with 'git am', I had to
>>>> manually apply it.
>>>>
>>>
>>> Sorry for the inconvenience.. I should keep my master branch updated.
>>>
>>>> I'm experiencing difficulties with checking patch 3. In particular,
>>>> after applying your patch utime02 fails on NFSv4 with
>>>> 2.6.32-431.29.2.el6.x86_64 kernel.
>>>
>>> Yes, I got the same results on 2.6.32-431.29.2.el6 kernel, v3 pass v4 fail.
>>>
>>>>
>>>> I'm not quite sure if it's a kernel problem or test case error. Still
>>>> investigating.
>>>>
>>>> Could you please check the test case in your RHEL 6 environment as well?
>>>
>>> I double checked that utime02 did pass on upstream 2.6.32 kernel
>>> both NFSv3 and NFSv4 in my env.
>>> On latest RHEL-6 kernel, both NFSv3 and NFSv4 passed utime02 test case.
>>>
>>> All failed test_output are just like:
>>> tst_tmpdir.c:158: chown(/nfsmnt/ltp-6L6Oqow6wv/utiMPq3y5, -1, 0) \
>>> failed: errno=EPERM(1): Operation not permitted
>>
>> Sorry, I didn't get whether utime02+NFSv4 passed with the latest RHEL-6
>> kernel. Could you elaborate on this?
>
> Sorry for the confusion. The latest kernel I have tested on was an internal
> test temp build.
>
>>
>>>
>>> One single clean chown(nfsfile, -1, 0) call to NFSv3/4 file succeeds
>>> on multiple kernels include 2.6.32-431.29.2.el6.
>>>
>>> Neither, I'm not sure about where the problem lies. Still checking.
>>
>> test.c:
>>
>> #include <error.h>
>> #include <unistd.h>
>> #include <sys/stat.h>
>> #include <sys/types.h>
>>
>> int main(void)
>> {
>> if (setuid(99)) {
>> perror("setuid() failed");
>> goto out;
>> }
>>
>> if (mkdir("dir", 0700)) {
>> perror("mkdir() failed");
>> goto out;
>> }
>>
>> if (chown("dir", -1, 0))
>> perror("chown() failed");
>>
>> out:
>> return 0;
>> }
>>
>> 99 is 'nobody'.
>>
>> With both upstream 2.6.32 and 2.6.32.63 `strace ./test` on a nfsv4 fs
>> will show:
>> setuid(99) = 0
>> mkdir("dir", 0700) = 0
>> chown("dir", 4294967295, 0) = 0
>>
>> [root@ol6-x64 nfsv4]# ls -ld dir
>> drwx------ 2 nobody root 4096 Sep 26 13:14 dir
>>
>> But with 2.6.32-431.29.2.el6.x86_64:
>> setuid(99) = 0
>> mkdir("dir", 0700) = 0
>> chown("dir", 4294967295, 0) = -1 EPERM (Operation not permitted)
>>
>> [root@ol6-x64 nfsv4]# ls -ld dir
>> drwx------ 2 nobody root 4096 Sep 26 13:19 dir
>>
>> So, most likely, it's a bug in the vendor kernels.
>
> I agree, and I think it has been recorded already.
>
> Thanks!
> --
> xzhou
>>
>> So on I think that your patch may be pushed.
>>
>> If there are no objections, I would like to do it on Monday.
>>
>> Thanks.
>>
>>>
>>> Thanks for catching this!
>>>
>>> --
>>> xzhou
>>>
>>>>
>>>> Thank you.
>>>>
>>
------------------------------------------------------------------------------
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
