All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@lip6.fr>
To: Nicolai Stange <nstange@suse.de>
Cc: Fabio Estevam <festevam@gmail.com>,
	Francisco Jerez <currojerez@riseup.net>,
	linux-pm@vger.kernel.org, Viresh Kumar <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	kbuild-all@01.org,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	0day robot <fengguang.wu@intel.com>, Len Brown <lenb@kernel.org>
Subject: Re: [kbuild-all] [PATCH] OPTIONAL: cpufreq/intel_pstate: fix debugfs_simple_attr.cocci warnings
Date: Fri, 30 Mar 2018 08:22:58 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1803300821330.2870@hadrien> (raw)
In-Reply-To: <87po3mxf73.fsf@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]



On Fri, 30 Mar 2018, Nicolai Stange wrote:

> Julia Lawall <julia.lawall@lip6.fr> writes:
>
> > On Thu, 29 Mar 2018, Fabio Estevam wrote:
> >
> >> Hi Julia,
> >>
> >> On Thu, Mar 29, 2018 at 4:12 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> >> >  Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
> >> >  for debugfs files.
> >> >
> >> > Semantic patch information:
> >> >  Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
> >> >  imposes some significant overhead as compared to
> >> >  DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
> >>
> >> Just curious: could you please expand on what "imposes some
> >> significant overhead" means?
> >
> > I don't know.  I didn't write this rule.  Nicolai, can you explain?
>
> From commit 49d200deaa68 ("debugfs: prevent access to removed files' private
> data"):
>
>     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.
>     [...]
>     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 [...]
>
> The additional overhead comes in terms of additional memory needed: for
> debugs files created through debugfs_create_file(), one such struct
> file_operations proxy is allocated for each struct file instantiation,
> c.f. full_proxy_open().
>
> This was needed to "repair" the ~1000 call sites without touching them.
>
> New debugfs users should make their file_operations removal aware
> themselves by means of DEFINE_DEBUGFS_ATTRIBUTE() and signal that fact to
> the debugfs core by instantiating them through
> debugfs_create_file_unsafe().
>
> See commit c64688081490 ("debugfs: add support for self-protecting
> attribute file fops") for further information.

Thanks.  Perhaps it would be good to add a reference to this commit in
the message generated by the semantic patch.

Would it be sufficient to just apply the semantic patch everywhere and
submit the patches?

julia

>
>
> Thanks,
>
> Nicolai
>
>
> --
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
>

  reply	other threads:[~2018-03-30  6:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-29 19:12 [PATCH] OPTIONAL: cpufreq/intel_pstate: fix debugfs_simple_attr.cocci warnings Julia Lawall
2018-03-29 19:11 ` Francisco Jerez
2018-03-29 19:31 ` [kbuild-all] " Fabio Estevam
2018-03-29 19:23   ` Francisco Jerez
2018-03-29 19:44   ` Julia Lawall
2018-03-30  6:14     ` Nicolai Stange
2018-03-30  6:22       ` Julia Lawall [this message]
2018-03-30 15:33         ` Fabio Estevam
2018-03-31  4:20         ` Nicolai Stange
2018-03-30  9:51 ` Rafael J. Wysocki

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=alpine.DEB.2.20.1803300821330.2870@hadrien \
    --to=julia.lawall@lip6.fr \
    --cc=currojerez@riseup.net \
    --cc=fengguang.wu@intel.com \
    --cc=festevam@gmail.com \
    --cc=kbuild-all@01.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nstange@suse.de \
    --cc=rjw@rjwysocki.net \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=viresh.kumar@linaro.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 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.