Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0469 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 0469.

Report 0469 Actions

    Problem Report Number 0469
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0088
    Raised 1994-08-08 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.3.4
    Test Identification POSIX.os/ioprim/fcntl 15, 16
    Problem Summary PG4R.089 Some VSX fcntl() tests attempt to verify that adjacent fcntl() record locks are coalesced by the operating system into one lock. We believe that these tests are testing fcntl() locking characteristics...
    Problem Text
    Some VSX fcntl() tests attempt to verify that adjacent fcntl()
    record locks are coalesced by the operating system into one lock.

    We believe that these tests are testing fcntl() locking characteristics
    not specified by X/open or POSIX. POSIX states that the GETLK command
    must return a lock, however, since POSIX does not specify how the
    operating system should implement record locks, the only information
    that must be returned is that a lock exists on a given byte.

    We found XPG3 waivers for this problem (PG3san.146, PG3san.254,
    PG3san.501) but was unsure that any of these waivers could be used in
    XPG4 branding. We also found a reference to the XPG3 waivers in
    PG4Rsan.020 which agreed that the function of coalescing adjacent
    locks was not required. It was suggested that we submit a new request
    for a XPG4 waiver.

    The authors of the original waivers included tests 11, 12, 15, 16,
    and 23 in their list of tests failing but only tests 15 and 16 are
    failing on our implementation so those are the only ones we are
    requesting waivers for.
    Test Output
    /tset/POSIX.os/ioprim/fcntl/T.fcntl 15.Failed

    Test Description:
    For the XNFS specification:
    If the implementation supports file locking for files residing on
    a remote file system: On a call to fcntl(fildes, F_SETLKW, arg)
    when l_type = F_RDLCK is specified a shared lock is created on the
    segment specified in arg.
    For the XSH specification:
    On a call to fcntl(fildes, F_SETLKW, arg) when l_type = F_RDLCK is
    specified a shared lock is created on the segment specified in
    arg.
    Posix Ref: Component FCNTL Assertion 6.5.2.2-20(A)

    Test Strategy:
    OPEN pipes using opensync() - (genlib)
    OPEN new file using creat()
    WRITE 40 bytes to file
    CLOSE file and OPEN it again O_RDWR
    SEEK to offset 5 within the file
    CREATE process pair
    PARENT Process:
    SET lock {F_RDLCK, SEEK_SET, 5, 5, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 20, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 5,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_RDLCK, SEEK_SET, 10, 5, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 20, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 10,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_RDLCK, SEEK_SET, 10, 10, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 20, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 15,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_RDLCK, SEEK_SET, 5, 20, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 25, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 20,
    getppid()}
    WRITE data to pipe using sendsync() - (genlib)
    PARENT Process:
    READ data from pipe using waitsync() - (genlib)
    SET lock {F_WRLCK, SEEK_SET, 20, 10, 0} using fcntl(F_SETLKW)
    WRITE data to pipe using sendsync() - (genlib)
    CHILD Process:
    READ data from pipe using waitsync() - (genlib)
    VERIFY that fcntl(F_GETLK) with lock description {F_WRLCK, SEEK_SET,
    5, 25, 0} gives lock description {F_RDLCK, SEEK_SET, 5, 15,
    getppid()}
    VERIFY that fcntl(F_GETLK) with lock description {F_RDLCK, SEEK_SET,
    20, 25, 0} gives lock description {F_WRLCK, SEEK_SET, 20, 10,
    getppid()}

    Test Information:
    F_RDLCK not created/detected properly
    lock lengths differ: got 5 - expected 15

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    Although there is a documented grey area regarding the assumptions about
    coalescing of adjacent locks made by these tests, it is not clear that
    the above failures are due to these assumptions. Two particular
    concerns are:

    1. In test 15 there are two points in the code where a lock length of 15
    is expected. It is not possible to determine from the test output which
    of these two was the one at which the test failed. The first occurs
    after a lock with start=10 len=10 is created overlapping the existing
    lock with start=5 len=10. Failure at this point could be due to
    non-coalescing of the new lock with the `left over' part of the original
    lock, and so would be eligible for a waiver. However, the second point
    occurs after an existing lock with start=5 len=20 has been truncated by
    creating an overlapping lock of a different type with start=20 len=10.
    Failure at this point could not be due to non-coalescing of adjacent
    locks. It should be possible to determine which of the two points is the
    one at which the failure occurs by running the test with VSX_DBUG_FLAGS
    set to d:F:L and examining the line numbers of the PATH_TRACE statements
    that have been executed.

    2. The sequence of locking operations performed in test 15 is identical
    to that in test 11. The only difference is that one uses F_SETLK and the
    other uses F_SETLKW when creating locks. The same relationship exists
    between tests 12 and 16. If the failures of tests 15 and 16 are due to
    non-coalescing of adjacent locks, as claimed, then it seems strange that
    tests 11 and 12 are succeeding. This needs to be explained.

    It is not recommended that a waiver is granted on the evidence provided
    with this request.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority