On Tue, Jun 27, 2023 at 1:24 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> On Mon, Jun 26, 2023 at 10:31:49AM -1000, Tejun Heo wrote:
> > On Mon, Jun 26, 2023 at 01:17:12PM -0700, Suren Baghdasaryan wrote:
> > > diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
> > > index 73f5c120def8..a7e404ff31bb 100644
> > > --- a/include/linux/kernfs.h
> > > +++ b/include/linux/kernfs.h
> > > @@ -273,6 +273,11 @@ struct kernfs_ops {
> > > */
> > > int (*open)(struct kernfs_open_file *of);
> > > void (*release)(struct kernfs_open_file *of);
> > > + /*
> > > + * Free resources tied to the lifecycle of the file, like a
> > > + * waitqueue used for polling.
> > > + */
> > > + void (*free)(struct kernfs_open_file *of);
> >
> > I think this can use a bit more commenting - ie. explain that release may be
> > called earlier than the actual freeing of the file and how that can lead to
> > problems. Othre than that, looks fine to me.
>
> It seems the more natural thing to do would be to introduce a ->drain()
> operation and order it before ->release(), no?
I assume you mean we should add a ->drain() operation and call it when
kernfs_drain_open_files() causes kernfs_release_file()? That would
work but if any existing release() handler counts on the current
behavior (release() being called while draining) then we should find
and fix these. Hopefully they don't really depend on the current
behavior but I dunno.
