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
next prev parent 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).