lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <YlyFEuTY7tASl8aY@codewreck.org> Date: Mon, 18 Apr 2022 06:22:26 +0900 From: asmadeus@...ewreck.org To: Christian Schoenebeck <linux_oss@...debyte.com> Cc: David Kahurani <k.kahurani@...il.com>, davem@...emloft.net, ericvh@...il.com, kuba@...nel.org, linux-kernel@...r.kernel.org, lucho@...kov.net, netdev@...r.kernel.org, v9fs-developer@...ts.sourceforge.net, David Howells <dhowells@...hat.com>, Greg Kurz <groug@...d.org> Subject: Re: 9p fs-cache tests/benchmark (was: 9p fscache Duplicate cookie detected) Christian Schoenebeck wrote on Sun, Apr 17, 2022 at 03:52:43PM +0200: > > From the looks of it, write fails in v9fs_write_begin, which itself > > fails because it tries to read first on a file that was open with > > O_WRONLY|O_CREAT|O_APPEND. > > Since this is an append the read is necessary to populate the local page > > cache when writing, and we're careful that the writeback fid is open in > > write, but not about read... > > > > Will have to think how we might want to handle this; perhaps just giving > > the writeback fid read rights all the time as well... > > Ran out of time for tonight, but hopefully we can sort it out soonish now! > > I fear that would just trade symptoms: There are use cases for write-only > permissions, which would then fail after such kind of simple change. The writeback fid is only used by async ops to flush (and apparently since 5.10ish populate) the cache; I actually wonder how that "populate the cache" worked before! Anyway, since it's not used by direct operations I believe we can mess with its open mode, but that assumes permission checks are properly done at vfs level (this is pretty much the line of thinking that allowed dirty cow... But in this case if a file is opened read-only the writeback fid isn't allocated afaik, so it's probably ok ?...) Alternatively we could have the cache issue yet another open for read when needed, but I think a single RW fid is probably good enough if we might read from it (no TRUNC)... It'd break opening the writeback fid on files with -w- permission if the open is not done as root, but I don't see how we could make appending to a write only file at something that is not a page boundary either way. David, netfs doesn't allow cache at byte granularity, correct? If it does we could fix the problem by only triggering a read when really needed. > Independent of this EBADF issue, it would be good to know why 9p performance > got so slow with cache=loose by the netfs changes. Maybe David has an idea? Yes, I've just compared the behaviour of the old cache and new one (with cache=loose) and the main difference in behaviour I can see if the time until flush is longer on older version, and reads are bigger with the new version recently, but the rest is all identical as far as I can see (4k IOs for write, walk/open/clunk sequences to read a cached file (we could delay these until reading into cache or a metadata op is required?), TFSYNC after a series of write or on directories after a while...), so I don't see a difference. In particular I don't observe any cache invalidation when the mtime (and so qid 'version', e.g. cache anciliary data) changes, but for cache=loose that's how I'd expect it to work as well. Perhaps the performance difference can be explained just by how aggressively it's flushed out of memory, since it's written to disk faster it'd also be easier to forget about and re-issue slow reads? hmm... I need to spend more time on that as well... -- Dominique
Powered by blists - more mailing lists