Messages in this thread | | | Date | Mon, 8 Aug 2011 09:38:42 +0300 | Subject | Re: list corruption in the last few days. (block ? crypto ?) | From | Pekka Enberg <> |
| |
On Mon, Aug 8, 2011 at 9:31 AM, Xiaotian Feng <xtfeng@gmail.com> wrote: > On Mon, Aug 8, 2011 at 2:18 PM, Pekka Enberg <penberg@kernel.org> wrote: >> On Mon, Aug 8, 2011 at 9:14 AM, Xiaotian Feng <xtfeng@gmail.com> wrote: >>> On Mon, Aug 8, 2011 at 1:18 PM, Pekka Enberg <penberg@kernel.org> wrote: >>>> Hi Linus, >>>> >>>> On Sun, Aug 7, 2011 at 11:58 AM, Pekka Enberg <penberg@kernel.org> wrote: >>>>>> >>>>>> Christoph, I've been reading the code and spotted two potential issues in >>>>>> __slab_free(). The first one seems like an off-by-one where our >>>>>> comparison >>>>>> in deactivate_slab() doesn't match __slab_free. >>>>>> >>>>>> The other one is remove_full() call in __slab_free() that can get called >>>>>> even if cache debugging is not enabled. >>>>>> >>>>>> Hmm? >>>> >>>> On Sun, 7 Aug 2011, Linus Torvalds wrote: >>>>> >>>>> I'd like to do -rc1 today, regardless of whether this fixes things or >>>>> not (-rc1 is already a few days delayed). >>>>> >>>>> The patch seems to be a good fix, and a likely candidate for the >>>>> corruption. Commit log and sign-off? I assume you've given it some >>>>> testing, even if you couldn't reproduce the original issue? >>>> >>>> No, I haven't tested the patch myself but here's one in proper format in >>>> case someone wants to test it. >>> >>> I applied it and I'm still seeing the corruption warning start from this :( >>> >>> [ 3674.255030] ------------[ cut here ]------------ >>> [ 3674.255040] WARNING: at lib/list_debug.c:53 __list_del_entry+0xa1/0xd0() >>> [ 3674.255042] Hardware name: 42424XC >>> [ 3674.255045] list_del corruption. prev->next should be >>> ffffea0000493420, but was ffffea0001ab0520 >>> [ 3674.255047] Modules linked in: ip6table_filter ip6_tables >>> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 >>> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp >>> iptable_filter ip_tables x_tables binfmt_misc bridge stp parport_pc >>> ppdev snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep >>> snd_pcm thinkpad_acpi arc4 cryptd aes_x86_64 aes_generic snd_seq_midi >>> i915 snd_rawmidi snd_seq_midi_event snd_seq joydev iwlagn btusb >>> snd_timer snd_seq_device drm_kms_helper bluetooth uvcvideo snd >>> videodev drm mac80211 cfg80211 i2c_algo_bit soundcore tpm_tis tpm >>> tpm_bios lp snd_page_alloc psmouse serio_raw v4l2_compat_ioctl32 nvram >>> video parport usbhid hid sdhci_pci firewire_ohci ahci libahci sdhci >>> firewire_core crc_itu_t e1000e >>> [ 3674.255129] Pid: 3, comm: ksoftirqd/0 Not tainted 3.1.0-rc1+ #38 >>> [ 3674.255131] Call Trace: >>> [ 3674.255138] [<ffffffff8106db3f>] warn_slowpath_common+0x7f/0xc0 >>> [ 3674.255143] [<ffffffff8106dc36>] warn_slowpath_fmt+0x46/0x50 >>> [ 3674.255147] [<ffffffff81331851>] __list_del_entry+0xa1/0xd0 >>> [ 3674.255151] [<ffffffff81331891>] list_del+0x11/0x40 >>> [ 3674.255156] [<ffffffff81179631>] __slab_free+0x3d1/0x3e0 >>> [ 3674.255162] [<ffffffff811c5b06>] ? bvec_free_bs+0x26/0x40 >>> [ 3674.255166] [<ffffffff8117ab27>] ? kmem_cache_free+0x97/0x220 >>> [ 3674.255170] [<ffffffff811c5b06>] ? bvec_free_bs+0x26/0x40 >>> [ 3674.255174] [<ffffffff811c5b06>] ? bvec_free_bs+0x26/0x40 >>> [ 3674.255179] [<ffffffff8117ac9f>] kmem_cache_free+0x20f/0x220 >> >> Can you please also run >> >> addr2line -e vmlinux >> 0xffffffff81179631 >> > > /opt/upstream/linux-3.0/mm/slub.c:1061 > > > /* > * list_lock must be held. > */ > static void remove_full(struct kmem_cache *s, struct page *page) > { > if (!(s->flags & SLAB_STORE_USER)) > return; > > list_del(&page->lru); <=== here > }
OK, so it's the full list. Looking at deactivate_slab() we actually can access the list without n->list_lock held. Does the attached patch help?
Pekka [unhandled content-type:application/octet-stream] | |