linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolai Stange <nicstange@gmail.com>
To: Brian Starkey <brian.starkey@arm.com>
Cc: Nicolai Stange <nicstange@gmail.com>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] debugfs: Add proxy function for the mmap file operation
Date: Fri, 05 Aug 2016 13:11:45 +0200	[thread overview]
Message-ID: <8760rfzczy.fsf@gmail.com> (raw)
In-Reply-To: <20160805101849.GA29995@e106950-lin.cambridge.arm.com> (Brian Starkey's message of "Fri, 5 Aug 2016 11:18:49 +0100")

Brian Starkey <brian.starkey@arm.com> writes:

> On Tue, Aug 02, 2016 at 07:31:36PM +0200, Nicolai Stange wrote:
>>Nicolai Stange <nicstange@gmail.com> writes:
>>> However, if you wish to have some mmapable debugfs file which *can* go
>>> away, introducing mmap support in the debugfs full proxy is perfectly
>>> valid. But please see below.
>>
>>Assuming that you've got such a use case, please consider resending your
>>patch along with the Cocci script below (and the Coccinelle team CC'ed,
>>of course). If OTOH your mmapable debugfs files are never removed, just
>>drop this message and use debugfs_create_file_unsafe() instead.
>
> So we do have an implementation using this, but it's likely we will
> keep it out-of-tree (it's a stop-gap until we can get a non-debugfs
> implementation of the functionality into mainline).
>
> Do you think it's worth merging this (and your cocci script) anyway to
> save someone else doing the same thing later?

I personally think that having ->mmap() support in debugfs would be a
good thing to have in general and I expect there to be some further
demand in the future.

But I also think that it is a little bit fragile in the current state:
how many people actually run the Cocci scripts on their changes? AFAICT,
even the kbuild test robot doesn't do this. And after all, the Cocci
script I provided could very well miss some obfuscated writes to
vma->vm_ops: if they aren't done from ->mmap() themselves, but from some
helper function invoked therein, for example.

I would personally prefer a hand coded full_proxy_mmap() which WARN()s
if the proxied ->mmap() changes vma->vm_ops:
- this would add an extra safety net
- ->mmap() for debugfs files isn't performance critical
- and lastly, we're already doing something similar to this in
  open_proxy_open().

But in the end, it's not mine but Greg K-H's opinion that matters here...

Thanks,

Nicolai

  reply	other threads:[~2016-08-05 11:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29 14:34 [PATCH] debugfs: Add proxy function for the mmap file operation Liviu Dudau
2016-07-29 17:35 ` Nicolai Stange
2016-08-02 17:31   ` Nicolai Stange
2016-08-05 10:18     ` Brian Starkey
2016-08-05 11:11       ` Nicolai Stange [this message]
2016-08-31 13:07         ` Greg Kroah-Hartman
2016-08-31 15:23           ` Liviu Dudau
2016-09-01  6:19             ` Greg Kroah-Hartman
2016-09-01 12:50               ` Liviu Dudau
2016-09-01 14:43                 ` Greg Kroah-Hartman

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=8760rfzczy.fsf@gmail.com \
    --to=nicstange@gmail.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=brian.starkey@arm.com \
    --cc=gregkh@linuxfoundation.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).