From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Subject: Re: linux-next: Tree for Jun 26 [ vfs | block | fuse (cpuidle) releated? ] Date: Wed, 26 Jun 2013 17:46:56 +0200 Message-ID: <20130626174656.6d9e2d2a@skate> References: <20130626172446.51f0bd5f@skate> <20130626153236.GA29455@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: sedat.dilek@gmail.com, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Al Viro , Jens Axboe , linux-fsdevel , Miklos Szeredi , fuse-devel@lists.sourceforge.net, Stephen Rothwell , Arnd Bergmann To: Greg Kroah-Hartman Return-path: In-Reply-To: <20130626153236.GA29455@kroah.com> Sender: linux-next-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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