Dear Greg Kroah-Hartman, On Wed, 26 Jun 2013 08:32:36 -0700, Greg Kroah-Hartman wrote: > > 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. Yes, sure, that's the right immediate action to take. Long term, I believe the FUSE code seems to be making a fragile assumption, and that might require some additional investigation. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
