Re: Yet another pipe related oops.

[Greg Kroah-Hartman]

On Mon, Apr 01, 2013 at 09:34:46PM +0100, Al Viro wrote:
> On Wed, Mar 27, 2013 at 05:45:06PM +0000, Al Viro wrote:
> > We shouldn't, at least not for something that has been successfully
> > opened.  I've a patch series cleaning that up a bit in the local
> > queue; will check for bitrot and throw into for-next.
> 
> Egads...  OK, that has gone more than slightly out of control - right now
> vfs.git#for-next is at 106 commits, -3.6KLoC balance and *still* hadn't
> reached the ->f_op part of that work ;-/  OTOH, procfs-related code got
> a lot cleaner and we actually have a chance to make the guts of proc_dir_entry
> private to fs/proc now...  I'll cull the outright bug fixes into for-linus
> and push it your way...
> 
> The thing that really worries me is debugfs; that fscker sets whatever
> file_operations it's got from the driver that registered a file there
> and sticks that into ->i_fop.  When we try to open() that, we get
> try_module_get() ->i_fop->owner; so far, so good, but what if the driver
> has just been removed *and* file_operations instance we are looking at
> has already been freed?
> 
> IOW, how do we deal with a race between attempt to open a debugfs file and
> its removal on driver unload?  Greg?

Hm, I thought the i_fop->owner thing would be the needed protection, but
I guess you are right, it will not.  I guess we need to do what
character devices do and have an "intermediate" fops in order to protect
this.  Would that work?

As module removal never happens unless an admin does it by hand, it's
not a "real" issue that can be triggered by anyone easily, thankfully.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/