kernel BUG at fs/reiser4/block_alloc.c:151

kernel BUG at fs/reiser4/block_alloc.c:151

[Marcin Baczyński]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Hi,
I'm attaching a trace of kernel BUG that Firefox hits. It's 100% reproducible,
every time I start the browser it hits the bug within several seconds, then
whole system hangs. However I've never triggered the problem with any other
application.
I've tested 2.6.37-gentoo-hardened + reiser4 patch, and 2.6.36-zen kernels
and both are affected.
I'm happy to test patches or provide more info if needed.

Thanks,
Marcin

[-- Attachment #2: trace.txt --]
[-- Type: text/plain, Size: 2591 bytes --]

------------[ cut here ]------------
kernel BUG at fs/reiser4/block_alloc.c:151!
invalid opcode: 0000 [#1] PREEMPT SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1/status
CPU 2 
Modules linked in: [last unloaded: microcode]

Pid: 2545, comm: firefox Tainted: G        W   2.6.37-hardened-r1-gentoo #4 1423/HP ProBook 4320s
RIP: 0010:[<ffffffff81141a4f>]  [<ffffffff81141a4f>] sub_from_ctx_grabbed.clone.8+0xf/0x20
RSP: 0018:ffff88018574ba10  EFLAGS: 00010297
RAX: 0000000000000000 RBX: ffff8801bad17000 RCX: 000000000000c4c3
RDX: 000000000010010d RSI: 0000000000000001 RDI: ffff8801baa3b7b0
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
R10: 00000000ffffff02 R11: 00000000ffffff02 R12: ffff8801b79c48c0
R13: 0000000000000002 R14: ffff88018574baa8 R15: 0000000000000001
FS:  000003649e3b4700(0000) GS:ffff8800bad00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000364c0067000 CR3: 0000000001532000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process firefox (pid: 2545, threadinfo ffff88018574a000, task ffff8801928e42b0)
Stack:
 ffffffff81142782 ffff8801abaf9980 ffff88018574bc98 ffff8801abaf99d0
 ffffffff81144c54 ffff8801b9c0aa90 ffff8801b79c48c0 ffff8801abaf9980
 ffffffff81144d31 ffff8801b9c0aa80 ffff88018574bc98 ffff8801a7848ac8
Call Trace:
 [<ffffffff81142782>] ? grabbed2flush_reserved_nolock+0x42/0xa0
 [<ffffffff81144c54>] ? jnode_make_dirty_locked+0xe4/0x190
 [<ffffffff81144d31>] ? znode_make_dirty+0x31/0xe0
 [<ffffffff81166a69>] ? find_disk_cluster+0x359/0x390
 [<ffffffff8117511c>] ? do_readpage_ctail+0xdc/0x570
 [<ffffffff81166f7d>] ? prepare_logical_cluster+0x23d/0x760
 [<ffffffff81164462>] ? set_window.clone.62+0x72/0xc0
 [<ffffffff811629cc>] ? write_dispatch_hook+0x2c/0x130
 [<ffffffff8116847f>] ? do_write_cryptcompress+0x1cf/0x6b0
 [<ffffffff81168db5>] ? write_cryptcompress+0xa5/0xf0
 [<ffffffff81162bf2>] ? reiser4_write_careful+0xe2/0x500
 [<ffffffff810d40e4>] ? vfs_write+0x104/0x1e0
 [<ffffffff810d447e>] ? sys_write+0x4e/0x90
 [<ffffffff8100286b>] ? system_call_fastpath+0x16/0x1b
Code: 75 15 48 09 d0 48 8b 6c 24 10 48 89 03 48 8b 5c 24 08 48 83 c4 18 c3 0f 0b 0f 1f 00 48 8b 07 48 39 f0 72 07 48 29 f0 48 89 07 c3 <0f> 0b 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 18 
RIP  [<ffffffff81141a4f>] sub_from_ctx_grabbed.clone.8+0xf/0x20
 RSP <ffff88018574ba10>
---[ end trace ec5c15e6a94a2468 ]---
note: firefox[2545] exited with preempt_count 2

Re: kernel BUG at fs/reiser4/block_alloc.c:151

[Edward Shishkin]

Marcin Baczyński wrote:
> Hi,
>   

Hello.

> I'm attaching a trace of kernel BUG that Firefox hits. It's 100% reproducible,
> every time I start the browser it hits the bug within several seconds, then
> whole system hangs. However I've never triggered the problem with any other
> application.
> I've tested 2.6.37-gentoo-hardened + reiser4 patch,

"2.6.37-gentoo-hardened" is based on what vanilla kernel (.36 or .37)?

>  and 2.6.36-zen kernels
> and both are affected.
> I'm happy to test patches or provide more info if needed.
>
> Thanks,
> Marcin
>   

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/reiser4/block_alloc.c:151

[Marcin Baczyński]

W dniu 8 lutego 2011 23:36 użytkownik Edward Shishkin
<edward.shishkin@gmail.com> napisał:
> Marcin Baczyński wrote:
>>
>> Hi,
>>
>
> Hello.
>
>> I'm attaching a trace of kernel BUG that Firefox hits. It's 100%
>> reproducible,
>> every time I start the browser it hits the bug within several seconds,
>> then
>> whole system hangs. However I've never triggered the problem with any
>> other
>> application.
>> I've tested 2.6.37-gentoo-hardened + reiser4 patch,
>
> "2.6.37-gentoo-hardened" is based on what vanilla kernel (.36 or .37)?
It's based on .37.

>
>>  and 2.6.36-zen kernels
>> and both are affected.
>> I'm happy to test patches or provide more info if needed.
>>
>> Thanks,
>> Marcin
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/reiser4/block_alloc.c:151

[Edward Shishkin]

On 02/09/2011 12:56 AM, Marcin Baczyński wrote:
> W dniu 8 lutego 2011 23:36 użytkownik Edward Shishkin
> <edward.shishkin@gmail.com>  napisał:
>> Marcin Baczyński wrote:
>>>
>>> Hi,
>>>
>>
>> Hello.
>>
>>> I'm attaching a trace of kernel BUG that Firefox hits. It's 100%
>>> reproducible,
>>> every time I start the browser it hits the bug within several seconds,
>>> then
>>> whole system hangs. However I've never triggered the problem with any
>>> other
>>> application.
>>> I've tested 2.6.37-gentoo-hardened + reiser4 patch,
>>
>> "2.6.37-gentoo-hardened" is based on what vanilla kernel (.36 or .37)?
> It's based on .37.
>
>>


  [<ffffffff81142782>] ? grabbed2flush_reserved_nolock+0x42/0xa0
  [<ffffffff81144c54>] ? jnode_make_dirty_locked+0xe4/0x190
  [<ffffffff81144d31>] ? znode_make_dirty+0x31/0xe0
  [<ffffffff81166a69>] ? find_disk_cluster+0x359/0x390
  [<ffffffff8117511c>] ? do_readpage_ctail+0xdc/0x570
  [<ffffffff81166f7d>] ? prepare_logical_cluster+0x23d/0x760

A set of blocks reserved in prepare_logical_cluster() is exhausted
at znode_make_dirty() for some reasons. No ideas except inserting
debugging messages to figure out who is stealing the reservation.
Will try to reproduce on weekends..

Thanks,
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/reiser4/block_alloc.c:151

[Edward Shishkin]

On 02/08/2011 11:13 PM, Marcin Baczyński wrote:
> Hi,
> I'm attaching a trace of kernel BUG that Firefox hits. It's 100% reproducible,
> every time I start the browser it hits the bug within several seconds, then
> whole system hangs. However I've never triggered the problem with any other
> application.
> I've tested 2.6.37-gentoo-hardened + reiser4 patch, and 2.6.36-zen kernels
> and both are affected.
> I'm happy to test patches or provide more info if needed.

You also can try to compile reiser4 with debugging info
and then run firefox. If some assertion is failed before
"kernel BUG at fs/reiser4/block_alloc.c:151", it would be
useful information...

Thanks,
Edward.

>
> Thanks,
> Marcin

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/reiser4/block_alloc.c:151

[Edward Shishkin]

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

On 02/09/2011 01:10 AM, Edward Shishkin wrote:
> On 02/09/2011 12:56 AM, Marcin Baczyński wrote:
>> W dniu 8 lutego 2011 23:36 użytkownik Edward Shishkin
>> <edward.shishkin@gmail.com> napisał:
>>> Marcin Baczyński wrote:
>>>>
>>>> Hi,
>>>>
>>>
>>> Hello.
>>>
>>>> I'm attaching a trace of kernel BUG that Firefox hits. It's 100%
>>>> reproducible,
>>>> every time I start the browser it hits the bug within several seconds,
>>>> then
>>>> whole system hangs. However I've never triggered the problem with any
>>>> other
>>>> application.
>>>> I've tested 2.6.37-gentoo-hardened + reiser4 patch,
>>>
>>> "2.6.37-gentoo-hardened" is based on what vanilla kernel (.36 or .37)?
>> It's based on .37.
>>
>>>
>
>
> [<ffffffff81142782>] ? grabbed2flush_reserved_nolock+0x42/0xa0
> [<ffffffff81144c54>] ? jnode_make_dirty_locked+0xe4/0x190
> [<ffffffff81144d31>] ? znode_make_dirty+0x31/0xe0
> [<ffffffff81166a69>] ? find_disk_cluster+0x359/0x390
> [<ffffffff8117511c>] ? do_readpage_ctail+0xdc/0x570
> [<ffffffff81166f7d>] ? prepare_logical_cluster+0x23d/0x760
>
> A set of blocks reserved in prepare_logical_cluster() is exhausted
> at znode_make_dirty() for some reasons. No ideas except inserting
> debugging messages to figure out who is stealing the reservation.


Aaahhh, it seems I understand what's up..
Could you please apply the attached patch, run
Firefox and send me kernel warnings?

Thanks,
Edward.

[-- Attachment #2: reiser4-increase-reservation-with-warn.patch --]
[-- Type: text/plain, Size: 1161 bytes --]

---
 fs/reiser4/estimate.c                  |    2 +-
 fs/reiser4/plugin/file/cryptcompress.c |    5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

--- linux-2.6.37.orig/fs/reiser4/estimate.c
+++ linux-2.6.37/fs/reiser4/estimate.c
@@ -114,7 +114,7 @@ reiser4_block_nr estimate_update_cluster
 */
 reiser4_block_nr estimate_dirty_cluster(struct inode *inode)
 {
-	return cluster_nrpages(inode) + 4;
+	return cluster_nrpages(inode) + 4 + 1000;
 }
 
 /* Make Linus happy.
--- linux-2.6.37.orig/fs/reiser4/plugin/file/cryptcompress.c
+++ linux-2.6.37/fs/reiser4/plugin/file/cryptcompress.c
@@ -2190,6 +2190,11 @@ int find_disk_cluster(struct cluster_han
  out:
 	assert("edward-1339",
 	       get_current_context()->grabbed_blocks >= was_grabbed);
+	if (get_current_context()->grabbed_blocks - was_grabbed < 1000)
+		warning("edward-2222", "file %llu consists of %d fragments",
+			(unsigned long long)get_inode_oid(inode),
+			was_grabbed + estimate_dirty_cluster(inode) -
+			get_current_context()->grabbed_blocks);
 	grabbed2free(get_current_context(),
 		     get_current_super_private(),
 		     get_current_context()->grabbed_blocks - was_grabbed);

Re: kernel BUG at fs/reiser4/block_alloc.c:151

[Marcin Baczyński]

W dniu 9 lutego 2011 03:37 użytkownik Edward Shishkin
<edward.shishkin@gmail.com> napisał:
> On 02/09/2011 01:10 AM, Edward Shishkin wrote:
>>
>> On 02/09/2011 12:56 AM, Marcin Baczyński wrote:
>>>
>>> W dniu 8 lutego 2011 23:36 użytkownik Edward Shishkin
>>> <edward.shishkin@gmail.com> napisał:
>>>>
>>>> Marcin Baczyński wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>
>>>> Hello.
>>>>
>>>>> I'm attaching a trace of kernel BUG that Firefox hits. It's 100%
>>>>> reproducible,
>>>>> every time I start the browser it hits the bug within several seconds,
>>>>> then
>>>>> whole system hangs. However I've never triggered the problem with any
>>>>> other
>>>>> application.
>>>>> I've tested 2.6.37-gentoo-hardened + reiser4 patch,
>>>>
>>>> "2.6.37-gentoo-hardened" is based on what vanilla kernel (.36 or .37)?
>>>
>>> It's based on .37.
>>>
>>>>
>>
>>
>> [<ffffffff81142782>] ? grabbed2flush_reserved_nolock+0x42/0xa0
>> [<ffffffff81144c54>] ? jnode_make_dirty_locked+0xe4/0x190
>> [<ffffffff81144d31>] ? znode_make_dirty+0x31/0xe0
>> [<ffffffff81166a69>] ? find_disk_cluster+0x359/0x390
>> [<ffffffff8117511c>] ? do_readpage_ctail+0xdc/0x570
>> [<ffffffff81166f7d>] ? prepare_logical_cluster+0x23d/0x760
>>
>> A set of blocks reserved in prepare_logical_cluster() is exhausted
>> at znode_make_dirty() for some reasons. No ideas except inserting
>> debugging messages to figure out who is stealing the reservation.
>
>
> Aaahhh, it seems I understand what's up..
> Could you please apply the attached patch, run
> Firefox and send me kernel warnings?

Here they are (kernel with patch applied + reiser4_debug=y):
reiser4[firefox(2497)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
WARNING: file 404669 consists of 1020 fragments
reiser4[firefox(2497)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
WARNING: file 18693127 consists of 1020 fragments

But there are thousands of them, and not all are caused by Firefox:
reiser4[bash(2708)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
WARNING: file 17649897 consists of 1020 fragments
reiser4[xz(2708)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
WARNING: file 17649897 consists of 1020 fragments

And among thousands of these 1020-fragments, there are
6 probably more intresting warns:

6542-reiser4[firefox(2518)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
6543:WARNING: file 404690 consists of 21 fragments
6544-reiser4[firefox(2518)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
6545:WARNING: file 404690 consists of 31 fragments
--
9297-reiser4[firefox(2518)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
9298:WARNING: file 404690 consists of 21 fragments
9299-reiser4[firefox(2518)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
9300:WARNING: file 404690 consists of 31 fragments
--
9453-reiser4[firefox(2518)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
9454:WARNING: file 404690 consists of 29 fragments
--
9847-reiser4[firefox(2518)]: find_disk_cluster
(fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
9848:WARNING: file 404690 consists of 21 fragments

I don't see any asserts in dmesg. And this time there was no BUG.
If more of these warning would be of any use, I can send them as well,
but compressed log is >60kB, so not attaching it now.

Thanks,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/reiser4/block_alloc.c:151

[Edward Shishkin]

Marcin Baczyński wrote:
> W dniu 9 lutego 2011 03:37 użytkownik Edward Shishkin
> <edward.shishkin@gmail.com> napisał:
>   
>> On 02/09/2011 01:10 AM, Edward Shishkin wrote:
>>     
>>> On 02/09/2011 12:56 AM, Marcin Baczyński wrote:
>>>       
>>>> W dniu 8 lutego 2011 23:36 użytkownik Edward Shishkin
>>>> <edward.shishkin@gmail.com> napisał:
>>>>         
>>>>> Marcin Baczyński wrote:
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>>             
>>>>> Hello.
>>>>>
>>>>>           
>>>>>> I'm attaching a trace of kernel BUG that Firefox hits. It's 100%
>>>>>> reproducible,
>>>>>> every time I start the browser it hits the bug within several seconds,
>>>>>> then
>>>>>> whole system hangs. However I've never triggered the problem with any
>>>>>> other
>>>>>> application.
>>>>>> I've tested 2.6.37-gentoo-hardened + reiser4 patch,
>>>>>>             
>>>>> "2.6.37-gentoo-hardened" is based on what vanilla kernel (.36 or .37)?
>>>>>           
>>>> It's based on .37.
>>>>
>>>>         
>>> [<ffffffff81142782>] ? grabbed2flush_reserved_nolock+0x42/0xa0
>>> [<ffffffff81144c54>] ? jnode_make_dirty_locked+0xe4/0x190
>>> [<ffffffff81144d31>] ? znode_make_dirty+0x31/0xe0
>>> [<ffffffff81166a69>] ? find_disk_cluster+0x359/0x390
>>> [<ffffffff8117511c>] ? do_readpage_ctail+0xdc/0x570
>>> [<ffffffff81166f7d>] ? prepare_logical_cluster+0x23d/0x760
>>>
>>> A set of blocks reserved in prepare_logical_cluster() is exhausted
>>> at znode_make_dirty() for some reasons. No ideas except inserting
>>> debugging messages to figure out who is stealing the reservation.
>>>       
>> Aaahhh, it seems I understand what's up..
>> Could you please apply the attached patch, run
>> Firefox and send me kernel warnings?
>>     
>
> Here they are (kernel with patch applied + reiser4_debug=y):
>   

Hello Marcin,
debug mode is not needed any more.

> reiser4[firefox(2497)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> WARNING: file 404669 consists of 1020 fragments
>   

This is an old problem of degeneration we need to fix somehow:
64K disk cluster should occupy not more than 17 4K-blocks
(15 full blocks plus 2 partially filled ones in the worst case).

For now please find the degenerated files with "find -inum 404669",
etc. and rename them. Use old names for non-sparse copies that
can be created with "cp" command. Some of those files are used
by Firefox, so it would be better to do it in the singe mode (init 1)
with minimum running applications. Such renaming will allow you to
avoid tons of warnings. Keep a list of degenerated files somewhere:
we'll work with them to narrow down the problem.

Could you join #reiser4 channel at irc://oftc.net, say on weekends?

Thanks,
Edward.

> reiser4[firefox(2497)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> WARNING: file 18693127 consists of 1020 fragments
>
> But there are thousands of them, and not all are caused by Firefox:
> reiser4[bash(2708)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> WARNING: file 17649897 consists of 1020 fragments
> reiser4[xz(2708)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> WARNING: file 17649897 consists of 1020 fragments
>
> And among thousands of these 1020-fragments, there are
> 6 probably more intresting warns:
>
> 6542-reiser4[firefox(2518)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> 6543:WARNING: file 404690 consists of 21 fragments
> 6544-reiser4[firefox(2518)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> 6545:WARNING: file 404690 consists of 31 fragments
> --
> 9297-reiser4[firefox(2518)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> 9298:WARNING: file 404690 consists of 21 fragments
> 9299-reiser4[firefox(2518)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> 9300:WARNING: file 404690 consists of 31 fragments
> --
> 9453-reiser4[firefox(2518)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> 9454:WARNING: file 404690 consists of 29 fragments
> --
> 9847-reiser4[firefox(2518)]: find_disk_cluster
> (fs/reiser4/plugin/file/cryptcompress.c:2197)[edward-2222]:
> 9848:WARNING: file 404690 consists of 21 fragments
>
> I don't see any asserts in dmesg. And this time there was no BUG.
> If more of these warning would be of any use, I can send them as well,
> but compressed log is >60kB, so not attaching it now.
>
> Thanks,
> Marcin
>
>   

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html