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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 B412AC2D0C2 for ; Fri, 3 Jan 2020 14:49:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8CF3B21835 for ; Fri, 3 Jan 2020 14:49:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8CF3B21835 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1802D8E0006; Fri, 3 Jan 2020 09:49:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 130338E0003; Fri, 3 Jan 2020 09:49:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01ECB8E0006; Fri, 3 Jan 2020 09:49:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id E0F8A8E0003 for ; Fri, 3 Jan 2020 09:49:40 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 82EFD1CBE for ; Fri, 3 Jan 2020 14:49:40 +0000 (UTC) X-FDA: 76336606920.05.hall94_8ea2f32f83025 X-HE-Tag: hall94_8ea2f32f83025 X-Filterd-Recvd-Size: 1891 Received: from gentwo.org (gentwo.org [3.19.106.255]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Fri, 3 Jan 2020 14:49:40 +0000 (UTC) Received: by gentwo.org (Postfix, from userid 1002) id 788923F875; Fri, 3 Jan 2020 14:49:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 7665A3E954; Fri, 3 Jan 2020 14:49:39 +0000 (UTC) Date: Fri, 3 Jan 2020 14:49:39 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Qian Cai cc: lijiazi , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , lijiazi , linux-mm@kvack.org Subject: Re: [PATCH] slub: call BUG if next_object is not valid In-Reply-To: <19578131-DF7A-486F-9198-B9294E04D450@lca.pw> Message-ID: References: <19578131-DF7A-486F-9198-B9294E04D450@lca.pw> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.068181, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 3 Jan 2020, Qian Cai wrote: > > On Jan 3, 2020, at 6:17 AM, lijiazi wrote: > > > > If current object's memory is corrupted, there is a high > > probability that next_objext stored in it will be rewritten as an > > illegal value. It's better to check next_object this time than to > > encounter a illegal pointer in next slub alloc like the following: > > Rather than papering over the issue, the key to figure out is how was the current object memory corrupted? Yes and this is a performance critical path. Keep expensive operations out and enable them only if debugging is enabled.