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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C695CC43334 for ; Thu, 14 Jul 2022 10:30:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D98394019F; Thu, 14 Jul 2022 06:30:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38B56940134; Thu, 14 Jul 2022 06:30:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2784E94019F; Thu, 14 Jul 2022 06:30:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 18196940134 for ; Thu, 14 Jul 2022 06:30:47 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id DE2921211DB for ; Thu, 14 Jul 2022 10:30:46 +0000 (UTC) X-FDA: 79685336892.13.B07B505 Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf19.hostedemail.com (Postfix) with ESMTP id 7E1491A0086 for ; Thu, 14 Jul 2022 10:30:46 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id e69so2482161ybh.2 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=HInUy5mJ2xsd5hl6mPgbVd00BuUzxJ9F432yzsJeN70dW+lCftyeONx/ytqrC7ctVx NLY0/sOeQMiRhQI0jTFI6T45l9cH55qSoIrA3PTg7QFIc6TH/zTifOotyCVtI0ZOZGI2 ucmJ1oXMnyk0GcHA0DiBoJLhk/ZcmtxDkvN/NWkUljv5ABAXdM7DS8c8IA4OI5TemWnb EUde0As08aF7KXtE0WUz26B4OVhyipGOOUczTScUwZduEOmWdLmA1Y3ZXgOaua+tcSLO +97XGiCwR/VE+7pKum3hUQeH99pTg3dcCnlpBwmu6Sky163TbOQFsKynh7GT6fwy5T50 vSNA== X-Gm-Message-State: AJIora9pfzdWrXhEUS9TErwRCR65sWCk1o5pFu/+BwerUm/EhhmZCong PY1cdeZHx8s3dBLiGBJUlrVMjMygpjBzBeXtadE4Ug== X-Google-Smtp-Source: AGRyM1uIv12rQzdLqqPzl8LdX476CU5OQAwR4beJZOeqAcyUeQCaYF0ArVBVh+G01Ah8zxlMQrh15WmRaEeU1uj5Rko= 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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657794646; a=rsa-sha256; cv=none; b=TvXHFlV3HTkhXoaww0Dxz92hPNU7XoyYRFfjvSenv1DPMmSHzlBPo1VaZINawxcHKWfoJV Q8Fu1IcJ0Gl+GqXgqLxUgHoUg6XsEjju1JdzuWewXrFQwC9V2/PLXWD/VChEVZGxWsFPgP DSdFWNZYra5LoYuCJHEyg3Nr7YrAcw4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UvzEqHXV; spf=pass (imf19.hostedemail.com: domain of elver@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657794646; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Lz8rGIDj9SXfgtM2+NZtPq8eRu27DnZwFYVL9tqzU00=; b=mDK6N7fj2Haf5BT5g1qR3rKLJxaz2PGJfy2DUuQOqXgSn4rYkhVysa1DroKSJfY64nJA8M UW8zBHGuICA2VY3VlY0hJB20ZH37UzZkde+OWzWJcFU+MaRQ1/OueNrKk6/t9lCCCOe+WV ruCb8uTRCsEOaJuyUZAn1we79uMTm+U= X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7E1491A0086 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UvzEqHXV; spf=pass (imf19.hostedemail.com: domain of elver@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: 75d19qatidzspje9bcnk156wogu1kcet X-HE-Tag: 1657794646-988622 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 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?