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'. Any flags associated with O_DENY_WRITE would need to be cleared synchronously in the close() rather then in any delayed fput(). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
