[LTP] [PATCH] Fix the fork/11-1 conformance testcase

[LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Garrett Cooper]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

The testcase tests to see whether or not locks are successfully
inherited across forking processes, as the requirements for fork state
that they should not be. The problem is that the test tests the negative
case for ftrylockfile (!= 0) instead of the positive case, which creates
an erroneous test failure as OUTPUT goes to /dev/stdout and the test
hangs.

Signed-off-by: Garrett Cooper <yanegomi@gmail.com>

diff --git a/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
b/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
index ffff125..632b0db 100644
--- a/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
+++ b/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
@@ -85,7 +85,7 @@ void * threaded(void * arg)
        int ret;
        ret = ftrylockfile(stdout);

-       if (ret != 0)
+       if (ret == 0)
        {
                FAILED("The child process is owning the file lock.");
        }
@@ -168,4 +168,4 @@ int main(int argc, char * argv[])
 #endif

        PASSED;
-}
\ No newline at end of file
+}

[-- Attachment #2: 0001-Fix-the-fork-11-1-conformance-testcase.patch --]
[-- Type: application/octet-stream, Size: 1866 bytes --]

From 585537f7fa46be824d26b90d122472447f57cffc Mon Sep 17 00:00:00 2001
From: Garrett Cooper <yanegomi@gmail.com>
Date: Sat, 26 May 2012 07:01:43 -0700
Subject: [PATCH] Fix the fork/11-1 conformance testcase
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------1.7.10.1"

This is a multi-part message in MIME format.
--------------1.7.10.1
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


The testcase tests to see whether or not locks are successfully
inherited across forking processes, as the requirements for fork state
that they should not be. The problem is that the test tests the negative
case for ftrylockfile (!= 0) instead of the positive case, which creates
an erroneous test failure as OUTPUT goes to /dev/stdout and the test
hangs.

Signed-off-by: Garrett Cooper <yanegomi@gmail.com>
---
 testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


--------------1.7.10.1
Content-Type: text/x-patch; name="0001-Fix-the-fork-11-1-conformance-testcase.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-the-fork-11-1-conformance-testcase.patch"

diff --git a/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c b/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
index ffff125..632b0db 100644
--- a/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
+++ b/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
@@ -85,7 +85,7 @@ void * threaded(void * arg)
 	int ret;
 	ret = ftrylockfile(stdout);
 
-	if (ret != 0)
+	if (ret == 0)
 	{
 		FAILED("The child process is owning the file lock.");
 	}
@@ -168,4 +168,4 @@ int main(int argc, char * argv[])
 #endif
 
 	PASSED;
-}
\ No newline at end of file
+}

--------------1.7.10.1--



[-- Attachment #3: Type: text/plain, Size: 395 bytes --]

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Wanlong Gao]

On 05/26/2012 10:15 PM, Garrett Cooper wrote:

> The testcase tests to see whether or not locks are successfully
> inherited across forking processes, as the requirements for fork state
> that they should not be. The problem is that the test tests the negative
> case for ftrylockfile (!= 0) instead of the positive case, which creates


The ftrylockfile() function returns zero for success (the lock was obtained),
and nonzero for failure. 
So I think the origin is right.

Thanks,
Wanlong Gao

> an erroneous test failure as OUTPUT goes to /dev/stdout and the test
> hangs.
> 
> Signed-off-by: Garrett Cooper <yanegomi@gmail.com>
> 
> diff --git a/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
> b/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
> index ffff125..632b0db 100644
> --- a/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
> +++ b/testcases/open_posix_testsuite/conformance/interfaces/fork/11-1.c
> @@ -85,7 +85,7 @@ void * threaded(void * arg)
>         int ret;
>         ret = ftrylockfile(stdout);
> 
> -       if (ret != 0)
> +       if (ret == 0)
>         {
>                 FAILED("The child process is owning the file lock.");
>         }
> @@ -168,4 +168,4 @@ int main(int argc, char * argv[])
>  #endif
> 
>         PASSED;
> -}
> \ No newline at end of file
> +}
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> 
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Garrett Cooper]

