1. 08 Apr, 2017 1 commit
  2. 02 Feb, 2017 1 commit
    • Omar Sandoval's avatar
      debugfs: add debugfs_lookup() · a7c5437b
      Omar Sandoval authored
      We don't always have easy access to the dentry of a file or directory we
      created in debugfs. Add a helper which allows us to get a dentry we
      previously created.
      
      The motivation for this change is a problem with blktrace and the blk-mq
      debugfs entries introduced in 07e4fead ("blk-mq: create debugfs
      directory tree"). Namely, in some cases, the directory that blktrace
      needs to create may already exist, but in other cases, it may not. We
      _could_ rely on a bunch of implied knowledge to decide whether to create
      the directory or not, but it's much cleaner on our end to just look it
      up.
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      a7c5437b
  3. 01 Feb, 2017 1 commit
    • Eric W. Biederman's avatar
      fs: Better permission checking for submounts · 93faccbb
      Eric W. Biederman authored
      To support unprivileged users mounting filesystems two permission
      checks have to be performed: a test to see if the user allowed to
      create a mount in the mount namespace, and a test to see if
      the user is allowed to access the specified filesystem.
      
      The automount case is special in that mounting the original filesystem
      grants permission to mount the sub-filesystems, to any user who
      happens to stumble across the their mountpoint and satisfies the
      ordinary filesystem permission checks.
      
      Attempting to handle the automount case by using override_creds
      almost works.  It preserves the idea that permission to mount
      the original filesystem is permission to mount the sub-filesystem.
      Unfortunately using override_creds messes up the filesystems
      ordinary permission checks.
      
      Solve this by being explicit that a mount is a submount by introducing
      vfs_submount, and using it where appropriate.
      
      vfs_submount uses a new mount internal mount flags MS_SUBMOUNT, to let
      sget and friends know that a mount is a submount so they can take appropriate
      action.
      
      sget and sget_userns are modified to not perform any permission checks
      on submounts.
      
      follow_automount is modified to stop using override_creds as that
      has proven problemantic.
      
      do_mount is modified to always remove the new MS_SUBMOUNT flag so
      that we know userspace will never by able to specify it.
      
      autofs4 is modified to stop using current_real_cred that was put in
      there to handle the previous version of submount permission checking.
      
      cifs is modified to pass the mountpoint all of the way down to vfs_submount.
      
      debugfs is modified to pass the mountpoint all of the way down to
      trace_automount by adding a new parameter.  To make this change easier
      a new typedef debugfs_automount_t is introduced to capture the type of
      the debugfs automount function.
      
      Cc: stable@vger.kernel.org
      Fixes: 069d5ac9 ("autofs:  Fix automounts by using current_real_cred()->uid")
      Fixes: aeaa4a79 ("fs: Call d_automount with the filesystems creds")
      Reviewed-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Reviewed-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      93faccbb
  4. 11 Jan, 2017 1 commit
  5. 04 Nov, 2016 1 commit
  6. 28 Oct, 2016 1 commit
    • Arnd Bergmann's avatar
      debugfs: improve DEFINE_DEBUGFS_ATTRIBUTE for !CONFIG_DEBUG_FS · 7f847dd3
      Arnd Bergmann authored
      The slp_s0_residency_usec debugfs file currently uses
      DEFINE_DEBUGFS_ATTRIBUTE(), but that macro cannot really be used to
      define files outside of the debugfs code, as it has no reference to
      the get/set functions if CONFIG_DEBUG_FS is not defined:
      
      drivers/platform/x86/intel_pmc_core.c:80:12: error: ‘pmc_core_dev_state_get’ defined but not used [-Werror=unused-function]
      
      This fixes the macro to always contain the reference, and instead rely
      on the stubbed-out debugfs_create_file to not actually refer to
      its arguments so the compiler can still drop the reference.
      This works because the attribute definition is always 'static',
      and the dead-code removal silently drops all static symbols
      that are not used.
      
      Fixes: c6468808 ("debugfs: add support for self-protecting attribute file fops")
      Fixes: df2294fb ("intel_pmc_core: Convert to DEFINE_DEBUGFS_ATTRIBUTE")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      [nicstange@gmail.com: Add dummy implementations of debugfs_attr_read() and
        debugfs_attr_write() in order to protect against possibly broken dead
        code elimination and to improve readability.
        Correct CONFIG_DEBUGFS_FS -> CONFIG_DEBUG_FS typo in changelog.]
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f847dd3
  7. 21 Sep, 2016 1 commit
  8. 12 Apr, 2016 3 commits
    • Nicolai Stange's avatar
      debugfs: add support for self-protecting attribute file fops · c6468808
      Nicolai Stange authored
      In order to protect them against file removal issues, debugfs_create_file()
      creates a lifetime managing proxy around each struct file_operations
      handed in.
      
      In cases where this struct file_operations is able to manage file lifetime
      by itself already, the proxy created by debugfs is a waste of resources.
      
      The most common class of struct file_operations given to debugfs are those
      defined by means of the DEFINE_SIMPLE_ATTRIBUTE() macro.
      
      Introduce a DEFINE_DEBUGFS_ATTRIBUTE() macro to allow any
      struct file_operations of this class to be easily made file lifetime aware
      and thus, to be operated unproxied.
      
      Specifically, introduce debugfs_attr_read() and debugfs_attr_write()
      which wrap simple_attr_read() and simple_attr_write() under the protection
      of a debugfs_use_file_start()/debugfs_use_file_finish() pair.
      
      Make DEFINE_DEBUGFS_ATTRIBUTE() set the defined struct file_operations'
      ->read() and ->write() members to these wrappers.
      
      Export debugfs_create_file_unsafe() in order to allow debugfs users to
      create their files in non-proxying operation mode.
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6468808
    • Nicolai Stange's avatar
      debugfs: prevent access to removed files' private data · 49d200de
      Nicolai Stange authored
      Upon return of debugfs_remove()/debugfs_remove_recursive(), it might
      still be attempted to access associated private file data through
      previously opened struct file objects. If that data has been freed by
      the caller of debugfs_remove*() in the meanwhile, the reading/writing
      process would either encounter a fault or, if the memory address in
      question has been reassigned again, unrelated data structures could get
      overwritten.
      
      However, since debugfs files are seldomly removed, usually from module
      exit handlers only, the impact is very low.
      
      Currently, there are ~1000 call sites of debugfs_create_file() spread
      throughout the whole tree and touching all of those struct file_operations
      in order to make them file removal aware by means of checking the result of
      debugfs_use_file_start() from within their methods is unfeasible.
      
      Instead, wrap the struct file_operations by a lifetime managing proxy at
      file open:
      - In debugfs_create_file(), the original fops handed in has got stashed
        away in ->d_fsdata already.
      - In debugfs_create_file(), install a proxy file_operations factory,
        debugfs_full_proxy_file_operations, at ->i_fop.
      
      This proxy factory has got an ->open() method only. It carries out some
      lifetime checks and if successful, dynamically allocates and sets up a new
      struct file_operations proxy at ->f_op. Afterwards, it forwards to the
      ->open() of the original struct file_operations in ->d_fsdata, if any.
      
      The dynamically set up proxy at ->f_op has got a lifetime managing wrapper
      set for each of the methods defined in the original struct file_operations
      in ->d_fsdata.
      
      Its ->release()er frees the proxy again and forwards to the original
      ->release(), if any.
      
      In order not to mislead the VFS layer, it is strictly necessary to leave
      those fields blank in the proxy that have been NULL in the original
      struct file_operations also, i.e. aren't supported. This is why there is a
      need for dynamically allocated proxies. The choice made not to allocate a
      proxy instance for every dentry at file creation, but for every
      struct file object instantiated thereof is justified by the expected usage
      pattern of debugfs, namely that in general very few files get opened more
      than once at a time.
      
      The wrapper methods set in the struct file_operations implement lifetime
      managing by means of the SRCU protection facilities already in place for
      debugfs:
      They set up a SRCU read side critical section and check whether the dentry
      is still alive by means of debugfs_use_file_start(). If so, they forward
      the call to the original struct file_operation stored in ->d_fsdata, still
      under the protection of the SRCU read side critical section.
      This SRCU read side critical section prevents any pending debugfs_remove()
      and friends to return to their callers. Since a file's private data must
      only be freed after the return of debugfs_remove(), the ongoing proxied
      call is guarded against any file removal race.
      
      If, on the other hand, the initial call to debugfs_use_file_start() detects
      that the dentry is dead, the wrapper simply returns -EIO and does not
      forward the call. Note that the ->poll() wrapper is special in that its
      signature does not allow for the return of arbitrary -EXXX values and thus,
      POLLHUP is returned here.
      
      In order not to pollute debugfs with wrapper definitions that aren't ever
      needed, I chose not to define a wrapper for every struct file_operations
      method possible. Instead, a wrapper is defined only for the subset of
      methods which are actually set by any debugfs users.
      Currently, these are:
      
        ->llseek()
        ->read()
        ->write()
        ->unlocked_ioctl()
        ->poll()
      
      The ->release() wrapper is special in that it does not protect the original
      ->release() in any way from dead files in order not to leak resources.
      Thus, any ->release() handed to debugfs must implement file lifetime
      management manually, if needed.
      For only 33 out of a total of 434 releasers handed in to debugfs, it could
      not be verified immediately whether they access data structures that might
      have been freed upon a debugfs_remove() return in the meanwhile.
      
      Export debugfs_use_file_start() and debugfs_use_file_finish() in order to
      allow any ->release() to manually implement file lifetime management.
      
      For a set of common cases of struct file_operations implemented by the
      debugfs_core itself, future patches will incorporate file lifetime
      management directly within those in order to allow for their unproxied
      operation. Rename the original, non-proxying "debugfs_create_file()" to
      "debugfs_create_file_unsafe()" and keep it for future internal use by
      debugfs itself. Factor out code common to both into the new
      __debugfs_create_file().
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49d200de
    • Nicolai Stange's avatar
      debugfs: prevent access to possibly dead file_operations at file open · 9fd4dcec
      Nicolai Stange authored
      Nothing prevents a dentry found by path lookup before a return of
      __debugfs_remove() to actually get opened after that return. Now, after
      the return of __debugfs_remove(), there are no guarantees whatsoever
      regarding the memory the corresponding inode's file_operations object
      had been kept in.
      
      Since __debugfs_remove() is seldomly invoked, usually from module exit
      handlers only, the race is hard to trigger and the impact is very low.
      
      A discussion of the problem outlined above as well as a suggested
      solution can be found in the (sub-)thread rooted at
      
        http://lkml.kernel.org/g/20130401203445.GA20862@ZenIV.linux.org.uk
        ("Yet another pipe related oops.")
      
      Basically, Greg KH suggests to introduce an intermediate fops and
      Al Viro points out that a pointer to the original ones may be stored in
      ->d_fsdata.
      
      Follow this line of reasoning:
      - Add SRCU as a reverse dependency of DEBUG_FS.
      - Introduce a srcu_struct object for the debugfs subsystem.
      - In debugfs_create_file(), store a pointer to the original
        file_operations object in ->d_fsdata.
      - Make debugfs_remove() and debugfs_remove_recursive() wait for a
        SRCU grace period after the dentry has been delete()'d and before they
        return to their callers.
      - Introduce an intermediate file_operations object named
        "debugfs_open_proxy_file_operations". It's ->open() functions checks,
        under the protection of a SRCU read lock, whether the dentry is still
        alive, i.e. has not been d_delete()'d and if so, tries to acquire a
        reference on the owning module.
        On success, it sets the file object's ->f_op to the original
        file_operations and forwards the ongoing open() call to the original
        ->open().
      - For clarity, rename the former debugfs_file_operations to
        debugfs_noop_file_operations -- they are in no way canonical.
      
      The choice of SRCU over "normal" RCU is justified by the fact, that the
      former may also be used to protect ->i_private data from going away
      during the execution of a file's readers and writers which may (and do)
      sleep.
      
      Finally, introduce the fs/debugfs/internal.h header containing some
      declarations internal to the debugfs implementation.
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9fd4dcec
  9. 08 Feb, 2016 1 commit
  10. 18 Oct, 2015 1 commit
  11. 04 Oct, 2015 1 commit
  12. 20 Jul, 2015 1 commit
  13. 11 May, 2015 1 commit
  14. 17 Feb, 2015 1 commit
  15. 26 Jan, 2015 1 commit
  16. 25 Jan, 2015 1 commit
  17. 30 Nov, 2014 1 commit
  18. 27 Nov, 2014 1 commit
  19. 05 Nov, 2014 1 commit
  20. 03 Oct, 2013 1 commit
  21. 28 Aug, 2013 1 commit
  22. 03 Jun, 2013 1 commit
  23. 18 Jan, 2013 1 commit
  24. 17 Apr, 2012 1 commit
  25. 21 Mar, 2012 1 commit
  26. 04 Jan, 2012 1 commit
  27. 18 Nov, 2011 2 commits
  28. 20 May, 2010 1 commit
  29. 24 Sep, 2009 1 commit
  30. 23 Mar, 2009 1 commit
  31. 27 Jan, 2009 1 commit
  32. 21 Jan, 2009 1 commit
  33. 07 Jan, 2009 1 commit
  34. 22 Jul, 2008 1 commit
    • Haavard Skinnemoen's avatar
      debugfs: Implement debugfs_remove_recursive() · 9505e637
      Haavard Skinnemoen authored
      debugfs_remove_recursive() will remove a dentry and all its children.
      Drivers can use this to zap their whole debugfs tree so that they don't
      need to keep track of every single debugfs dentry they created.
      
      It may fail to remove the whole tree in certain cases:
      
      sh-3.2# rmmod atmel-mci < /sys/kernel/debug/mmc0/ios/clock
      mmc0: card b368 removed
      atmel_mci atmel_mci.0: Lost dma0chan1, falling back to PIO
      sh-3.2# ls /sys/kernel/debug/mmc0/
      ios
      
      But I'm not sure if that case can be handled in any sane manner.
      Signed-off-by: default avatarHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Cc: Pierre Ossman <drzeus-list@drzeus.cx>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9505e637
  35. 19 Jul, 2008 1 commit
  36. 04 Mar, 2008 1 commit
  37. 12 Oct, 2007 1 commit