Bug 41102 - BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
Summary: BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
Status: NEW
Alias: None
Product: Memory Management
Classification: Unclassified
Component: Slab Allocator (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-13 22:29 UTC by Paul Bolle
Modified: 2019-11-05 07:11 UTC (History)
6 users (show)

See Also:
Kernel Version: 3.0.1
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Paul Bolle 2011-08-13 22:29:57 UTC
I found three occurrences of the "Poison overwritten" BUG in my logs. These occurred in one session (with a suspend/resume cycle between the second and third BUG). I've lumped these three occurrences in this one report. I have no idea what's going on an haven't yet dived deeper into this.

This might as well be just a one time issue. I recorded it here in case some else runs into this too (or I manage to trigger this again).

1st:
=============================================================================
BUG dentry: Poison overwritten
-----------------------------------------------------------------------------

INFO: 0xffff8801313f2000-0xffff8801313f201f. First byte 0x0 instead of 0x6b
INFO: Allocated in d_alloc+0x27/0x1b3 age=2345298 cpu=1 pid=32047
INFO: Freed in __d_free+0x59/0x5e age=2345298 cpu=1 pid=32047
INFO: Slab 0xffffea00042c5cf0 objects=12 used=11 fp=0xffff8801313f2000 flags=0x400000000000c1
INFO: Object 0xffff8801313f2000 @offset=0 fp=0x          (null)

  Object 0xffff8801313f2000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff8801313f2010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff8801313f2020:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2030:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2040:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2050:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2060:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2070:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2080:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2090:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f20a0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f20b0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f20c0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f20d0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f20e0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f20f0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f2100:  6b 6b 6b 6b 6b 6b 6b a5                         kkkkkkk�        
 Redzone 0xffff8801313f2108:  bb bb bb bb bb bb bb bb                         ��������        
 Padding 0xffff8801313f2148:  5a 5a 5a 5a 5a 5a 5a 5a                         ZZZZZZZZ        
Pid: 1262, comm: mandb Not tainted 3.0.1.1-1.local0.fc14.x86_64 #1
Call Trace:
 [<ffffffff8112f5eb>] print_trailer+0x133/0x13c
 [<ffffffff8112f908>] check_bytes_and_report+0xc1/0xff
 [<ffffffff8113069d>] check_object+0xc5/0x1b0
 [<ffffffff81155836>] ? d_alloc+0x27/0x1b3
 [<ffffffff811309a2>] alloc_debug_processing+0x7f/0x120
 [<ffffffff811319c5>] __slab_alloc+0x302/0x372
 [<ffffffff81155836>] ? d_alloc+0x27/0x1b3
 [<ffffffff8104a356h>] ? should_resched+0xe/0x2e
 [<ffffffff81155836>] ? d_alloc+0x27/0x1b3
 [<ffffffff81132d7b>] kmem_cache_alloc+0x53/0x105
 [<ffffffff811568b0>] ? __d_lookup+0xf8/0x10a
 [<ffffffff81155836>] d_alloc+0x27/0x1b3
 [<ffffffff8114c595>] d_alloc_and_lookup+0x2c/0x6d
 [<ffffffff8114d9a3>] walk_component+0x1ea/0x3da
 [<ffffffff8114ccd4>] ? handle_dots+0x218/0x218
 [<ffffffff8114f00a>] path_lookupat+0xae/0x34b
 [<ffffffff81252cd1>] ? __strncpy_from_user+0x1f/0x4e
 [<ffffffff8114f2d1>] do_path_lookup+0x2a/0x99
 [<ffffffff8114f70b>] user_path_at+0x56/0x93
 [<ffffffff81147037>] vfs_fstatat+0x49/0x74
 [<ffffffff8114709d>] vfs_stat+0x1b/0x1d
 [<ffffffff811471b3>] sys_newstat+0x1f/0x39
 [<ffffffff8108fcea>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff810b4759>] ? audit_syscall_entry+0x11c/0x148
 [<ffffffff81252a3e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff814f6242>] system_call_fastpath+0x16/0x1b
FIX dentry: Restoring 0xffff8801313f2000-0xffff8801313f201f=0x6b

FIX dentry: Marking all objects used

2nd:
=============================================================================
BUG buffer_head: Poison overwritten
-----------------------------------------------------------------------------

INFO: 0xffff8801313f4000-0xffff8801313f401f. First byte 0x0 instead of 0x6b
INFO: Allocated in alloc_buffer_head+0x21/0x49 age=35663788 cpu=0 pid=9854
INFO: Freed in free_buffer_head+0x24/0x33 age=2354764 cpu=0 pid=32425
INFO: Slab 0xffffea00042c5d60 objects=23 used=7 fp=0xffff8801313f4000 flags=0x400000000000c1
INFO: Object 0xffff8801313f4000 @offset=0 fp=0xffff8801313f4580

  Object 0xffff8801313f4000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff8801313f4010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff8801313f4020:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f4030:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f4040:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f4050:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f4060:  6b 6b 6b 6b 6b 6b 6b a5                         kkkkkkk�        
 Redzone 0xffff8801313f4068:  bb bb bb bb bb bb bb bb                         ��������        
 Padding 0xffff8801313f40a8:  5a 5a 5a 5a 5a 5a 5a 5a                         ZZZZZZZZ        
Pid: 1277, comm: updatedb Not tainted 3.0.1.1-1.local0.fc14.x86_64 #1
Call Trace:
 [<ffffffff8112f5eb>] print_trailer+0x133/0x13c
 [<ffffffff8112f908>] check_bytes_and_report+0xc1/0xff
 [<ffffffff8113069d>] check_object+0xc5/0x1b0
 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49
 [<ffffffff811309a2>] alloc_debug_processing+0x7f/0x120
 [<ffffffff811319c5>] __slab_alloc+0x302/0x372
 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49
 [<ffffffff8104a356>] ? should_resched+0xe/0x2e
 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49
 [<ffffffff81132d7b>] kmem_cache_alloc+0x53/0x105
 [<ffffffff810fd692>] ? get_page+0x2c/0x4d
 [<ffffffff811687c1>] alloc_buffer_head+0x21/0x49
 [<ffffffff81168ee0>] alloc_page_buffers+0x32/0xce
 [<ffffffff8116a58a>] __getblk+0x17a/0x211
 [<ffffffff8116a633>] __breadahead+0x12/0x39
 [<ffffffff811a9d77>] __ext4_get_inode_loc+0x2bd/0x377
 [<ffffffff811ab43d>] ext4_iget+0x58/0x6eb
 [<ffffffff811b379a>] ext4_lookup+0x97/0xec
 [<ffffffff8114c5ae>] d_alloc_and_lookup+0x45/0x6d
 [<ffffffff8114d9a3>] walk_component+0x1ea/0x3da
 [<ffffffff8114ccd4>] ? handle_dots+0x218/0x218
 [<ffffffff8114f00a>] path_lookupat+0xae/0x34b
 [<ffffffff81252cd1>] ? __strncpy_from_user+0x1f/0x4e
 [<ffffffff8114f2d1>] do_path_lookup+0x2a/0x99
 [<ffffffff8114f70b>] user_path_at+0x56/0x93
 [<ffffffff8110fe25>] ? might_fault+0xa5/0xac
 [<ffffffff81146d96>] ? cp_new_stat+0xf3/0x10b
 [<ffffffff81147037>] vfs_fstatat+0x49/0x74
 [<ffffffff81147080>] vfs_lstat+0x1e/0x20
 [<ffffffff811471ec>] sys_newlstat+0x1f/0x39
 [<ffffffff8108fcea>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff810b4759>] ? audit_syscall_entry+0x11c/0x148
 [<ffffffff81252a3e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff814f6242>] system_call_fastpath+0x16/0x1b
FIX buffer_head: Restoring 0xffff8801313f4000-0xffff8801313f401f=0x6b

FIX buffer_head: Marking all objects used

3rd:
=============================================================================
BUG buffer_head: Poison overwritten
-----------------------------------------------------------------------------

INFO: 0xffff8801313f8000-0xffff8801313f801f. First byte 0x0 instead of 0x6b
INFO: Allocated in alloc_buffer_head+0x21/0x49 age=65625325 cpu=0 pid=7495
INFO: Freed in free_buffer_head+0x24/0x33 age=3288593 cpu=0 pid=32425
INFO: Slab 0xffffea00042c5e40 objects=23 used=18 fp=0xffff8801313f8000 flags=0x400000000000c1
INFO: Object 0xffff8801313f8000 @offset=0 fp=0xffff8801313f8210

  Object 0xffff8801313f8000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff8801313f8010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff8801313f8020:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f8030:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f8040:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f8050:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff8801313f8060:  6b 6b 6b 6b 6b 6b 6b a5                         kkkkkkk�        
 Redzone 0xffff8801313f8068:  bb bb bb bb bb bb bb bb                         ��������        
 Padding 0xffff8801313f80a8:  5a 5a 5a 5a 5a 5a 5a 5a                         ZZZZZZZZ        
Pid: 2088, comm: yumBackend.py Not tainted 3.0.1.1-1.local0.fc14.x86_64 #1
Call Trace:
 [<ffffffff8112f5eb>] print_trailer+0x133/0x13c
 [<ffffffff8112f908>] check_bytes_and_report+0xc1/0xff
 [<ffffffff8113069d>] check_object+0xc5/0x1b0
 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49
 [<ffffffff811309a2>] alloc_debug_processing+0x7f/0x120
 [<ffffffff811319c5>] __slab_alloc+0x302/0x372
 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49
 [<ffffffff8104a356>] ? should_resched+0xe/0x2e
 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49
 [<ffffffff81132d7b>] kmem_cache_alloc+0x53/0x105
 [<ffffffff810f3c88>] ? add_to_page_cache_locked+0x86/0x10c
 [<ffffffff811687c1>] alloc_buffer_head+0x21/0x49
 [<ffffffff81168ee0>] alloc_page_buffers+0x32/0xce
 [<ffffffff81168f9e>] create_empty_buffers+0x22/0xb1
 [<ffffffff8110baf7>] ? __inc_zone_page_state+0x23/0x25
 [<ffffffff8116a7a6>] __block_write_begin+0x71/0x2a7
 [<ffffffff811adcab>] ? ext4_block_truncate_page+0x26/0x26
 [<ffffffff810f3d61>] ? add_to_page_cache_lru+0x53/0x5b
 [<ffffffff810f3e05>] ? grab_cache_page_write_begin+0x9c/0xae
 [<ffffffff811aeda0>] ext4_da_write_begin+0x176/0x21b
 [<ffffffff810f2f1c>] generic_file_buffered_write+0xfd/0x240
 [<ffffffff810f498e>] __generic_file_aio_write+0x248/0x278
 [<ffffffff810f4a21>] generic_file_aio_write+0x63/0xbe
 [<ffffffff811a6d11>] ext4_file_write+0x1f8/0x253
 [<ffffffff81172dc5>] ? fsnotify+0x86/0x41e
 [<ffffffff8108f8ce>] ? lock_acquire+0xd3/0xfb
 [<ffffffff81172dc5>] ? fsnotify+0x86/0x41e
 [<ffffffff81142a1a>] do_sync_write+0xcb/0x108
 [<ffffffff81206cff>] ? selinux_file_permission+0x57/0xb6
 [<ffffffff812015ff>] ? security_file_permission+0x2e/0x33
 [<ffffffff811430c1>] vfs_write+0xaf/0x102
 [<ffffffff8114468d>] ? fget_light+0x3a/0xa1
 [<ffffffff811432d4>] sys_write+0x4d/0x74
 [<ffffffff814f6242>] system_call_fastpath+0x16/0x1b
FIX buffer_head: Restoring 0xffff8801313f8000-0xffff8801313f801f=0x6b

FIX buffer_head: Marking all objects used
Comment 1 Andrew Morton 2011-08-16 22:13:46 UTC
I marked this as a regression.  I *think* it's a 2.6.39->3.0 regression?
Comment 2 Paul Bolle 2011-08-17 10:14:04 UTC
(In reply to comment #1)
> I marked this as a regression.  I *think* it's a 2.6.39->3.0 regression?

0) That might well be correct. But please note that the 3.0.1 kernel I triggered this issue with seems to be the first I ran on this machine that has CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than a one time goof - would never have showed up in the logs unless I manually booted with "slub_debug" on the command line. And I can't remember booting with "slub_debug". 

(1) Background: mm/slub.c:check_bytes_and_report() and work your way up in code and CONFIG_* options.)

