Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp349208imw; Thu, 14 Jul 2022 02:27:45 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vdjU7ca67TyBiWcGbKLuNBSlAlPtghnqmC17clzMXvNRo9e+T5+qJ0zxl6YYWBfgMbRLzP X-Received: by 2002:a05:6402:11c9:b0:43a:b054:52ba with SMTP id j9-20020a05640211c900b0043ab05452bamr11251048edw.344.1657790864967; Thu, 14 Jul 2022 02:27:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657790864; cv=none; d=google.com; s=arc-20160816; b=DbcUQEzhqBO8zADXnsNQYOsO1zcRE/i+Njj36OIpSjbS+zjPXMDRX1biVtoEn3xwxp OQu2BhdJMjJXWcfwKV3vsugyePRtqSbxybUNczqd84f7LaVL/aDLUXi+KshZqGy7PG+t ACAeMWEwcPbi+idz4dp6c/5YU20L109BcqPNqFOelgmdunKUlZNjFpLetO5bRS6wXQzF FpPwjl7/DMGSFhiov/lnAuHgGoYI/7LOIWXseiI0yDvZ9hhfDGhJiB/OXDXr0/uvi8u7 wamy1a5Lw4TCbYQDj6+qp9qxe2/cSsGUYevaScsr2XTrCmjiwRdcGM42m1T6fjBjpY3P Tzrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=32hwBy0u3/431+faOWAMGVXWX8xeJyN/BOQ9pzsMuOc=; b=bqNVJ0P8slgx6gsSauZ2mXVO01qjs94eWTD45NatNzgyPn6ANIfkcWMojr2J7dSDLr ZaCN3IvA0JHWQ2HEELJtMhwPwv7ulTNxBrIJUwWvJhD74Itkw7ulZe7pmDme1blnjYFi wL2vxARU6i7gBg1cF8PJYQJ8/6d/8iE9Cuoza79nxoB2G2MolnLuYl3CvbnG2nt5niqR k6xPHLkq4i50HoPvhiXWkl42ZfH5YABcuV56Z8E4gO0dSOzgKGE+cPpq/FVGqZnRYzVx 5znx3ZZvVHE5sItdlBuym+Uhz+zO6KkeY0OLOt6KH/BXULFqbhiIaHzuWogqCZ1/JIJj 6c1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gentwo.de header.s=default header.b=xDw5deea; 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=NONE sp=NONE dis=NONE) header.from=gentwo.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i14-20020a1709064fce00b0072aa56cd0a3si1702708ejw.28.2022.07.14.02.27.20; Thu, 14 Jul 2022 02:27:44 -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=@gentwo.de header.s=default header.b=xDw5deea; 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=NONE sp=NONE dis=NONE) header.from=gentwo.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237877AbiGNJTc (ORCPT + 99 others); Thu, 14 Jul 2022 05:19:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238214AbiGNJTQ (ORCPT ); Thu, 14 Jul 2022 05:19:16 -0400 Received: from gentwo.de (gentwo.de [161.97.139.209]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F36F724BD9 for ; Thu, 14 Jul 2022 02:16:32 -0700 (PDT) Received: by gentwo.de (Postfix, from userid 1001) id ED319B0028E; Thu, 14 Jul 2022 11:15:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.de; s=default; t=1657790159; bh=32hwBy0u3/431+faOWAMGVXWX8xeJyN/BOQ9pzsMuOc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=xDw5deeaOdaaXyFY5w2uRpXZqhwlePLrMk4hMaLuuhKWpFcjV947IocSt5ERy3Tdx k/XbxvqYbjcn7QgQuWL5mZJoyOmk8BZBDc/FpXsJmyWyZzj+BLH72+eZOK7NkBw0Ty W8RkBVNsoVA07SxBEMUzERVAuK89CxFBVwF7gv+58r3jVa5/cL8pLnQFVS/cYzn1KX CQ3xqb+vCzIAOS7FQksZX7h8PB9PoipmKYvnvLwEDFepUWb2d8Ud4D5/0MTINSBr+u cEuMOLN1xu1E3e0qlX0Mly4sNdgDn4gb0lz7280QQlzc9kePgcgrDx04QAmiFTdWhA x91A2HD/88V+A== Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id EBC0AB00266; Thu, 14 Jul 2022 11:15:59 +0200 (CEST) Date: Thu, 14 Jul 2022 11:15:59 +0200 (CEST) From: Christoph Lameter To: Marco Elver 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 Subject: Re: [PATCH 16/16] mm/sl[au]b: check if large object is valid in __ksize() In-Reply-To: Message-ID: References: <20220712133946.307181-1-42.hyeyoo@gmail.com> <20220712133946.307181-17-42.hyeyoo@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE 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 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.