[LU-4219] posix test_1: fpathconf.8 and pathconf.10 failed: did not return the value of NAME_MAX

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.6.0, Lustre 2.4.2, Lustre 2.5.1
• Affects Version/s: Lustre 2.4.1, Lustre 2.5.0
• Labels: zfs
• Environment: BASELINE_FS=zfs
• Severity: 3
• Assignee: Jian Yu
• Reporter: Jian Yu

Description

While running posix test on Lustre with BASELINE_FS=zfs, fpathconf.8 and pathconf.10 failed as follows:

####################################################
Test Name: fpathconf.8 Failed

	Test Description:
For the XNFS specification:
    Not in use.
For the XSH specification:
    If NAME_MAX is defined when <limits.h> is included, a call to
    fpathconf(fildes, _PC_NAME_MAX) when fildes refers to a directory,
    returns the value of NAME_MAX.
    (In XPG3 mode, a value > NAME_MAX is also allowed.)
Posix Ref: Component FPATHCONF Assertion 5.7.1.2-11(C)

	Test Strategy:
IF NAME_MAX is defined
  OPEN current directory using open() with O_RDONLY|O_NONBLOCK and
  with time out
  VERIFY that the open() was successful
  OBTAIN the system value associated with fpathconf() with
  _PC_NAME_MAX
  VERIFY that fpathconf() returned successfully and errno was not set
  VERIFY that return value is equal to NAME_MAX (or >= in XPG3 mode)
  OPEN root directory using open() with O_RDONLY|O_NONBLOCK and with
  time out
  VERIFY that the open() was successful
  OBTAIN the system value associated with fpathconf() with
  _PC_NAME_MAX
  VERIFY that fpathconf() returned successfully and errno was not set
  VERIFY that return value is equal to NAME_MAX (or >= in XPG3 mode)

	Test Information:
fpathconf(fd, _PC_NAME_MAX) on "." did not return the value of NAME_MAX
value returned: 256, NAME_MAX: 255
(NAME_MAX should not be defined in <limits.h> if the 
run-time value can vary.)

####################################################
Test Name: pathconf.10 Failed

	Test Description:
For the XNFS specification:
    Not in use.
For the XSH specification:
    If NAME_MAX is defined when <limits.h> is included, a call to
    pathconf(path, _PC_NAME_MAX) when path refers to a directory,
    returns the value of NAME_MAX.
    (In XPG3 mode, a value > NAME_MAX is also allowed.)
Posix Ref: Component PATHCONF Assertion 5.7.1.2-33(C)

	Test Strategy:
IF NAME_MAX is defined
  FOR current directory and root directory
    OBTAIN the system value associated with pathconf() with
    _PC_NAME_MAX and current directory
    VERIFY that pathconf() returned successfully and errno was not set
    VERIFY that return value is equal to NAME_MAX (or >= in XPG3 mode)

	Test Information:
pathconf(".", _PC_NAME_MAX) did not return the value of NAME_MAX
value returned: 256, NAME_MAX: 255
(NAME_MAX should not be defined in <limits.h> if the 
run-time value can vary.)

####################################################

Maloo report: https://maloo.whamcloud.com/test_sets/e74b645e-4634-11e3-810a-52540035b04c

Comments from Andreas:

I think all of the pathconf failures may be caused by pathconf being hard coded in glibc based on the Filesystem magic number. That means it isn't possible to change the value for Lustre without recompiling glibc.

Issue Links

• is duplicated by: LU-4220 posix test_1: creat.24 failed: creat("<256 char path>", 0777) did not give correct results
• is duplicated by: LU-3603 posix test_1: path tracing error: path counter 1, expected 3
• is related to: LU-18783 pjdfstest test chmod 2 fails with ZFS 2.3.0
• is related to: LU-3587 CR_MAXSIZE is too small
• is related to: LU-18803 remove hard-coded NAME_MAX from client and server

Comments

[Jian Yu]

Patch landed on Lustre b2_4 branch for 2.4.2.

[Bob Glossman (Inactive)]

backport to b2_4
http://review.whamcloud.com/8276

[Jian Yu]

Patch for master branch has landed. The remaining work is to land the patch on Lustre b2_4 and b2_5 branches.

[Jian Yu]

Patch for master branch is in http://review.whamcloud.com/8217.
After the patch is ready to land, it can also be cherry-picked to Lustre b2_4 branch.

[Jian Yu]

For reference, in lts_vsx-pcts2.0beta2/tset/POSIX.os/files/pathconf/pathconf.c:

private void
test10()
{
        //......
        chkval(".", _PC_NAME_MAX, (long)NAME_MAX, "NAME_MAX");
        //......
}

private void
chkval(path, name, expval, constname)
char *path;
int name;
long expval;
char *constname;
{       
        /* Check return value is equal to constant in <limits.h> */

        //......
        rval = tbpathconf(path, name, SUCCEED, NOERROR);

        //......
        if (rval != expval)
        {
                if (testfail == 0)
                        xx_rpt(FAILURE);
                in_rpt("pathconf(\"%s\", %s) did not return the value of %s",
                        path, strname(name), constname);
                in_rpt("value returned: %ld, %s: %ld", rval, constname, expval);
                if (testfail == 0)
                {
                        in_rpt("(%s should not be defined in <limits.h> if the ",
                                constname);
                        in_rpt("run-time value can vary.)");
                }
                testfail++;
        }
        //......
}

I'll upload a patch as per the comments from Andreas.

[Andreas Dilger]

It looks like ldiskfs/ext4 uses EXT4_NAME_LEN = 255, and ZFS uses MAXNAMELEN = 256, which it gets from MDT0 statfs f_namelen. Since glibc doesn't handle dynamic f_namelen, so we probably need to limit f_namelen to a max of 255 in mdd_statfs().