From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF857C433E2 for ; Sat, 6 Jun 2020 06:46:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 98EDA207DF for ; Sat, 6 Jun 2020 06:46:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98EDA207DF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1324380007; Sat, 6 Jun 2020 02:46:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BCE18E0006; Sat, 6 Jun 2020 02:46:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC6B580007; Sat, 6 Jun 2020 02:46:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id D09878E0006 for ; Sat, 6 Jun 2020 02:46:55 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 800E11CFD3C for ; Sat, 6 Jun 2020 06:46:55 +0000 (UTC) X-FDA: 76897854390.14.waves95_42183c426da6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 5A8D118229835 for ; Sat, 6 Jun 2020 06:46:55 +0000 (UTC) X-HE-Tag: waves95_42183c426da6 X-Filterd-Recvd-Size: 6801 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Sat, 6 Jun 2020 06:46:54 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id b8so10309729oic.1 for ; Fri, 05 Jun 2020 23:46:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gwWaD5Q8IVHw1QydWU1MECvDrlkrGMlMpGEjvbM9ZfM=; b=aELyPuNiBvOjj+Bn3EEMhtfpjP1u31WsZP4M9bNEbszgWzdpj0Of3P6VO8HflgRmmc nLdsxsSh7gmhHsmn9187OyVg3NCDvCbI1netD/tLYM5uTF2ULkQrdyzzfwYe0x4GNPtF w29lBpkPq7Fd10NmjUu6XOpDUvV7aVOsiZ21UUV/X3ASsNr7oXDOO4ZWWCuvnphoVYFu aK3hma5PV77LCtWwMZkbNrzP2FKpE4Y3eUAdpjM7uaLx0SZ3dfur8Fb4DdoPC0pG4Wpu esegzVIDO2ZLWmiVuoBa/I54s0rL0vgZI4q5V360ompPwL9t2UKw9tPWR9oDrRNzSoGU PAVg== X-Gm-Message-State: AOAM532mV629b3GAO+Llgkc+K9QCL5cfSiwlOeWGzlYmG07kKsYre/Nz WFeEXuEUN5qx+fqQeKU8vX2uBiGHJFPDNjiDyAg= X-Google-Smtp-Source: ABdhPJy8ArS/aVX9wRHilqeUfr+43DhbEyNX79e34r1Xe4ZcflEBe71GLGg2bZktyqMUHusjoJpLpFXn2OmGWL71c0w= X-Received: by 2002:aca:ad88:: with SMTP id w130mr4395472oie.103.1591426014336; Fri, 05 Jun 2020 23:46:54 -0700 (PDT) MIME-Version: 1.0 References: <7839183d-1c0b-da02-73a2-bf5e1e8b02b9@suse.cz> <94296941-1073-913c-2adb-bf2e41be9f0f@oracle.com> <202006041054.874AA564@keescook> <34455dce-6675-1fc2-8d61-45bf56f3f554@suse.cz> <6b2b149e-c2bc-f87a-ea2c-3046c5e39bf9@oracle.com> <894e8cee-33df-1f63-fb12-72dceb024ea7@oracle.com> <202006050828.F85A75D13@keescook> In-Reply-To: <202006050828.F85A75D13@keescook> From: "Rafael J. Wysocki" Date: Sat, 6 Jun 2020 08:46:42 +0200 Message-ID: Subject: Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018 To: Kees Cook Cc: Vegard Nossum , Vlastimil Babka , "Rafael J. Wysocki" , Robert Moore , Erik Kaneda , "Rafael J. Wysocki" , Christoph Lameter , Andrew Morton , Marco Elver , Waiman Long , LKML , Linux MM , ACPI Devel Maling List , Len Brown , Steven Rostedt Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5A8D118229835 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jun 5, 2020 at 5:44 PM Kees Cook wrote: > > On Fri, Jun 05, 2020 at 04:44:51PM +0200, Vegard Nossum wrote: > > On 2020-06-05 16:08, Vlastimil Babka wrote: > > > On 6/5/20 3:12 PM, Rafael J. Wysocki wrote: > > > > On Fri, Jun 5, 2020 at 2:48 PM Vegard Nossum wrote: > > > > > > > > > > On 2020-06-05 11:36, Vegard Nossum wrote: > > > > > > > > > > > > On 2020-06-05 11:11, Vlastimil Babka wrote: > > > > > > > So, with Kees' patch reverted, booting with slub_debug=F (or even more > > > > > > > specific slub_debug=F,ftrace_event_field) also hits this bug below. I > > > > > > > wanted to bisect it, but v5.7 was also bad, and also v5.6. Didn't try > > > > > > > further in history. So it's not new at all, and likely very specific to > > > > > > > your config+QEMU? (and related to the ACPI error messages that precede > > > > > > > it?). > > > [...] > > > [ 0.140408] ------------[ cut here ]------------ > > > [ 0.140837] cache_from_obj: Wrong slab cache. Acpi-Namespace but object is from kmalloc-64 > > > [ 0.141406] WARNING: CPU: 0 PID: 1 at mm/slab.h:524 kmem_cache_free+0x1d3/0x250 > > Ah yes! Good. I had improved this check recently too, and I was worried > the freelist pointer patch was somehow blocking it, but I see now that > the failing config didn't have CONFIG_SLAB_FREELIST_HARDENED=y. Once > SLAB_CONSISTENCY_CHECKS was enabled ("slub_debug=F"), it started > tripping. Whew. > > I wonder if that entire test block should just be removed from > cache_from_obj(): > > if (!memcg_kmem_enabled() && > !IS_ENABLED(CONFIG_SLAB_FREELIST_HARDENED) && > !unlikely(s->flags & SLAB_CONSISTENCY_CHECKS)) > return s; > > and make this test unconditional? It's mostly only called during free(), > and shouldn't be too expensive to be made unconditional. Hmm. > > > > And it seems ACPI is allocating an object via kmalloc() and then freeing it > > > via kmem_cache_free(<"Acpi-Namespace" kmem_cache>) which is wrong. > > > > > > > ./scripts/faddr2line vmlinux 'acpi_ns_root_initialize+0xb6' > > > acpi_ns_root_initialize+0xb6/0x2d1: > > > kmalloc at include/linux/slab.h:555 > > > (inlined by) kzalloc at include/linux/slab.h:669 > > > (inlined by) acpi_os_allocate_zeroed at include/acpi/platform/aclinuxex.h:57 > > > (inlined by) acpi_ns_root_initialize at drivers/acpi/acpica/nsaccess.c:102 > > > > > > > That's it :-) This fixes it for me: > > > > diff --git a/drivers/acpi/acpica/nsaccess.c b/drivers/acpi/acpica/nsaccess.c > > index 2566e2d4c7803..b76bbab917941 100644 > > --- a/drivers/acpi/acpica/nsaccess.c > > +++ b/drivers/acpi/acpica/nsaccess.c > > @@ -98,14 +98,12 @@ acpi_status acpi_ns_root_initialize(void) > > * predefined names are at the root level. It is much easier > > to > > * just create and link the new node(s) here. > > */ > > - new_node = > > - ACPI_ALLOCATE_ZEROED(sizeof(struct > > acpi_namespace_node)); > > + new_node = acpi_ns_create_node(*ACPI_CAST_PTR (u32, > > init_val->name)); > > if (!new_node) { > > status = AE_NO_MEMORY; > > goto unlock_and_exit; > > } > > > > - ACPI_COPY_NAMESEG(new_node->name.ascii, init_val->name); > > new_node->descriptor_type = ACPI_DESC_TYPE_NAMED; > > new_node->type = init_val->type; > > I'm a bit confused by the internals of acpi_ns_create_note(). It can still > end up calling ACPI_ALLOCATE_ZEROED() via acpi_os_acquire_object(). No, it can't. Linux uses the one from include/acpi/platform/aclinuxex.h > Is this fix correct? Yes, it is, AFAICS. Cheers!