David Laight [off-list ref] writes:

From: Eric W. Biederman

quoted

Sent: 26 August 2021 23:14

...

quoted

I also ran into this issue not too long ago when I refactored the
usermode_driver code.  My challenge was not being in userspace
the delayed fput was not happening in my kernel thread.  Which meant
that writing the file, then closing the file, then execing the file
consistently reported -ETXTBSY.

The kernel code wound up doing:
	/* Flush delayed fput so exec can open the file read-only */
	flush_delayed_fput();
	task_work_run();

As I read the code the delay for userspace file descriptors is
always done with task_work_add, so userspace should not hit
that kind of silliness, and should be able to actually close
the file descriptor before the exec.

If task_work_add ends up adding it to a task that is already
running on a different cpu, and that cpu takes a hardware
interrupt that takes some time and/or schedules the softint
code to run immediately the hardware interrupt completes
then it may well be possible for userspace to have 'issues'.

It it task_work_add(current).  Which punts the work to the return to
userspace.

Any flags associated with O_DENY_WRITE would need to be cleared
synchronously in the close() rather then in any delayed fput().

Eric