On 3/7/25 9:25 AM, Mateusz Guzik wrote: > On Fri, Mar 7, 2025 at 5:18?PM Jens Axboe <[email protected]> wrote: >> >>> +static inline void makeatomicname(struct filename *name) >>> +{ >>> + VFS_BUG_ON(IS_ERR_OR_NULL(name)); >>> + /* >>> + * The name can legitimately already be atomic if it was cached by >>> audit. >>> + * If switching the refcount to atomic, we need not to know we are the >>> + * only non-atomic user. >>> + */ >>> + VFS_BUG_ON(name->owner != current && !name->is_atomic); >>> + /* >>> + * Don't bother branching, this is a store to an already dirtied >>> cacheline. >>> + */ >>> + name->is_atomic = true; >>> +} >> >> Should this not depend on audit being enabled? io_uring without audit is >> fine. >> > > I thought about it, but then I got worried about transitions from > disabled to enabled -- will they suddenly start looking here? Should > this test for audit_enabled, audit_dummy_context() or something else? > I did not want to bother analyzing this.
Let me take a look at it, the markings for when to switch atomic are not accurate - it only really needs to happen for offload situations only, and if audit is enabled and tracking. So I think we can great improve upon this patch. > I'll note though this would be an optimization on top of the current > code, so I don't think it *blocks* the patch. Let's not go with something half-done if we can get it right the first time. -- Jens Axboe
