Re: linux-next: Tree for Jun 26 [ vfs | block | fuse (cpuidle) releated? ]

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Jun 26, 2013 at 05:36:03PM +0200, Sedat Dilek wrote:
> On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
> >> Dear Sedat Dilek,
> >>
> >> On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
> >>
> >> > [ TO/CC char-misc folks ]
> >> >
> >> > The CULPRIT commit [1] due to my git-bisecting is:
> >> >
> >> > commit 585d98e00ba7a5e2abe65f7a1eff631cb612289b
> >> > "char: misc: assign file->private_data in all cases"
> >> >
> >> > After reverting it, my system boots up fine again.
> >> >
> >> > Can someone from the char-misc folks look at that?
> >>
> >> Ok. My understanding is that the misc device registered by
> >> fs/fuse/dev.c:fuse_dev_init() makes the assumption that
> >> file->private_data == NULL when a misc device is opened. But I'm not
> >> sure to fully understand the code flow of the FUSE filesystem.
> >>
> >> And since it doesn't provide its own implementation of the ->open()
> >> operation, the misc infrastructure was leaving the file->private_data
> >> defined to NULL before my patch.
> >>
> >> With my patch, the file->private_data gets assigned unconditionally
> >> (regardless of whether the misc driver provides or does not provide a
> >> ->open() operation) which modifies the unwritten assumption that fuse
> >> was making about the initial value of file->private_data. I believe the
> >> assumption made by fuse over the initial value of this variable is a
> >> bit fragile.
> >>
> >> Maybe the FUSE code needs to be slightly adjusted to not make this
> >> assumption?
> >
> > As the FUSE code was working properly before this change, I think this
> > misc core change needs to be reverted, so I'll go do that in a bit.
> >
> 
> Good, sound reasonable.
> 
> I was not aware that char-misc and fuse code is so interwoven (hope
> this is the right word).

The fuse driver is a misc device, so the fuse code depends on the misc
core to work properly, that's the dependancy here.

I've now reverted this change, thanks again for the report and the quick
determination of the problem.

greg k-h