(2) Uninteresting detail: I changed the way I built the kernel for this machine - which still tracks Fedora 14 - after it was made clear that v2.6.39.4 would be the last stable release for v2.6.39. I now sort of rebuilt a Fedora Rawhide kernel, but dropping Fedora's non-upstreamed patches.)
Comment 3 Rafael J. Wysocki 2011-08-30 18:43:06 UTC
On Tuesday, August 30, 2011, Paul Bolle wrote:
> On Sun, 2011-08-28 at 21:01 +0200, Rafael J. Wysocki wrote:
> > Please verify if it still should
> > be listed and let the tracking team know (either way).
> 
> From comment #2:
> > [...] please note that the 3.0.1 kernel I
> > triggered this issue with seems to be the first I ran on this machine that
> has
> > CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than
> a
> > one time goof - would never have showed up in the logs unless I manually
> booted
> > with "slub_debug" on the command line. And I can't remember booting with
> > "slub_debug".
> 
> At this moment I see little reason to track this bug entry as a
> regression.
Comment 4 Rafael J. Wysocki 2011-08-30 18:44:32 UTC
Dropping from the list of recent regressions.
Comment 5 Paul Bolle 2012-04-16 08:50:29 UTC
(0) This is a copy of a message I sent directly to one of the people tracking this bug on Sep 11, 2011, since kernel.org was down at that time. I forgot to update this report once bugzilla.kernel.org was up again. I add this to this report on the odd chance that someone running v3.0.x runs into something similar.)

