Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752022Ab3FZPbQ (ORCPT ); Wed, 26 Jun 2013 11:31:16 -0400 Received: from mail-we0-f175.google.com ([74.125.82.175]:43340 "EHLO mail-we0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751498Ab3FZPbP (ORCPT ); Wed, 26 Jun 2013 11:31:15 -0400 MIME-Version: 1.0 Reply-To: sedat.dilek@gmail.com In-Reply-To: <20130626172446.51f0bd5f@skate> References: <20130626172446.51f0bd5f@skate> Date: Wed, 26 Jun 2013 17:31:13 +0200 Message-ID: Subject: Re: linux-next: Tree for Jun 26 [ vfs | block | fuse (cpuidle) releated? ] From: Sedat Dilek To: Thomas Petazzoni Cc: 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 , Greg Kroah-Hartman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2133 Lines: 62 On Wed, Jun 26, 2013 at 5:24 PM, 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? > Hi Thomas, ( Fast response like a "free electron". ) That's a question for Miklos :-). As said I have here a WUBI (fuse/loop/ext4) installation which is not quite common, but catched some nice bugs people normally do not hit. I can only confirm your change let's me no more boot into my system. - Sedat - > 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/