On Sun, May 27, 2012 at 12:33 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
> On 05/26/2012 10:15 PM, Garrett Cooper wrote:
>
>> The testcase tests to see whether or not locks are successfully
>> inherited across forking processes, as the requirements for fork state
>> that they should not be. The problem is that the test tests the negative
>> case for ftrylockfile (!= 0) instead of the positive case, which creates
>
> The ftrylockfile() function returns zero for success (the lock was obtained),
> and nonzero for failure.
> So I think the origin is right.

    My description might be wrong, but the fix is right. ftrylockfile
should fail in the testcase (not succeed) because the file lock isn't
owned by the forked process. It succeeds simply because the delay is
long enough on some platforms. I could check and ensure that EAGAIN
(or the POSIX prescribed error) occurs if this occurs instead in the
implicit else case.
Thanks!
-Garrett

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Wanlong Gao]

On 05/27/2012 04:00 PM, Garrett Cooper wrote:

> On Sun, May 27, 2012 at 12:33 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>> On 05/26/2012 10:15 PM, Garrett Cooper wrote:
>>
>>> The testcase tests to see whether or not locks are successfully
>>> inherited across forking processes, as the requirements for fork state
>>> that they should not be. The problem is that the test tests the negative
>>> case for ftrylockfile (!= 0) instead of the positive case, which creates
>>
>> The ftrylockfile() function returns zero for success (the lock was obtained),
>> and nonzero for failure.
>> So I think the origin is right.
> 
>     My description might be wrong, but the fix is right. ftrylockfile
> should fail in the testcase (not succeed) because the file lock isn't
> owned by the forked process. It succeeds simply because the delay is


But on my system ftrylockfile() always return 0, and the test PASSED.
and with your patch, it fails.

Thanks,
Wanlong Gao

> long enough on some platforms. I could check and ensure that EAGAIN
> (or the POSIX prescribed error) occurs if this occurs instead in the
> implicit else case.
> Thanks!
> -Garrett
> 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Garrett Cooper]

On Sun, May 27, 2012 at 1:14 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
> On 05/27/2012 04:00 PM, Garrett Cooper wrote:
>
>> On Sun, May 27, 2012 at 12:33 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>>> On 05/26/2012 10:15 PM, Garrett Cooper wrote:
>>>
>>>> The testcase tests to see whether or not locks are successfully
>>>> inherited across forking processes, as the requirements for fork state
>>>> that they should not be. The problem is that the test tests the negative
>>>> case for ftrylockfile (!= 0) instead of the positive case, which creates
>>>
>>> The ftrylockfile() function returns zero for success (the lock was obtained),
>>> and nonzero for failure.
>>> So I think the origin is right.
>>
>>     My description might be wrong, but the fix is right. ftrylockfile
>> should fail in the testcase (not succeed) because the file lock isn't
>> owned by the forked process. It succeeds simply because the delay is
>
>
> But on my system ftrylockfile() always return 0, and the test PASSED.
> and with your patch, it fails.

Then that's a Linux/POSIX bug then. From fork(2) on OpenGroup [1]:

"File locks set by the parent process are not inherited by the child process."

And from flockfile(2) on OpenGroup [2]:

"   The flockfile() function is used by a thread to acquire ownership
of a ( FILE *) object.

    The ftrylockfile() function is used by a thread to acquire
ownership of a ( FILE *) object if the object is available;
ftrylockfile() is a non-blocking version of flockfile().

...

    None for flockfile() and funlockfile(). The function
ftrylockfile() returns zero for success and non-zero to indicate that
the lock cannot be acquired."

The goal/algorithm as stated at the top of the testcase was...

"* The steps are:
* -> lock stdout
* -> fork
* -> child creates a thread
* -> child thread trylock stdout
* -> join the child

* The test fails if the child thread cannot lock the file
* -- this would mean the child process got stdout file lock ownership."

Thanks!
-Garrett

1. http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html
2. http://pubs.opengroup.org/onlinepubs/009695399/functions/flockfile.html

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Wanlong Gao]

On 05/27/2012 04:23 PM, Garrett Cooper wrote:

