On Wed, Jun 26, 2013 at 10:06 AM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> Changes since 20130625:
>
> New tree: cpuinit
>
> The arm-mpidr tree gained a conflict against the arm tree.
>
> The net-next tree gained a conflict against the pm tree and a build
> failure for which I reverted a commit.
>
> The drm-intel tree gained a conflict against Linus' tree.
>
> The pinctrl tree gained a conflict against the regmap tree.
>
> The akpm tree lost a patch that turned up elsewhere and gained a conflict
> against the powerpc tree.
>
> The cpuinit tree lost a patch that turned up in the arc tree and gained a
> conflict against the arm-current tree.
>
> ----------------------------------------------------------------------------
>
[ CC some vfs | block | fuse maintainers ]
Since yesterday (next-20130625) and today (next-20130626) I can NOT
boot into my -next kernels.
I have seen two traces whereas I would like to concentrate on Trace #1.
Trace #1 (noted manually, read from the screen):
...
general_protection
spin_dump
spin_bug
do_raw_spin_lock
_raw_spin_locking
rwsem_spin_locking
rwsem_downwrite_failed
_rwsem_downwrite_failed
call_rwsem_downwrite_failed
downwrite
fuse_kill_sb_blk
deactivate_locked_super
mount_bdev
fuse_iget
fuse_mountblk
mount_fs
vfs_kern_mount
do_mount
__get_free_pages
copy_mount_options
SyS_mount
tracesys
Trace #2 (noted manually, read from the screen):
...
blablabla cpuidle
...
arch_trigger_all_cpu_backtrace_handler
I have attached my kernel-config.
Any hints/feedback welcome!
Regards,
- Sedat -
On Wed, Jun 26, 2013 at 11:48 AM, Sedat Dilek <[email protected]> wrote:
> On Wed, Jun 26, 2013 at 10:06 AM, Stephen Rothwell <[email protected]> wrote:
>> Hi all,
>>
>> Changes since 20130625:
>>
>> New tree: cpuinit
>>
>> The arm-mpidr tree gained a conflict against the arm tree.
>>
>> The net-next tree gained a conflict against the pm tree and a build
>> failure for which I reverted a commit.
>>
>> The drm-intel tree gained a conflict against Linus' tree.
>>
>> The pinctrl tree gained a conflict against the regmap tree.
>>
>> The akpm tree lost a patch that turned up elsewhere and gained a conflict
>> against the powerpc tree.
>>
>> The cpuinit tree lost a patch that turned up in the arc tree and gained a
>> conflict against the arm-current tree.
>>
>> ----------------------------------------------------------------------------
>>
>
> [ CC some vfs | block | fuse maintainers ]
>
> Since yesterday (next-20130625) and today (next-20130626) I can NOT
> boot into my -next kernels.
>
> I have seen two traces whereas I would like to concentrate on Trace #1.
>
> Trace #1 (noted manually, read from the screen):
> ...
> general_protection
> spin_dump
> spin_bug
> do_raw_spin_lock
> _raw_spin_locking
> rwsem_spin_locking
> rwsem_downwrite_failed
> _rwsem_downwrite_failed
> call_rwsem_downwrite_failed
> downwrite
> fuse_kill_sb_blk
> deactivate_locked_super
> mount_bdev
> fuse_iget
> fuse_mountblk
> mount_fs
> vfs_kern_mount
> do_mount
> __get_free_pages
> copy_mount_options
> SyS_mount
> tracesys
>
> Trace #2 (noted manually, read from the screen):
> ...
> blablabla cpuidle
> ...
> arch_trigger_all_cpu_backtrace_handler
>
> I have attached my kernel-config.
>
> Any hints/feedback welcome!
>
Just as a sidenote:
This is not a ***native*** Ubuntu/precise AMD64 installation - I am
using a WUBI environment.
- Sedat -
https://wiki.ubuntu.com/WubiGuide
> Regards,
> - Sedat -
On Wed, Jun 26, 2013 at 11:48 AM, Sedat Dilek <[email protected]> wrote:
> On Wed, Jun 26, 2013 at 10:06 AM, Stephen Rothwell <[email protected]> wrote:
>> Hi all,
>>
>> Changes since 20130625:
>>
>> New tree: cpuinit
>>
>> The arm-mpidr tree gained a conflict against the arm tree.
>>
>> The net-next tree gained a conflict against the pm tree and a build
>> failure for which I reverted a commit.
>>
>> The drm-intel tree gained a conflict against Linus' tree.
>>
>> The pinctrl tree gained a conflict against the regmap tree.
>>
>> The akpm tree lost a patch that turned up elsewhere and gained a conflict
>> against the powerpc tree.
>>
>> The cpuinit tree lost a patch that turned up in the arc tree and gained a
>> conflict against the arm-current tree.
>>
>> ----------------------------------------------------------------------------
>>
>
> [ CC some vfs | block | fuse maintainers ]
>
> Since yesterday (next-20130625) and today (next-20130626) I can NOT
> boot into my -next kernels.
>
> I have seen two traces whereas I would like to concentrate on Trace #1.
>
> Trace #1 (noted manually, read from the screen):
> ...
> general_protection
> spin_dump
> spin_bug
> do_raw_spin_lock
> _raw_spin_locking
> rwsem_spin_locking
> rwsem_downwrite_failed
> _rwsem_downwrite_failed
> call_rwsem_downwrite_failed
> downwrite
> fuse_kill_sb_blk
> deactivate_locked_super
> mount_bdev
> fuse_iget
> fuse_mountblk
> mount_fs
> vfs_kern_mount
> do_mount
> __get_free_pages
> copy_mount_options
> SyS_mount
> tracesys
>
> Trace #2 (noted manually, read from the screen):
> ...
> blablabla cpuidle
> ...
> arch_trigger_all_cpu_backtrace_handler
>
> I have attached my kernel-config.
>
> Any hints/feedback welcome!
>
[ 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?
Thanks.
NOTE: You also need [PATCH] Revert "kconfig: fix randomising choice
entries in presence of KCONFIG_ALLCONFIG".
- Sedat -
[1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=585d98e00ba7a5e2abe65f7a1eff631cb612289b
> Regards,
> - Sedat -
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?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Wed, Jun 26, 2013 at 5:24 PM, Thomas Petazzoni
<[email protected]> 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
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.
thanks,
greg k-h
On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
<[email protected]> 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).
- Sedat -
> thanks,
>
> greg k-h
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
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
> <[email protected]> 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
On Wed, Jun 26, 2013 at 7:15 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> 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
>> <[email protected]> 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.
>
All this early-testing results sometimes in nice use-cases/test-cases.
If I think of the IPC-MSG issue (fakeroot & 'make deb-pkg') I had in -next...
I have sent a patch to Linux-Testing-Project to enhance the IPC test-suite.
As a goodie I catched a BASHISM bug for dash shell in runltp script :-).
I forgot a bug-report for Debian's fakeroot... The shipped DEBUG
doc-file is outdated.
The harder part is to convince the maintainers that sth. is/went wrong :-).
Personally, I am happy when Friday's Linux-Next is "bug-free" for me.
- Sedat -
> greg k-h