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=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 9121BC433DF for ; Fri, 5 Jun 2020 15:44:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 38EF12074B for ; Fri, 5 Jun 2020 15:44:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="NikDzLOK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38EF12074B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8527680007; Fri, 5 Jun 2020 11:44:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 801068E0006; Fri, 5 Jun 2020 11:44:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A29A80007; Fri, 5 Jun 2020 11:44:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 4EAD98E0006 for ; Fri, 5 Jun 2020 11:44:16 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0EA6E8248D52 for ; Fri, 5 Jun 2020 15:44:16 +0000 (UTC) X-FDA: 76895579712.26.judge26_140517226da1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 0528218145976 for ; Fri, 5 Jun 2020 15:44:12 +0000 (UTC) X-HE-Tag: judge26_140517226da1 X-Filterd-Recvd-Size: 7218 Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Jun 2020 15:44:12 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id y17so3766859plb.8 for ; Fri, 05 Jun 2020 08:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1mULMROuThJEJ5mn2BpH3TCtjO6X9vn9NXYKq1SVXCQ=; b=NikDzLOKEbkdHl/a+qsn72HQQdgG4lUWew7gJeKOem2r+jk/zX/zfvHnv0NNmhzFm7 zYt45PiWRzHSua6gEBvhxICbkJ5xlf/RiDfUJZz+Pg7FKaHqMzUC7gOAd2VZzDeTZ/8/ QO+Gu1UWhZuFTFXNwtbOJqb0F1nglhXU1rzYA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1mULMROuThJEJ5mn2BpH3TCtjO6X9vn9NXYKq1SVXCQ=; b=OE+gVPfwg02MzPggT76LFZyo0loL2Kp2NSKy+T6/+/ipayq2AXgARkLKNvfu7KR8O5 4kIPAisjug6nOuWR+zBOuLsgoB10KK2ubmBXxqCK7+7tCjoEue2d32qxB+Qnopes/I4B iQMfMHyB6LYAB6aUh8cfI2uUCUVSTBKE55vjKIkRULVxwZvKB2BiImZMLSSotMZ+QYFf 6/A9g6Pmvp6uNnqFHiRrFWQ7rjtC7WblGaPE/FSAdNt8CLexSLnShq98E2GL88kKziAw DKkm6CL7jiUxMNdlmUCT98yphWX9SXGQLMgUZ5hfMvrjYFWZq2xcEii3rQEd02KnAtWr eV9A== X-Gm-Message-State: AOAM530LDmkQRn1JrQh/r06gargx3wI8u60ULRbjq6vGnyqqdGrvxqNn /m+gmSrOkGwPtB4w9DmU/D6Itw== X-Google-Smtp-Source: ABdhPJxCJZj6genPtMB0lpkEc5DOWzQaxfWZ3R8Dw3uF3dgSiNjDe0nqGoGObx9Tl6gZci9hQn2mJg== X-Received: by 2002:a17:90a:f694:: with SMTP id cl20mr3815256pjb.141.1591371851304; Fri, 05 Jun 2020 08:44:11 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id w190sm39003pfw.35.2020.06.05.08.44.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 08:44:09 -0700 (PDT) Date: Fri, 5 Jun 2020 08:44:08 -0700 From: Kees Cook To: Vegard Nossum Cc: 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 Subject: Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018 Message-ID: <202006050828.F85A75D13@keescook> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <894e8cee-33df-1f63-fb12-72dceb024ea7@oracle.com> X-Rspamd-Queue-Id: 0528218145976 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 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(). Is this fix correct? -- Kees Cook