Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1598341 - Error messages"umount.nfs4: remote share not in 'host:dir' format" occur when umount nfs filesystem
Summary: Error messages"umount.nfs4: remote share not in 'host:dir' format" occur when...
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: util-linux
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-05 07:37 UTC by wanjiankang
Modified: 2018-08-24 14:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)
script file (deleted)
2018-07-05 07:38 UTC, wanjiankang
no flags Details

Description wanjiankang 2018-07-05 07:37:43 UTC
Description of problem:
Run the command (mount nfs filesystem and umount it) concurrently,there will be error messages(umount.nfs4: remote share not in 'host:dir' format).But the operating result of command is suceess.

Version-Release number of selected component (if applicable):
util-linux-2.23.2-52.el7.x86_64.rpm

How reproducible:
Configure nfs server,it can be mount in some directory of a client.

Steps to Reproduce:
1.Running script, operating concurrent mount nfs filesystem and umount it on client
The script content is:
#/bin/bash


    for (( i=1;i<101;i++ ))
    do
        mkdir -p /tmpfs/mount-press-krb5p/user4-${i}&
    done

    for (( i=1;i<101;i++ ))
    do
        mount nfs-sve1.example.com:/ext4/nfsnobody-krb5 /tmpfs/mount-press-krb5p/user4-${i} &
    done
    wait

    for (( i=1;i<101;i++ ))
    do
         umount /tmpfs/mount-press-krb5p/user4-${i} &
    done

    wait


Actual results:
Client will print error messages:

umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format
umount.nfs4: remote share not in 'host:dir' format


Expected results:
No error message printed,and the result of the command is executed correctly.

Additional info:

Comment 2 wanjiankang 2018-07-05 07:38:24 UTC
Created attachment 1456688 [details]
script file

Comment 3 wanjiankang 2018-07-05 12:38:44 UTC
     I found that the error is caused by the referenced library function.Look up source code from nfs-utils source package, the function umount_main call the library function mnt_context_prepare_umount from the file -libmount/src/context_umount.c of util-linux source code package.
             /* read mtab/fstab, evaluate permissions, etc. */
        rc = mnt_context_prepare_umount(cxt);
        if (rc) {
                nfs_error(_("%s: failed to prepare umount: %s\n"),
                                        progname, strerror(-rc));
                goto err;
        }

     When multiple programs call this function concurrently,the cxt->fs->attrs may be NULL,although system have sufficient conditions make cxt->fs->attrs is not NULL.Then I look up code from the directory -libmount of util-linux source code package and find 


static int mnt_table_parse_next(struct libmnt_table *tb, FILE *f, struct libmnt_fs *fs,
                                const char *filename, int *nlines)
{
        char buf[BUFSIZ];
        char *s;
        int rc;

        assert(tb);
        assert(f);
        assert(fs);

        /* read the next non-blank non-comment line */
next_line:
        do {
                if (fgets(buf, sizeof(buf), f) == NULL)
                        return -EINVAL;
                ++*nlines;
                s = strchr (buf, '\n');
the fuction mnt_table_parse_next use fgets read information from /proc/self/mountinofo,it may be miss some content,although /proc/self/mountinfo have 
these content.mnt_table_parse_next will be call many times ,every times only get online content.
    So I found the cause of the result.Every program open one file,can generate a file descriptor,the file descriptor have the offset value the program have read position.Multiple program concurrently open the same file,Each process has a separate file descriptor about the file,meanwhile has separate offset vlaue.When the data of before the offset value is deleted,hte data of after the offset value will Move forward.if descriptor offset value has no changed.it will skip data without a visit and read the data below,miss some content,cause an error message to print behind.

Comment 4 Karel Zak 2018-08-24 12:26:40 UTC
Oh, sounds as a strange conclusion :-)

The kernel generates mountinfo as one string and then it's exported to the userspace program. I don't think it's updated on the fly when userspace just read the file. You need open/read it again to get an updated version of the file.

Anyway, fs->attrs is userspace stuff and it comes from /run/mount/utab where we use flock to protect the file.

I'm able to reproduce the problem, so I'll try to debug it locally. Thanks!

Comment 5 Karel Zak 2018-08-24 14:04:36 UTC
Well, not sure if I'm right in the previous comment.

It really seems like the issue is /proc/self/mountinfo, where in umount(8) we see the mountpoint (by fopen->fgets->fclose), but after fork (and umount.nfs exec) we don't see the line (again fopen, ...) in the mountinfo file.


Note You need to log in before you can comment on or make changes to this bug.