linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolai Stange <nicstange@gmail.com>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Brian Starkey <Brian.Starkey@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Nicolai Stange <nicstange@gmail.com>
Subject: Re: [PATCH] debugfs: Add proxy function for the mmap file operation
Date: Fri, 29 Jul 2016 19:35:02 +0200	[thread overview]
Message-ID: <87oa5gpcu1.fsf@gmail.com> (raw)
In-Reply-To: <20160729143459.2672-1-Liviu.Dudau@arm.com> (Liviu Dudau's message of "Fri, 29 Jul 2016 15:34:59 +0100")

Liviu Dudau <Liviu.Dudau@arm.com> writes:

> Add proxy function for the mmap file_operations hook under the
> full_proxy_fops structure. This is useful for providing a custom
> mmap routine in a driver's debugfs implementation.

I guess you've got some specific use case for mmap() usage on some new
debugfs file in mind?

Currently, there exist only two mmap providers:
  drivers/staging/android/sync_debug.c
  kernel/kcov.c

Both don't suffer from the lack of mmap support in the debugfs full proxy
implementation because they don't use it -- their files never go away
and thus, can be (and are) created via debugfs_create_file_unsafe().

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.


> Cc: Nicolai Stange <nicstange@gmail.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  fs/debugfs/file.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 592059f..d87148a 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -168,6 +168,10 @@ FULL_PROXY_FUNC(write, ssize_t, filp,
>  			loff_t *ppos),
>  		ARGS(filp, buf, size, ppos));
>  
> +FULL_PROXY_FUNC(mmap, int, filp,
> +		PROTO(struct file *filp, struct vm_area_struct *vma),
> +		ARGS(filp, vma));
> +


While this protects the call to ->mmap() itself against file removal
races, it doesn't protect anything possibly installed at vma->vm_ops
from that.

I'm fine with this as long as vma->vm_ops isn't set from ->mmap() ;).
At the very least, we should probably provide a Coccinelle script for
this. I'll try to put something together at the weekend or at the
beginning of next week (if you aren't faster).

Another option would be to add a check in the wrapping ->mmap() whether
the vma->vm_ops has been set from the wrapped ->mmap().
Greg, do you think such a runtime check would be a good thing to have?

Btw, it would certainly be possible to even support a custom vma->vm_ops
by proxying this one, too. However, we probably would have to SIGSEGV
userspace if ->fault() was called on a stale debugfs file. And since
nobody has asked for this feature yet, I don't think that it should be
implemented now.

Thanks,

Nicolai

  reply	other threads:[~2016-07-29 17:35 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 [this message]
2016-08-02 17:31   ` Nicolai Stange
2016-08-05 10:18     ` Brian Starkey
2016-08-05 11:11       ` Nicolai Stange
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=87oa5gpcu1.fsf@gmail.com \
    --to=nicstange@gmail.com \
    --cc=Brian.Starkey@arm.com \
    --cc=Liviu.Dudau@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).