> On Sun, May 27, 2012 at 1:14 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>> On 05/27/2012 04:00 PM, Garrett Cooper wrote:
>>
>>> On Sun, May 27, 2012 at 12:33 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>>>> On 05/26/2012 10:15 PM, Garrett Cooper wrote:
>>>>
>>>>> The testcase tests to see whether or not locks are successfully
>>>>> inherited across forking processes, as the requirements for fork state
>>>>> that they should not be. The problem is that the test tests the negative
>>>>> case for ftrylockfile (!= 0) instead of the positive case, which creates
>>>>
>>>> The ftrylockfile() function returns zero for success (the lock was obtained),
>>>> and nonzero for failure.
>>>> So I think the origin is right.
>>>
>>>     My description might be wrong, but the fix is right. ftrylockfile
>>> should fail in the testcase (not succeed) because the file lock isn't
>>> owned by the forked process. It succeeds simply because the delay is
>>
>>
>> But on my system ftrylockfile() always return 0, and the test PASSED.
>> and with your patch, it fails.
> 
> Then that's a Linux/POSIX bug then. From fork(2) on OpenGroup [1]:
> 
> "File locks set by the parent process are not inherited by the child process."
> 
> And from flockfile(2) on OpenGroup [2]:
> 
> "   The flockfile() function is used by a thread to acquire ownership
> of a ( FILE *) object.
> 
>     The ftrylockfile() function is used by a thread to acquire
> ownership of a ( FILE *) object if the object is available;
> ftrylockfile() is a non-blocking version of flockfile().
> 
> ...
> 
>     None for flockfile() and funlockfile(). The function
> ftrylockfile() returns zero for success and non-zero to indicate that
> the lock cannot be acquired."

> 

> The goal/algorithm as stated at the top of the testcase was...
> 
> "* The steps are:
> * -> lock stdout
> * -> fork
> * -> child creates a thread
> * -> child thread trylock stdout
> * -> join the child
> 
> * The test fails if the child thread cannot lock the file
> * -- this would mean the child process got stdout file lock ownership."


Yes, if trylock can't get the lock, it should return nonzero, I think
the concept is right.
But you mean if trylock() can't get the lock, it should return zero?

Thanks,
Wanlong Gao

> 
> Thanks!
> -Garrett
> 
> 1. http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html
> 2. http://pubs.opengroup.org/onlinepubs/009695399/functions/flockfile.html
> 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Garrett Cooper]

On Sun, May 27, 2012 at 2:06 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
> On 05/27/2012 04:23 PM, Garrett Cooper wrote:
>
>> On Sun, May 27, 2012 at 1:14 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>>> On 05/27/2012 04:00 PM, Garrett Cooper wrote:
>>>
>>>> On Sun, May 27, 2012 at 12:33 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>>>>> On 05/26/2012 10:15 PM, Garrett Cooper wrote:
>>>>>
>>>>>> The testcase tests to see whether or not locks are successfully
>>>>>> inherited across forking processes, as the requirements for fork state
>>>>>> that they should not be. The problem is that the test tests the negative
>>>>>> case for ftrylockfile (!= 0) instead of the positive case, which creates
>>>>>
>>>>> The ftrylockfile() function returns zero for success (the lock was obtained),
>>>>> and nonzero for failure.
>>>>> So I think the origin is right.
>>>>
>>>>     My description might be wrong, but the fix is right. ftrylockfile
>>>> should fail in the testcase (not succeed) because the file lock isn't
>>>> owned by the forked process. It succeeds simply because the delay is
>>>
>>>
>>> But on my system ftrylockfile() always return 0, and the test PASSED.
>>> and with your patch, it fails.
>>
>> Then that's a Linux/POSIX bug then. From fork(2) on OpenGroup [1]:
>>
>> "File locks set by the parent process are not inherited by the child process."
>>
>> And from flockfile(2) on OpenGroup [2]:
>>
>> "   The flockfile() function is used by a thread to acquire ownership
>> of a ( FILE *) object.
>>
>>     The ftrylockfile() function is used by a thread to acquire
>> ownership of a ( FILE *) object if the object is available;
>> ftrylockfile() is a non-blocking version of flockfile().
>>
>> ...
>>
>>     None for flockfile() and funlockfile(). The function
>> ftrylockfile() returns zero for success and non-zero to indicate that
>> the lock cannot be acquired."
>
>>
>
>> The goal/algorithm as stated at the top of the testcase was...
>>
>> "* The steps are:
>> * -> lock stdout
>> * -> fork
>> * -> child creates a thread
>> * -> child thread trylock stdout
>> * -> join the child
>>
>> * The test fails if the child thread cannot lock the file
>> * -- this would mean the child process got stdout file lock ownership."
>
>
> Yes, if trylock can't get the lock, it should return nonzero, I think
> the concept is right.
> But you mean if trylock() can't get the lock, it should return zero?

