Re: [PATCH 1/2] Allow a kthread to declare that it calls task_work_run()

From: NeilBrown
Date: Mon Dec 04 2023 - 16:03:06 EST


On Mon, 04 Dec 2023, Jens Axboe wrote:
> On 12/3/23 6:36 PM, NeilBrown wrote:
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index e157efc54023..46d640b70ca9 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -1328,7 +1328,7 @@ static void mntput_no_expire(struct mount *mnt)
> >
> > if (likely(!(mnt->mnt.mnt_flags & MNT_INTERNAL))) {
> > struct task_struct *task = current;
> > - if (likely(!(task->flags & PF_KTHREAD))) {
> > + if (likely((task->flags & PF_RUNS_TASK_WORK))) {
>
> Extraneous parens here.

Thanks - and thanks to Matthew Wilcox too. Fixed.

>
> > diff --git a/kernel/task_work.c b/kernel/task_work.c
> > index 95a7e1b7f1da..aec19876e121 100644
> > --- a/kernel/task_work.c
> > +++ b/kernel/task_work.c
> > @@ -183,3 +183,4 @@ void task_work_run(void)
> > } while (work);
> > }
> > }
> > +EXPORT_SYMBOL(task_work_run);
>
> If we're exporting this, then I think that function needs a big
> disclaimer on exactly when it is safe to call it. And it most certainly
> needs to be a _GPL export.

I've added

* Can be used by a kernel thread but only when no locks are held and the
* thread won't be waited for by other code that might hold locks. It
* can be useful in the top-level loop of a file-serving thread to ensure
* files get closed promptly.

to the documentation comment.
It isn't clear to me what _GPL is appropriate, but maybe the rules
changed since last I looked..... are there rules?

My reasoning was that the call is effectively part of the user-space
ABI. A user-space process can call this trivially by invoking any
system call. The user-space ABI is explicitly a boundary which the GPL
does not cross. So it doesn't seem appropriate to prevent non-GPL
kernel code from doing something that non-GPL user-space code can
trivially do.

But if there are other strong opinions, or clearly documented rules that
contradict my opinion, I have not problem with adding _GPL.

Thanks,
NeilBrown


>
> --
> Jens Axboe
>
>