1) I've hit this again (that is, the first of the free "Poison overwritten" messages). Thawing from hibernation seems to be a possible cause of this. Kernel is now v3.0.4. So it seems not to be just a one time goof and might even be reproducible. (I haven't yet dared to reproduce this.)

2) And this was what I found in the logs:

=============================================================================
BUG dentry: Poison overwritten
-----------------------------------------------------------------------------

INFO: 0xffff88012f6ef000-0xffff88012f6ef01f. First byte 0x0 instead of 0x6b
INFO: Allocated in d_alloc+0x27/0x1b3 age=8009211 cpu=1 pid=9833
INFO: Freed in __d_free+0x59/0x5e age=10700 cpu=1 pid=13756
INFO: Slab 0xffffea0004260448 objects=12 used=5 fp=0xffff88012f6ef000
flags=0x400000000000c1
INFO: Object 0xffff88012f6ef000 @offset=0 fp=0xffff88012f6efbd0

  Object 0xffff88012f6ef000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff88012f6ef010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  Object 0xffff88012f6ef020:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef030:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef040:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef050:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef060:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef070:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef080:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef090:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef0a0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef0b0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef0c0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef0d0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef0e0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef0f0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff88012f6ef100:  6b 6b 6b 6b 6b 6b 6b a5
