Bug 211171
Summary: | vboxsf VirtualBox shared folder mkdir and open/create file racy/random errors : "Already exists" or "Text file busy" | ||
---|---|---|---|
Product: | File System | Reporter: | Ludovic Pouzenc (ludovic) |
Component: | Other | Assignee: | fs_other |
Status: | NEW --- | ||
Severity: | normal | CC: | jwrdegoede |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 5.9.6-1~bpo10+1 (2020-11-19) x86_64 GNU/Linux (Debian) | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | all-mentionned-logs-and-reproducers-source-code.zip |
Description
Ludovic Pouzenc
2021-01-13 10:32:45 UTC
As already discussed by email, there are really 2 independent issues here: 1. There was a race condition where a wait_on could be interrupted even though it was an in-kernel vbox ipc call. This was causing the errors above and this has been fixed upstream now: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=c35901b39ddc20077f4ae7b9f7bf344487f62212 2. When running "git clone" on the guest inside a vbox-shared-folder and the host is a Linux machine then it will fail with -EPERM when trying to create a tmpfile. I've posted a patch-series for the vboxsf fs driver which fixes 2. here is a copy of the cover-letter which explain the problem in more details: Opening a new file is done in 2 steps on regular filesystems: 1. Call the create inode-op on the parent-dir to create an inode to hold the meta-data related to the file. 2. Call the open file-op to get a handle for the file. vboxsf however does not really use disk-backed inodes because it is based on passing through file-related system-calls through to the hypervisor. So both steps translate to an open(2) call being passed through to the hypervisor. With the handle returned by the first call immediately being closed again. Making 2 open calls for a single open(..., O_CREATE, ...) calls has 2 problems: a) It is not really efficient. b) It actually breaks some apps. An example of b) is doing a git clone inside a vboxsf mount. When git clone tries to create a tempfile to store the pak files which is downloading the following happens: 1. vboxsf_dir_mkfile() gets called with a mode of 0444 and succeeds. 2. vboxsf_file_open() gets called with file->f_flags containing O_RDWR. When the host is a Linux machine this fails because doing a open(..., O_RDWR) on a file which exists and has mode 0444 results in an -EPERM error. This series fixes this by adding support for the atomic_open directory-inode op. The patch series fixing 2. is awaiting review. |