David Laight <David.Laight@xxxxxxxxxx> writes: > From: Eric W. Biederman >> Sent: 26 August 2021 23:14 > ... >> 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