kkkkkkk�        
 Redzone 0xffff88012f6ef108:  bb bb bb bb bb bb bb bb
��������        
 Padding 0xffff88012f6ef148:  5a 5a 5a 5a 5a 5a 5a 5a
ZZZZZZZZ        
Pid: 14674, comm: pm-powersave Not tainted 3.0.4-local0.fc14.x86_64 #1
Call Trace:
 [<ffffffff8112f7db>] print_trailer+0x133/0x13c
 [<ffffffff8112faf8>] check_bytes_and_report+0xc1/0xff
 [<ffffffff8113088d>] check_object+0xc5/0x1b0
 [<ffffffff81155a26>] ? d_alloc+0x27/0x1b3
 [<ffffffff81130b92>] alloc_debug_processing+0x7f/0x120
 [<ffffffff81131bb5>] __slab_alloc+0x302/0x372
 [<ffffffff81155a26>] ? d_alloc+0x27/0x1b3
 [<ffffffff8104a356>] ? should_resched+0xe/0x2e
 [<ffffffff81155a26>] ? d_alloc+0x27/0x1b3
 [<ffffffff81132f6b>] kmem_cache_alloc+0x53/0x105
 [<ffffffff81156aa0>] ? __d_lookup+0xf8/0x10a
 [<ffffffff81155a26>] d_alloc+0x27/0x1b3
 [<ffffffff8114c785>] d_alloc_and_lookup+0x2c/0x6d
 [<ffffffff8114db93>] walk_component+0x1ea/0x3da
 [<ffffffff8114cec4>] ? handle_dots+0x218/0x218
 [<ffffffff8114f1fa>] path_lookupat+0xae/0x34b
 [<ffffffff81252fb1>] ? __strncpy_from_user+0x1f/0x4e
 [<ffffffff8114f4c1>] do_path_lookup+0x2a/0x99
 [<ffffffff8114f8fb>] user_path_at+0x56/0x93
 [<ffffffff8107eb40>] ? up_read+0x2b/0x33
 [<ffffffff814f2b9a>] ? do_page_fault+0x31e/0x3a8
 [<ffffffff8110ffcc>] ? might_fault+0x5c/0xac
 [<ffffffff81147227>] vfs_fstatat+0x49/0x74
 [<ffffffff8108f8e7>] ? lock_release+0x18a/0x1b2
 [<ffffffff8114728d>] vfs_stat+0x1b/0x1d
 [<ffffffff811473a3>] sys_newstat+0x1f/0x39
 [<ffffffff8114c5a1>] ? path_put+0x22/0x26
 [<ffffffff8110ffcc>] ? might_fault+0x5c/0xac
 [<ffffffff810b4949>] ? audit_syscall_entry+0x11c/0x148
 [<ffffffff81252d1e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff814f62c2>] system_call_fastpath+0x16/0x1b
