Re: debugfs vs. device removal

Path	csiph.com!1.us.feeder.erje.net!feeder.erje.net!2.eu.feeder.erje.net!news.unit0.net!news.panservice.it!diesel.cu.mi.it!bofh.it!news.nic.it!robomod
From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Newsgroups	linux.kernel
Subject	Re: debugfs vs. device removal
Date	Thu, 19 Jan 2017 19:30:01 +0100
Message-ID	<t1pDb-51e-5@gated-at.bofh.it> (permalink)
References	<t1n8n-3mv-37@gated-at.bofh.it> <t1ni2-3q2-35@gated-at.bofh.it> <t1nrI-3IU-15@gated-at.bofh.it> <t1oQP-4uu-37@gated-at.bofh.it>
X-Original-To	Omar Sandoval <osandov@osandov.com>
MIME-Version	1.0
Content-Type	text/plain; charset=us-ascii
Content-Disposition	inline
User-Agent	Mutt/1.7.2 (2016-11-26)
Sender	robomod@news.nic.it
List-ID	<linux-kernel.vger.kernel.org>
X-Mailing-List	linux-kernel@vger.kernel.org
Approved	robomod@news.nic.it
Lines	36
Organization	linux.* mail to news gateway
X-Original-Cc	Jiri Kosina <jikos@kernel.org>, linux-kernel@vger.kernel.org
X-Original-Date	Thu, 19 Jan 2017 19:03:52 +0100
X-Original-Message-ID	<20170119180352.GA29512@kroah.com>
X-Original-References	<20170119154841.GA6416@vader> <20170119155345.GA11660@kroah.com> <alpine.LSU.2.20.1701191700150.25515@cbobk.fhfr.pm> <20170119173350.GA7599@vader.DHCP.thefacebook.com>
X-Original-Sender	linux-kernel-owner@vger.kernel.org
Xref	csiph.com linux.kernel:1562991

Show key headers only | View raw

On Thu, Jan 19, 2017 at 09:33:50AM -0800, Omar Sandoval wrote:
> On Thu, Jan 19, 2017 at 05:03:48PM +0100, Jiri Kosina wrote:
> > On Thu, 19 Jan 2017, Greg Kroah-Hartman wrote:
> > 
> > > > In the block layer, we abuse sysfs to export some per-device debugging
> > > > information. I was looking into moving this to debugfs, but I realized
> > > > that debugfs doesn't have a mechanism to ensure that a file associated
> > > > with a device is safe to use when the device is removed. 
> > > 
> > > What do you mean by "safe"?  The race conditions where you remove a file
> > > and still have it open should all now be resolved in 4.8 and 4.9, di dwe
> > > miss something?
> > 
> > This is something else -- Omar is right, hid-debugfs interface is buggy. 
> > It basically doesn't synchronize the data dumping with device removal, so 
> > if device is removed and deallocated and the race is hit, it tries to 
> > dereference struct hid_device which has already been freed.
> 
> Yup, I'm talking about the case where I create a debugfs file and the
> data pointer is, say, a struct request_queue. If userspace calls open()
> on a debugfs file, then the device goes away, the struct request_queue
> is going to get freed and read() will blow up.
> 
> If we're talking about objects with a struct kobject (like struct
> request_queue), can we just grab an extra reference in open() and drop
> it in release()? This allows userspace to keep stuff pinned
> indefinitely, but debugfs is root-only and the use-case is usually just
> `cat`.

Again, debugfs got a bunch of changes in the 4.8 and 4.9 timeframe to
resolve this issue.  Try it and see with just a "normal" debugfs file
and see how it works.

thanks,

greg k-h

Thread

debugfs vs. device removal Omar Sandoval <osandov@osandov.com> - 2017-01-19 16:50 +0100
  Re: debugfs vs. device removal Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-19 17:00 +0100
    Re: debugfs vs. device removal Jiri Kosina <jikos@kernel.org> - 2017-01-19 17:10 +0100
      Re: debugfs vs. device removal Omar Sandoval <osandov@osandov.com> - 2017-01-19 18:40 +0100
        Re: debugfs vs. device removal Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-19 19:30 +0100
          Re: debugfs vs. device removal Omar Sandoval <osandov@osandov.com> - 2017-01-19 20:50 +0100

csiph-web