Messages in this thread | | | Date | Tue, 27 Jun 2023 18:36:22 +0100 | From | Matthew Wilcox <> | Subject | Re: [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file |
| |
On Tue, Jun 27, 2023 at 10:03:15AM -0700, Suren Baghdasaryan wrote: > On Mon, Jun 26, 2023 at 11:25 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Mon, Jun 26, 2023 at 01:17:12PM -0700, Suren Baghdasaryan wrote: > > > kernfs_ops.release operation can be called from kernfs_drain_open_files > > > which is not tied to the file's real lifecycle. Introduce a new kernfs_ops > > > free operation which is called only when the last fput() of the file is > > > performed and therefore is strictly tied to the file's lifecycle. This > > > operation will be used for freeing resources tied to the file, like > > > waitqueues used for polling the file. > > > > This is confusing, shouldn't release be the "last" time the file is > > handled and then all resources attached to it freed? Why do we need > > another callback, shouldn't release handle this? > > That is what I thought too but apparently kernfs_drain_open_files() > can also cause ops->release to be called while the file keeps on > living (see details here: > https://lore.kernel.org/all/CAJuCfpFZ3B4530TgsSHqp5F_gwfrDujwRYewKReJru==MdEHQg@mail.gmail.com/#t).
If we're splitting these two functions apart, can we use the same naming as the VFS please?
``flush`` called by the close(2) system call to flush a file
``release`` called when the last reference to an open file is closed
| |