Received-SPF: pass (google.com: domain of linux-nfs+bounces-114-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0
From: "NeilBrown" <neilb@suse.de>
To: "Al Viro" <viro@zeniv.linux.org.uk>
Cc: "Christian Brauner" <brauner@kernel.org>, "Jens Axboe" <axboe@kernel.dk>,
 "Oleg Nesterov" <oleg@redhat.com>, "Chuck Lever" <chuck.lever@oracle.com>,
 "Jeff Layton" <jlayton@kernel.org>, "Ingo Molnar" <mingo@redhat.com>,
 "Peter Zijlstra" <peterz@infradead.org>, "Juri Lelli" <juri.lelli@redhat.com>,
 "Vincent Guittot" <vincent.guittot@linaro.org>, linux-fsdevel@vger.kernel.org,
 linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH/RFC] core/nfsd: allow kernel threads to use task_work.
In-reply-to: <20231127223054.GL38156@ZenIV>
References: <170112272125.7109.6245462722883333440@noble.neil.brown.name>,
 <20231127223054.GL38156@ZenIV>
Date: Tue, 28 Nov 2023 09:43:30 +1100
Message-id: <170112501017.7109.11367576354770728388@noble.neil.brown.name>

On Tue, 28 Nov 2023, Al Viro wrote:
> On Tue, Nov 28, 2023 at 09:05:21AM +1100, NeilBrown wrote:
>=20
> > A simple way to fix this is to treat nfsd threads like normal processes
> > for task_work.  Thus the pending files are queued for the thread, and
> > the same thread finishes the work.
> >=20
> > Currently KTHREADs are assumed never to call task_work_run().  With this
> > patch that it still the default but it is implemented by storing the
> > magic value TASK_WORKS_DISABLED in ->task_works.  If a kthread, such as
> > nfsd, will call task_work_run() periodically, it sets ->task_works
> > to NULL to indicate this.
>=20
> >  		svc_recv(rqstp);
> >  		validate_process_creds();
> > +		if (task_work_pending(current))
> > +			task_work_run();
>=20
> What locking environment and call chain do you have here?  And what happens=
 if
> you get something stuck in ->release()?

No locking. This is in the top level function of the kthread.
A ->release function that waits for an NFS filesystem to flush out data
through a filesystem exported by this nfsd might hit problems.
But that really requires us nfs-exporting and nfs filesystem which is
loop-back mounted.  While we do support nfs-reexport and nfs-loop-back
mounts, I don't think we make any pretence of supporting a combination.

Is that the sort of thing you were think of?

>=20
> > =20
> >  	p->pdeath_signal =3D 0;
> > -	p->task_works =3D NULL;
> > +	p->task_works =3D args->kthread ? TASK_WORKS_DISABLED : NULL;
>=20
> Umm... why not have them set (by helper in kernel/task_work.c) to
> &work_exited?  Then the task_work_run parts wouldn't be needed at all...
>=20

I hadn't tried to understand what work_exited was for - but now I see
that its purpose is precisely to block further work from being queued -
exactly what I need.
Thanks - I make that change for a v2.

I've realised that I'll also need to change the flush_delayed_fput() in
fsd_file_close_inode_sync() to task_work_run().

Thanks,
NeilBrown