On 10/18/19 8:40 AM, Jann Horn wrote: > On Fri, Oct 18, 2019 at 4:37 PM Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> On 10/18/19 8:34 AM, Jann Horn wrote: >>> On Fri, Oct 18, 2019 at 4:01 PM Jens Axboe <axboe@xxxxxxxxx> wrote: >>>> On 10/17/19 8:41 PM, Jann Horn wrote: >>>>> On Fri, Oct 18, 2019 at 4:01 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >>>>>> This is in preparation for adding opcodes that need to modify files >>>>>> in a process file table, either adding new ones or closing old ones. >>> [...] >>>> Updated patch1: >>>> >>>> http://git.kernel.dk/cgit/linux-block/commit/?h=for-5.5/io_uring-test&id=df6caac708dae8ee9a74c9016e479b02ad78d436 >>> >>> I don't understand what you're doing with old_files in there. In the >>> "s->files && !old_files" branch, "current->files = s->files" happens >>> without holding task_lock(), but current->files and s->files are also >>> the same already at that point anyway. And what's the intent behind >>> assigning stuff to old_files inside the loop? Isn't that going to >>> cause the workqueue to keep a modified current->files beyond the >>> runtime of the work? >> >> I simply forgot to remove the old block, it should only have this one: >> >> if (s->files && s->files != cur_files) { >> task_lock(current); >> current->files = s->files; >> task_unlock(current); >> if (cur_files) >> put_files_struct(cur_files); >> cur_files = s->files; >> } > > Don't you still need a put_files_struct() in the case where "s->files > == cur_files"? I want to hold on to the files for as long as I can, to avoid unnecessary shuffling of it. But I take it your worry here is that we'll be calling something that manipulates ->files? Nothing should do that, unless s->files is set. We didn't hide the workqueue ->files[] before this change either. -- Jens Axboe
