[Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()
Linus Torvalds
torvalds at linux-foundation.org
Wed Oct 25 23:44:04 UTC 2023
On Wed, 25 Oct 2023 at 10:36, Christian Brauner <brauner at kernel.org> wrote:
>
> I did think that the loop didn't really matter for this case but since
> it seemingly does paper over the weird semantics here let's drop it.
> Anyway, pushed to:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.misc
LGTM.
We could then make the i915 mmap_singleton() do the proper loop over
the whole thing. Not quite the way Jann suggested - which would not
increment the file refcount properly, but instead of the current
smp_store_mb(i915->gem.mmap_singleton, file);
drm_dev_get(&i915->drm);
return file;
it could do something much more complicated like
drm_dev_get(&i915->drm);
if (cmpxchg(&i915->gem.mmap_singleton, NULL, file) == NULL)
return file;
// mmap_singleton wasn't NULL: it might be an old one in the
// process of being torn down (with a zero refcount), or a new
// one that was just installed that we should use instead
fput(file);
file = READ_ONCE(i915->gem.mmap_singleton);
if (!file)
goto repeat;
// Is it valid? Just try again
if (atomic_read(&file->f_count))
goto repeat;
// We have a file pointer, but it's in the process of being torn
// down but gem.mmap_singleton hasn't been cleared yet. Yield to
// make progress.
sched_yield();
goto repeat;
which is disgusting, but would probably work.
Note the "probably work". I'm handwaving: "something like the above".
Presumably not even worth doing - I assume a correct client always
just does a single mmap() before starting work.
Linus
More information about the Intel-gfx
mailing list