lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130626171501.GA32056@kroah.com>
Date:	Wed, 26 Jun 2013 10:15:01 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Sedat Dilek <sedat.dilek@...il.com>
Cc:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Al Viro <viro@...iv.linux.org.uk>,
	Jens Axboe <axboe@...nel.dk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Miklos Szeredi <miklos@...redi.hu>,
	fuse-devel@...ts.sourceforge.net,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: linux-next: Tree for Jun 26 [ vfs | block | fuse (cpuidle)
 releated? ]

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@...uxfoundation.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