linux-kernel - Re: [PATCH] debugfs: Add proxy function for the mmap file operation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160901125039.GA26936@e106497-lin.cambridge.arm.com>
Date:   Thu, 1 Sep 2016 13:50:39 +0100
From:   Liviu Dudau <Liviu.Dudau@....com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Nicolai Stange <nicstange@...il.com>,
        Brian Starkey <brian.starkey@....com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] debugfs: Add proxy function for the mmap file operation

On Thu, Sep 01, 2016 at 08:19:33AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 31, 2016 at 04:23:52PM +0100, Liviu Dudau wrote:
> > On Wed, Aug 31, 2016 at 03:07:49PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Aug 05, 2016 at 01:11:45PM +0200, Nicolai Stange wrote:
> > > > Brian Starkey <brian.starkey@....com> writes:
> > > > 
> > > > > On Tue, Aug 02, 2016 at 07:31:36PM +0200, Nicolai Stange wrote:
> > > > >>Nicolai Stange <nicstange@...il.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.
> > > 
> > > Ugh, mmap in debugfs, that's funny.  And sad...
> > 
> > Yeah.
> > 
> > While our need for the mmap-ing the debugfs entry is at best a temporary
> > option and a hack, I would be interested to know what alternatives could
> > be used to read a large amount of data that does not need the seq_operations
> > API? The out-of-tree proof-of-concept code that we have to interact with
> > a memory write engine needs to be able to access the output buffer from
> > userspace, but that output buffer is created by the kernel KMS driver.
> 
> What type of debugging do you need this for?

Taking snapshots of a composition scene using the KMS driver for Mali DP.

> 
> A binary sysfs attribute also might work well for you, on the device
> that you are talking to, but if not, yeah, mmap on debugfs will work
> just fine, seems to be the best fit.

We felt sysfs gives a whiff of official support for the feature, while in reality
is a stop gap until we work out the V4L2 functionality to do the same thing.

Best regards,
Liviu

> 
> thanks,
> 
> greg k-h
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