Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp400705imw; Thu, 14 Jul 2022 03:39:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v4V8aV8t3p4kveLIMnsSMQb4Y1WrPG6S7OSsGjv3RVaN2OYscOvxOZpjrrfCjW0R4PrFO2 X-Received: by 2002:a17:907:67b0:b0:72b:7792:5e0a with SMTP id qu48-20020a17090767b000b0072b77925e0amr8042817ejc.400.1657795166122; Thu, 14 Jul 2022 03:39:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657795166; cv=none; d=google.com; s=arc-20160816; b=Jil4TrP42RLviUruwYnByigC8WUwnQfaXG92nbE+CnMolEI2TjItRn9MzlNDIOS0+z UGF1sDNMr+Cy4KcDAZ0+4J/ZnZMg6GP6lw4YEQutP74i6ariklkrLysfMMH+27VvXmwE 8p0GaJfBT+bpiTTkLqyra2SiCiTpEiutmjJBEwrxjI2EkOihu3nZnS7/H5o1EpDDVOGR BAr/YDpgp+gL3u9lxd03UT7pxF0xGDFeO1p3/Pwi2z+9SSM5YblZcby8ophp7NjJqLPk mLShOF/t1AkMhlKgm+zoOsF7qD6e7r90G6O2gkiRp3IP2nGbvDEUQODaOO9UhXmWca+i KsFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Lz8rGIDj9SXfgtM2+NZtPq8eRu27DnZwFYVL9tqzU00=; b=AiasjOzVvdMwaaTLrOffxocblnndO+MRk/41XjSDtdK8DIySHepuAr/P5DXYaHx9I0 VLVUUNiJMexT/AWrEifjQMC9fZHd3lotHT5EGSSVSaLKGYFy8+S0o3qfEotXqZH9ccZ0 gFhJpZd0zUHNlm3ZYzabbcxWIAfOaEVKAWO3N53noCo+iGJ7QP5AB9188Y975vFuOrOc csjyGEweDCIKSGQSR2m4KZ9nlicm1KZLduRinevtbIWOa9RQF6mxT4Z1DGNtYPUnJpti k5PjNvXdL3slwrenzss59cykY9EY1YAwxs/dAOUUw9eNynSxzFcute90pOsKdzFfTjik 0Qyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=UvzEqHXV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z10-20020a170906434a00b0072b7dab918csi921289ejm.255.2022.07.14.03.39.00; Thu, 14 Jul 2022 03:39:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=UvzEqHXV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238160AbiGNKas (ORCPT + 99 others); Thu, 14 Jul 2022 06:30:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229768AbiGNKar (ORCPT ); Thu, 14 Jul 2022 06:30:47 -0400 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7902243E60 for ; Thu, 14 Jul 2022 03:30:46 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id i14so2491184yba.1 for ; Thu, 14 Jul 2022 03:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lz8rGIDj9SXfgtM2+NZtPq8eRu27DnZwFYVL9tqzU00=; b=UvzEqHXVWDE8JyHkxyh135weDxe1AEyOVg6p1RG2QmPQVKznjn6egIm+afeDBMnEPI vS3umzYqLiGNYhv3OXv9at5XDpsjZX02DzV+g/OWAIsLT7RqwrKqgCuHnUOmwNh6oucX IgoS90dqsUP9sj5QeQI6Z7FyAAlG4GZXr3qKXfpx3nlRV6EiLFEDgWMe5JbdZug7z2Gs NtO5SsVJEI6L/1oWMeCNWl3dQNQC24m9mhPKkGZW4UIKte9CuXjBVEl5rvB4qqPkMBmn nxny9eHAzbU9D2H4/13Qpi+VjQv/rxrWcnzFGy67gj7q2tmar6F1RfU4GmBPtPRwy/E9 PYEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lz8rGIDj9SXfgtM2+NZtPq8eRu27DnZwFYVL9tqzU00=; b=lSsoh+zGiNRakNKIwbDgEKHImxC+EBap41do0izgGCBFD2Pf40yHuk49pdkghaXD1b C0YnH5jkaU4gDQ5+91SF+0IPV8A3ZCqUkRPzLmU7KCahJqxg12aoDMQIg+bJpF/0oxnS JVw1o5FtNtx7zLCckdjI0ngjI0FfBFk+plYFq3LjTq3DLrGcJRHO1fOYagFiuPMyipJe ozVUSRsVFhcTkGw5+TyAhE0gHonaLP5VrUMFNLgbfZ/au2sL1hgbtvbsOG3ZjDP0zUln cx/fs+zg0lOaxG/cn8B8MffoB8BQuA3uPutbof1uclAUdF50q++HDmyvJDRV85vpCOaV trhw== X-Gm-Message-State: AJIora9JF9sCFTB5wX70EZkRB688MS4E+KavYldL4hON0yPPcJAUBbhu jM9Csz4wJ0sruSYEy7WJXFaQWfVvO4mLsRyaP8OUKA== X-Received: by 2002:a05:6902:1184:b0:66e:756d:3baa with SMTP id m4-20020a056902118400b0066e756d3baamr7783160ybu.533.1657794645395; Thu, 14 Jul 2022 03:30:45 -0700 (PDT) MIME-Version: 1.0 References: <20220712133946.307181-1-42.hyeyoo@gmail.com> <20220712133946.307181-17-42.hyeyoo@gmail.com> In-Reply-To: From: Marco Elver Date: Thu, 14 Jul 2022 12:30:09 +0200 Message-ID: Subject: Re: [PATCH 16/16] mm/sl[au]b: check if large object is valid in __ksize() To: Christoph Lameter Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , Joe Perches , Vasily Averin , Matthew WilCox , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Jul 2022 at 11:16, Christoph Lameter wrote: > > On Wed, 13 Jul 2022, Marco Elver wrote: > > > We shouldn't crash, so it should be WARN(), but also returning > > PAGE_SIZE is bad. The intuition behind returning 0 is to try and make > > the buggy code cause less harm to the rest of the kernel. > > > > >From [1]: > > > > > Similarly, if you are able to tell if the passed pointer is not a > > > valid object some other way, you can do something better - namely, > > > return 0. The intuition here is that the caller has a pointer to an > > > invalid object, and wants to use ksize() to determine its size, and > > > most likely access all those bytes. Arguably, at that point the kernel > > > is already in a degrading state. But we can try to not let things get > > > worse by having ksize() return 0, in the hopes that it will stop > > > corrupting more memory. It won't work in all cases, but should avoid > > > things like "s = ksize(obj); touch_all_bytes(obj, s)" where the size > > > bounds the memory accessed corrupting random memory. > > "in the hopes that it will stop corrupting memory"!!!??? > > Do a BUG() then and definitely stop all chances of memory corruption. Fair enough. Well, I'd also prefer to just kill the kernel. But some people don't like that and want the option to continue running. So a WARN() gives that option, and just have to boot the kernel with panic_on_warn to kill it. There are other warnings in the kernel where we'd better kill the kernel as the chances of corrupting memory are pretty damn high if we hit them. And I still don't quite see why the case here is any more or less special. If the situation here is exceedingly rare, let's try BUG() and see what breaks?