Bug 195663 - Not all files from a 9P mounted directory/subdirectory are shown
Summary: Not all files from a 9P mounted directory/subdirectory are shown
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: v9fs (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Eric Van Hensbergen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-05 04:33 UTC by Dinu-Razvan Chis-Serban
Modified: 2018-09-05 07:05 UTC (History)
2 users (show)

See Also:
Kernel Version: 4
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Patch (356 bytes, patch)
2017-05-05 04:33 UTC, Dinu-Razvan Chis-Serban
Details | Diff
Patch for fs/9p/vfs_dir.c (395 bytes, patch)
2017-05-12 07:35 UTC, Dinu-Razvan Chis-Serban
Details | Diff

Description Dinu-Razvan Chis-Serban 2017-05-05 04:33:43 UTC
Created attachment 256207 [details]
Patch

Description of problem:
When browsing the directories mounted over 9P filesystem, if there are lots of sub-directories and files, not all of them are shown.

How reproducible:
mount a 9p share and re-share it with samba, if there are a few hundred of files and sub-directories, not all of them are sown

Actual results:
4xy (x, y are digits) files

Expected results:
7xy (x, y are digits) files


Additional info:
in kernel source: 'fs/9p/vfs_dir.c' the inside the function 'v9fs_alloc_rdir_buf' the 'head' and 'tail' members of the structure 'struct p9_rdir *rdir' aren't initialized and after at a second call by the same process they retain the last value and in v9fs_dir_readdir/v9fs_dir_readdir_dotl the test (rdir->tail == rdir->head) is not executed.

Patch:
--- vfs_dir.c   2017-05-02 12:09:10.165100579 +0300
+++ vfs_dir.c   2017-05-02 12:13:04.305450584 +0300
@@ -97,6 +97,7 @@
        struct p9_fid *fid = filp->private_data;
        if (!fid->rdir)
                fid->rdir = kzalloc(sizeof(struct p9_rdir) + buflen, GFP_KERNEL);
+       ((struct p9_rdir *)fid->rdir)->tail = ((struct p9_rdir *)fid->rdir)->head = 0;
        return fid->rdir;
 }
Comment 1 Dinu-Razvan Chis-Serban 2017-05-12 07:35:08 UTC
Created attachment 256479 [details]
Patch for fs/9p/vfs_dir.c

Same patch but this time I have sent -p to diff command.
Comment 2 Dominique Martinet 2018-09-05 06:57:06 UTC
Hi Razvan, thanks for the bug report and the patch (and for linking to this bugzilla on a recent diod issue, I was just browsing by chance when I stumbled on this).

I agree with the problem and can definitely imagine that scenario you're describing happen even if I never experienced it myself - I think the common pattern is that the previous iteration would cleanly finish eating the buffer so it would usually work but I guess samba's buffer is too small maybe?..

I don't really like the long line with double cast like this though so I'll send an equivalent patch to the v9fs-developer list for upstream to pick up around 4.20; since you did the debugging though I've love to have your sign-off.

Please reply to the mail when it comes later today!
Comment 3 Dominique Martinet 2018-09-05 07:05:34 UTC
Actually I spoke too fast, the buffer isn't cleared on purpose so the readdir continues from where it was left off: imagine a readdir with a user buffer of two entries but a "on-the-wire" buffer of 100 entries.
The readdir syscall would get 100 entries from the server but only return two to userspace, then on next call would get the next two etc.

I think we need more info here, I don't have time to set up a samba share in the near future but this bug has been around forever... So since you said you're not using 9p anymore I assume you're not too interested in debugging further?


Anyway, thanks for the report, I'll finish looking at other open bugs and dig further into this one when time permits.

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