From: Simon Kirby <sim@hostway.ca>
To: Ian Applegate <ia@cloudflare.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Lameter <cl@gentwo.org>,
Pekka Enberg <penberg@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Chris Mason <chris.mason@fusionio.com>
Subject: Re: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()
Date: Mon, 25 Nov 2013 16:44:56 -0800 [thread overview]
Message-ID: <20131126004456.GF19648@hostway.ca> (raw)
In-Reply-To: <CAEcaRjg7GJhEbQoduup6xQKea4Pn4+SOgv8GbbJUeU=xR74dVQ@mail.gmail.com>
On Tue, Aug 20, 2013 at 12:51:11AM -0700, Ian Applegate wrote:
> Unfortunately no boxen with CONFIG_DEBUG_MUTEXES among them. I can
> enable on a few and should have some results within the day. These
> mainly serve (quite a bit of) HTTP/S cache traffic.
>
> On Tue, Aug 20, 2013 at 12:21 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, Aug 20, 2013 at 12:17:52AM -0700, Ian Applegate wrote:
> >> We are also seeing this or a similar issue. On a fairly widespread
> >> deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the
> >> order of 36 days (combined MTBF.)
> >
> > Do you have any boxen with CONFIG_DEBUG_MUTEXES among those? What
> > kind of setup do you have on those, BTW?
Hmm. So, we went through a few months of running with Linus' suggested
culprit-catching patch w/DEBUG_PAGE_ALLOC, but it never tripped. We also
ran with DEBUG_MUTEXES, but that never seem to catch anything, either.
Ian, is it true that what you saw involved no btrfs? I was still guessing
this is related to btrfs, as we are only seeing this on boxes doing btrfs
rsync-snapshot backups. I don't know what else is interesting about our
workload there, since we're not doing anything exotic.
Meanwhille, with DEBUG_LIST on 3.12-rc, we found list corruption, which
Josef fixed in 93858769172c4e3678917810e9d5de360eb991cc. This missed
3.12, unfortunately, so I built a 3.12 with Josef's btrfs-next merged (to
54563d41a58be77e9bd9ef7af1ea4026cf0e7e07, which contained that fix).
I was hoping this or something else by 3.12 would have fixed it, so after
testing we deployed this everywhere and turned off the rest of the debug
options. I missed slub_debug on one server, though...and it just hit
another case of overwritten poison.
Is it true that with slub_debug, aliasing of equal-sized objects is
turned off, and so they shouldn't be immediately side-by-side? In other
words, would there be similar scrawling victim chances as allocating
pipe_inode_info with pages instead of slabs? "slabinfo -a" is empty.
[158037.526662] =============================================================================
[158037.528014] BUG kmalloc-192 (Not tainted): Poison overwritten
[158037.528014] -----------------------------------------------------------------------------
[158037.528014]
[158037.528014] Disabling lock debugging due to kernel taint
[158037.528014] INFO: 0xffff88013af3da6c-0xffff88013af3da6c. First byte 0x6c instead of 0x6b
[158037.528014] INFO: Allocated in alloc_pipe_info+0x1f/0xb0 age=22 cpu=3 pid=26402
[158037.528014] __slab_alloc.constprop.63+0x35b/0x3a0
[158037.528014] kmem_cache_alloc_trace+0xab/0x110
[158037.528014] alloc_pipe_info+0x1f/0xb0
[158037.528014] create_pipe_files+0x41/0x1f0
[158037.528014] __do_pipe_flags+0x3c/0xb0
[158037.528014] SyS_pipe2+0x1b/0xa0
[158037.528014] SyS_pipe+0xb/0x10
[158037.528014] system_call_fastpath+0x16/0x1b
[158037.528014] INFO: Freed in free_pipe_info+0x6a/0x70 age=39 cpu=1 pid=26402
[158037.528014] __slab_free+0x2d/0x2d4
[158037.528014] kfree+0xfd/0x130
[158037.528014] free_pipe_info+0x6a/0x70
[158037.528014] pipe_release+0x94/0xf0
[158037.528014] __fput+0xa7/0x230
[158037.528014] ____fput+0x9/0x10
[158037.528014] task_work_run+0x97/0xd0
[158037.528014] do_notify_resume+0x66/0x70
[158037.528014] int_signal+0x12/0x17
[158037.528014] INFO: Slab 0xffffea0004ebcf00 objects=31 used=29 fp=0xffff88013af3e080 flags=0x8000000000004080
[158037.528014] INFO: Object 0xffff88013af3da68 @offset=6760 fp=0xffff88013af3ca28
[158037.528014]
[158037.528014] Bytes b4 ffff88013af3da58: 97 b8 59 02 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ..Y.....ZZZZZZZZ
[158037.528014] Object ffff88013af3da68: 6b 6b 6b 6b 6c 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkklkkkkkkkkkkk
[158037.528014] Object ffff88013af3da78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3da88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3da98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3daa8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3dab8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3dac8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3dad8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3dae8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3daf8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3db08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[158037.528014] Object ffff88013af3db18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
[158037.528014] Redzone ffff88013af3db28: bb bb bb bb bb bb bb bb ........
[158037.528014] Padding ffff88013af3dc68: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[158037.528014] CPU: 3 PID: 26402 Comm: perl Tainted: G B 3.12.0-hw+ #75
[158037.528014] Hardware name: Dell Inc. PowerEdge 1950/0UR033, BIOS 2.0.1 10/30/2007
[158037.528014] ffff88013af3da68 ffff88012252fc98 ffffffff817f6c6e 0000000000000007
[158037.528014] ffff88042d804900 ffff88012252fcc8 ffffffff81135099 ffff88013af3da6d
[158037.528014] ffff88042d804900 000000000000006b ffff88013af3da68 ffff88012252fd18
[158037.528014] Call Trace:
[158037.528014] [<ffffffff817f6c6e>] dump_stack+0x46/0x58
[158037.528014] [<ffffffff81135099>] print_trailer+0xf9/0x160
[158037.528014] [<ffffffff81135232>] check_bytes_and_report+0xe2/0x120
[158037.528014] [<ffffffff81135437>] check_object+0x1c7/0x240
[158037.528014] [<ffffffff8114325f>] ? alloc_pipe_info+0x1f/0xb0
[158037.528014] [<ffffffff817f2d0c>] alloc_debug_processing+0x153/0x168
[158037.528014] [<ffffffff817f307c>] __slab_alloc.constprop.63+0x35b/0x3a0
[158037.528014] [<ffffffff8114325f>] ? alloc_pipe_info+0x1f/0xb0
[158037.528014] [<ffffffff811369ab>] kmem_cache_alloc_trace+0xab/0x110
[158037.528014] [<ffffffff81152f2d>] ? inode_init_always+0xed/0x1b0
[158037.528014] [<ffffffff8114325f>] alloc_pipe_info+0x1f/0xb0
[158037.528014] [<ffffffff81143781>] create_pipe_files+0x41/0x1f0
[158037.528014] [<ffffffff8114396c>] __do_pipe_flags+0x3c/0xb0
[158037.528014] [<ffffffff8107808c>] ? task_work_run+0x9c/0xd0
[158037.528014] [<ffffffff81143a3b>] SyS_pipe2+0x1b/0xa0
[158037.528014] [<ffffffff818045f0>] ? int_signal+0x12/0x17
[158037.528014] [<ffffffff81143acb>] SyS_pipe+0xb/0x10
[158037.528014] [<ffffffff818043b9>] system_call_fastpath+0x16/0x1b
[158037.528014] FIX kmalloc-192: Restoring 0xffff88013af3da6c-0xffff88013af3da6c=0x6b
[158037.528014]
[158037.528014] FIX kmalloc-192: Marking all objects used
There was a crash from btrfs memcpy shortly after this, which may or may
not be related, followed by another poison overwritten. Writeback was
wedged at this point.
Full kernel log: http://0x.ca/sim/ref/3.12/dmesg
Other stuff: http://0x.ca/sim/ref/3.12/
Simon-
next prev parent reply other threads:[~2013-11-26 0:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-06 0:09 [3.10] Oopses in kmem_cache_allocate() via prepare_creds() Simon Kirby
2013-07-06 8:27 ` Pekka Enberg
2013-08-19 20:17 ` Simon Kirby
2013-08-19 20:29 ` Christoph Lameter
2013-08-19 21:16 ` Linus Torvalds
2013-08-19 21:24 ` Chris Mason
2013-08-19 23:31 ` Simon Kirby
2013-09-03 20:43 ` Simon Kirby
2013-08-20 4:06 ` Al Viro
2013-08-20 7:17 ` Ian Applegate
2013-08-20 7:21 ` Al Viro
2013-08-20 7:51 ` Ian Applegate
2013-11-26 0:44 ` Simon Kirby [this message]
2013-11-26 23:16 ` Linus Torvalds
2013-11-26 23:44 ` Linus Torvalds
2013-11-30 9:43 ` Simon Kirby
2013-11-30 17:25 ` Linus Torvalds
2013-11-30 21:04 ` Simon Kirby
2013-11-30 21:08 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131126004456.GF19648@hostway.ca \
--to=sim@hostway.ca \
--cc=chris.mason@fusionio.com \
--cc=cl@gentwo.org \
--cc=ia@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.