No.

Looking into the implementation of ftrylockfile further, it looks like
the locking is not advisory locking in the traditional sense, but
instead thread-based locking -- this matches the description in the
FreeBSD and OpenGroup manpage.

The problem that I see is multi-fold:
1. The testcase's original test for success was right as the testcase
is using fork, not forkall.
2. There's a bug in FreeBSD that I need to investigate and fix.

I think that the testcase should test another stream than stdout
though (say, open up /dev/null via fopen?). It would at least allow
the test to return immediately instead of blocking indefinitely.

Do you object to the other changes?

Thanks!
-Garrett

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] Fix the fork/11-1 conformance testcase

[Wanlong Gao]

On 05/28/2012 02:19 AM, Garrett Cooper wrote:

> On Sun, May 27, 2012 at 2:06 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>> On 05/27/2012 04:23 PM, Garrett Cooper wrote:
>>
>>> On Sun, May 27, 2012 at 1:14 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>>>> On 05/27/2012 04:00 PM, Garrett Cooper wrote:
>>>>
>>>>> On Sun, May 27, 2012 at 12:33 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> wrote:
>>>>>> On 05/26/2012 10:15 PM, Garrett Cooper wrote:
>>>>>>
>>>>>>> The testcase tests to see whether or not locks are successfully
>>>>>>> inherited across forking processes, as the requirements for fork state
>>>>>>> that they should not be. The problem is that the test tests the negative
>>>>>>> case for ftrylockfile (!= 0) instead of the positive case, which creates
>>>>>>
>>>>>> The ftrylockfile() function returns zero for success (the lock was obtained),
>>>>>> and nonzero for failure.
>>>>>> So I think the origin is right.
>>>>>
>>>>>     My description might be wrong, but the fix is right. ftrylockfile
>>>>> should fail in the testcase (not succeed) because the file lock isn't
>>>>> owned by the forked process. It succeeds simply because the delay is
>>>>
>>>>
>>>> But on my system ftrylockfile() always return 0, and the test PASSED.
>>>> and with your patch, it fails.
>>>
>>> Then that's a Linux/POSIX bug then. From fork(2) on OpenGroup [1]:
>>>
>>> "File locks set by the parent process are not inherited by the child process."
>>>
>>> And from flockfile(2) on OpenGroup [2]:
>>>
>>> "   The flockfile() function is used by a thread to acquire ownership
>>> of a ( FILE *) object.
>>>
>>>     The ftrylockfile() function is used by a thread to acquire
>>> ownership of a ( FILE *) object if the object is available;
>>> ftrylockfile() is a non-blocking version of flockfile().
>>>
>>> ...
>>>
>>>     None for flockfile() and funlockfile(). The function
>>> ftrylockfile() returns zero for success and non-zero to indicate that
>>> the lock cannot be acquired."
>>
>>>
>>
>>> The goal/algorithm as stated at the top of the testcase was...
>>>
>>> "* The steps are:
>>> * -> lock stdout
>>> * -> fork
>>> * -> child creates a thread
>>> * -> child thread trylock stdout
>>> * -> join the child
>>>
>>> * The test fails if the child thread cannot lock the file
>>> * -- this would mean the child process got stdout file lock ownership."
>>
>>
>> Yes, if trylock can't get the lock, it should return nonzero, I think
>> the concept is right.
>> But you mean if trylock() can't get the lock, it should return zero?
> 
> No.
> 
> Looking into the implementation of ftrylockfile further, it looks like
> the locking is not advisory locking in the traditional sense, but
> instead thread-based locking -- this matches the description in the
> FreeBSD and OpenGroup manpage.
> 
> The problem that I see is multi-fold:
> 1. The testcase's original test for success was right as the testcase
> is using fork, not forkall.
> 2. There's a bug in FreeBSD that I need to investigate and fix.
> 
> I think that the testcase should test another stream than stdout
> though (say, open up /dev/null via fopen?). It would at least allow
> the test to return immediately instead of blocking indefinitely.
> 
> Do you object to the other changes?


I think I have no more objection.

Thanks,
Wanlong Gao 

> 
> Thanks!
> -Garrett
> 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list