jerpelea opened a new pull request, #20247: URL: https://github.com/apache/nuttx/pull/20247
## Summary filemtd_initialize() opens its backing file with mode = O_RDONLY | O_WRONLY | O_CLOEXEC; Commit https://github.com/apache/nuttx/commit/6161c7363977c75dd47281aa134092434eec1a98 ("include/fcntl.h: remove O_RDOK/O_WROK aliases") introduced this when it replaced the non-standard O_RDOK | O_WROK pair, describing the change as a pure text substitution. That held while the access mode was a genuine bitmask: O_RDONLY was (1 << 0), O_WRONLY was (1 << 1), O_RDWR was both bits, and O_ACCMODE was defined as an alias for O_RDWR. OR-ing the two was meaningful and produced O_RDWR. Commit https://github.com/apache/nuttx/commit/9e141acab36329e380c46bb2aa1ede0abc96fcb3 ("include/fcntl.h: align open flags with Linux values") then made the low two bits an enumeration — O_RDONLY 0, O_WRONLY 1, O_RDWR 2 — and O_ACCMODE stopped being an alias for O_RDWR, becoming an independent mask of 3. OR-ing two members of that enumeration is no longer meaningful: O_RDONLY | O_WRONLY == 0 | 1 == 1 1 & O_ACCMODE == O_WRONLY The file is opened write-only, and fs/vfs/fs_read.c:202 rejects every read on it with -EACCES. Is this a pattern? It looks like an isolated miss rather than a systematic one. Grepping the tree: Two access-mode constants OR-ed together — this call site only. Bit-testing the mode instead of masking — one site, fs/xipfs/xipfs_vfs.c:606, which happens to be correct under the new values (and would have been wrong under the old ones, so it was clearly written after the change). Unmasked equality against an access mode — none. Host/guest translation — the NUTTX_O_* mirror in include/nuttx/fs/hostfs.h was updated in lockstep and host_oflags_convert() switches on flags & NUTTX_O_ACCMODE. ## Impact RELEASE ## Testing CI -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
