All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@amd.com>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling
Date: Fri, 8 Oct 2021 13:07:17 +0200	[thread overview]
Message-ID: <YWAmZdRwnAt6wh9B@kroah.com> (raw)
In-Reply-To: <87a6jjyhuo.fsf@intel.com>

On Fri, Oct 08, 2021 at 12:40:47PM +0300, Jani Nikula wrote:
> On Fri, 08 Oct 2021, Nirmoy Das <nirmoy.das@amd.com> wrote:
> > Debugfs API returns encoded error instead of NULL.
> > This patch cleanups drm debugfs error handling to
> > properly set dri and its minor's root dentry to NULL.
> >
> > Also do not error out if dri/minor debugfs directory
> > creation fails as a debugfs error is not a fatal error.
> 
> Cc: Greg
> 
> I thought this is the opposite of what Greg's been telling everyone to
> do with debugfs.

Yes, that is not good.

You should never care about the result of a debugfs_create* call.  Just
take the result, and if it is a directory, save it off to use it for
creating a file, no need to check anything.

And then throw it away, later, when you want to remove the directory,
look it up with a call to debugfs_lookup() and pass that to
debugfs_remove() (which does so recursively).

There should never be a need to save, or check, the result of any
debugfs call.  If so, odds are it is being used incorrectly.

thanks,

greg k-h

  reply	other threads:[~2021-10-08 11:07 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08  9:17 [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling Nirmoy Das
2021-10-08  9:17 ` Nirmoy Das
2021-10-08  9:17 ` [Intel-gfx] [PATCH 2/5] drm/i915: check dri root before debugfs init Nirmoy Das
2021-10-08  9:17   ` Nirmoy Das
2021-10-12  9:59   ` [Intel-gfx] " Wang, Zhi A
2021-10-12  9:59     ` Wang, Zhi A
2021-10-12 10:19     ` [Intel-gfx] " Das, Nirmoy
2021-10-12 10:19       ` Das, Nirmoy
2021-10-08  9:17 ` [Intel-gfx] [PATCH 3/5] drm/radeon: " Nirmoy Das
2021-10-08  9:17   ` Nirmoy Das
2021-10-08 10:23   ` [Intel-gfx] " Christian König
2021-10-08 10:23     ` Christian König
2021-10-08 10:34     ` [Intel-gfx] " Das, Nirmoy
2021-10-08 10:34       ` Das, Nirmoy
2021-10-08  9:17 ` [Intel-gfx] [PATCH 4/5] drm/armada: check dri/crtc " Nirmoy Das
2021-10-08  9:17   ` Nirmoy Das
2021-10-12 19:40   ` [Intel-gfx] " kernel test robot
2021-10-12 19:40     ` kernel test robot
2021-10-12 19:40     ` kernel test robot
2021-10-08  9:17 ` [Intel-gfx] [PATCH 5/5] drm/tegra: check root dentry " Nirmoy Das
2021-10-08  9:17   ` Nirmoy Das
2021-11-08  6:35   ` [Intel-gfx] " kernel test robot
2021-11-08  6:35     ` kernel test robot
2021-11-08  6:35     ` kernel test robot
2021-10-08  9:35 ` [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling Thomas Zimmermann
2021-10-08  9:35   ` Thomas Zimmermann
2021-10-08  9:40 ` [Intel-gfx] " Jani Nikula
2021-10-08 11:07   ` Greg KH [this message]
2021-10-08 12:08     ` Das, Nirmoy
     [not found]     ` <02fc9da3-ebac-2df1-3a54-d764b273f91b@amd.com>
2021-10-08 12:56       ` Fw: " Das, Nirmoy
     [not found]         ` <c4f1464d-19b6-04a3-e2d8-a153bfbb050a@amd.com>
     [not found]           ` <YWBfvILqkBQ8VSYc@kroah.com>
2021-10-11 14:19             ` Christian König
2021-10-11 14:53               ` Greg KH
2021-10-11 16:38                 ` Jani Nikula
2021-10-11 17:07                   ` Greg KH
2021-10-11 18:43                     ` Jani Nikula
2021-10-11 15:13               ` Das, Nirmoy
2021-10-08 14:09 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] " Patchwork
2021-10-08 14:10 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-08 19:18 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=YWAmZdRwnAt6wh9B@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nirmoy.das@amd.com \
    --cc=tzimmermann@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.