Messages in this thread | | | From | Christian Schoenebeck <> | Subject | Re: 9p EBADF with cache enabled (Was: 9p fs-cache tests/benchmark (was: 9p fscache Duplicate cookie detected)) | Date | Fri, 06 May 2022 21:14:52 +0200 |
| |
On Mittwoch, 4. Mai 2022 23:48:47 CEST asmadeus@codewreck.org wrote: > Christian Schoenebeck wrote on Wed, May 04, 2022 at 08:33:36PM +0200: > > On Dienstag, 3. Mai 2022 12:21:23 CEST asmadeus@codewreck.org wrote: > > > - add some complex code to track the exact byte range that got updated > > > > > > in some conditions e.g. WRONLY or read fails? > > > That'd still be useful depending on how the backend tracks file mode, > > > qemu as user with security_model=mapped-file keeps files 600 but with > > > passthrough or none qemu wouldn't be able to read the file regardless of > > > what we do on client... > > > Christian, if you still have an old kernel around did that use to work? > > > > Sorry, what was the question, i.e. what should I test / look for > > precisely? :) > I was curious if older kernel does not issue read at all, or issues read > on writeback fid correctly opened as root/RDRW > > You can try either the append.c I pasted a few mails back or the dd > commands, as regular user. > > $ dd if=/dev/zero of=test bs=1M count=1 > $ chmod 400 test > # drop cache or remount > $ dd if=/dev/urandom of=test bs=102 seek=2 count=1 conv=notrunc > dd: error writing 'test': Bad file descriptor
Seems you were right, the old kernel opens the file with O_RDWR.
The following was taken with cache=loose, pre-netfs kernel version, using your append code and file to be appended already containing 34 bytes, relevant file is fid 7:
v9fs_open tag 0 id 12 fid 7 mode 2 v9fs_open_return tag 0 id 12 qid={type 0 version 1651854932 path 3108899} iounit 4096 v9fs_xattrwalk tag 0 id 30 fid 5 newfid 8 name security.capability v9fs_rerror tag 0 id 30 err 95 v9fs_read tag 0 id 116 fid 7 off 0 max_count 4096 v9fs_read_return tag 0 id 116 count 34 err 45 v9fs_read tag 0 id 116 fid 7 off 34 max_count 4062 v9fs_read_return tag 0 id 116 count 0 err 11 v9fs_clunk tag 0 id 120 fid 6 v9fs_clunk tag 0 id 120 fid 4 [delay] v9fs_write tag 0 id 118 fid 7 off 0 count 39 cnt 1 v9fs_write_return tag 0 id 118 total 39 err 11 v9fs_fsync tag 0 id 50 fid 7 datasync 0
BTW to see this protocol debug output with QEMU:
cd qemu/build ../configure --enable-trace-backends=log ... make -jN ./qemu-system-x86_64 -trace 'v9fs*' ...
Best regards, Christian Schoenebeck
| |