FIX dentry: Restoring 0xffff88012f6ef000-0xffff88012f6ef01f=0x6b

FIX dentry: Marking all objects used
Comment 6 Paul Bolle 2012-04-16 09:18:46 UTC
(0) And this is a copy of a message I sent directly to one of the people tracking
this bug on Sep 20, 2011, since kernel.org was still down at that time. I again add this to this report on the odd chance that someone running v3.0.x runs into something similar.)

1) I've just hit an almost identical message, and again after thawing from hibernation. Kernel is still now v3.0.4. So it really seems to be reproducible by thawing from hibernation. We're making progress, I'd guess.

(2) But I have to note that I've stopped using hibernation on this machine some time after sending this message. I seem to remember running into filesystem trouble after thawing. The filesystem concerned gave me a Desktop Manager with one of its executables having the contents of some PNG. Try debugging that!

Anyhow, this machine has an Intel 965M chipset, and so it uses the i915 module. Perhaps this all is related to the issues fixed with commit 3fa016a0b5c5237e9c387fc3249592b2cb5391c6 ("drm/i915: suspend fbdev device around suspend/hibernate"), which shipped in v3.4-rc1 and later. See bug #37142 for some background.

Perhaps I'll try again once this machine is running v3.4.)
Comment 7 Alan 2012-08-30 10:32:13 UTC
Did 3.4 help ?
Comment 8 Paul Bolle 2012-08-30 10:55:35 UTC
(In reply to comment #7)
0) Thanks for taking the time take a look at this report. I, of course, had already forgotten it.

> Did 3.4 help ?
1) I'd have to check. I don't think I ever ran v3.4 with SLUB_DEBUG_ON set. Nor did I ever use the slub_debug parameter. And, more importantly, after filing this report I stopped using hibernation (see comment #6).

2) So feel free to close this report (with insufficient data or whatever).

3) In the mean time I'll have to think whether I again dare to hibernate this machine. And if I do dare to do that, I'll do so with "slub_debug" set. Then we'll see whether v3.4 helped. If not, I could always reopen this report.

Note You need to log in before you can comment on or make changes to this bug.