linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Chiappero, Marco" <marco.chiappero@intel.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Linux FS Devel" <linux-fsdevel@vger.kernel.org>
Cc: "Cabiddu, Giovanni" <giovanni.cabiddu@intel.com>
Subject: Correct debugfs file removal pattern
Date: Tue, 19 Jan 2021 21:27:36 +0000	[thread overview]
Message-ID: <DM5PR11MB1707D6FCF5F9CDF83174B83DE8A30@DM5PR11MB1707.namprd11.prod.outlook.com> (raw)

Hi,

I'm looking to expose some information through a debugfs file, however I'm not entirely clear with the correct steps for file removal upon module unloading. I'm asking this because I would expect debugfs_remove() to wait until every open file has been closed when using debugfs_create_file (not debugfs_create_file_unsafe), as per debugfs_file_put() documentation:

 * Up to a matching call to debugfs_file_put(), any successive call
 * into the file removing functions debugfs_remove() and
 * debugfs_remove_recursive() will block.

Unfortunately it's not what I'm seeing when removing the module with one file kept open (leading to a page fault when eventually closing the file). So, is this the expected behaviour? If so, what is the right approach for waiting, inotify or fsnotify? Any suggestion on what the best pattern would be?

Thank you,
Marco

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

                 reply	other threads:[~2021-01-19 21:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM5PR11MB1707D6FCF5F9CDF83174B83DE8A30@DM5PR11MB1707.namprd11.prod.outlook.com \
    --to=marco.chiappero@intel.com \
    --cc=giovanni.cabiddu@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).