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 7A243C43334 for ; Wed, 20 Jul 2022 10:05:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D55A16B0072; Wed, 20 Jul 2022 06:05:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D06226B0073; Wed, 20 Jul 2022 06:05:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFEA46B0074; Wed, 20 Jul 2022 06:05:52 -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 B167C6B0072 for ; Wed, 20 Jul 2022 06:05:52 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7B5C4AAE0D for ; Wed, 20 Jul 2022 10:05:52 +0000 (UTC) X-FDA: 79707046944.04.6AD51AD Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf26.hostedemail.com (Postfix) with ESMTP id 1EF9B140085 for ; Wed, 20 Jul 2022 10:05:50 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id g17so14528928plh.2 for ; Wed, 20 Jul 2022 03:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=C6Z6JqwqSHD1Pxl7j+M9Xv/wk5TAAqbSiRlE2ihHvyk=; b=U93OjkVXci1r2RHwNOXChSOl29W1H4Aw9ze6/rLApkBNlMNjYWwh/uGvi0LxozP6D1 buw7A48b80d75D7Zgy19O3zcN2oJHahtSiCUFvUwcvnYa4f1OmFdEKHPk+Tw++fHpHkO nJcwYvw5klU2ua/Fg/KSvx6R4oIGFl8JrMpq1QE1JU+tjnbuSqLcAXWEGlgkJbcJI2wa QT65DgTUFGOZ6iNbWIzr2cEEtZZ91eZzp7ZlqiItTguX0MP3qxrDuxX7bct5SPyavvoI WdBHfuJQUxq4TbLdmbklReu3rgMbjcfQpQygdILmoCpgUifHRsTbcVeroULUrVqksci+ h/dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=C6Z6JqwqSHD1Pxl7j+M9Xv/wk5TAAqbSiRlE2ihHvyk=; b=l9kTWxpTG0EJcXoXftT/2HNUjALNWcvrEVBPHBtUMHSBeFh/J7Otd1dC/rzIwp4KtI eqQfvoY/xEbCEWiX2JaH7wFLMRRuRc49sPOZ+/8fdoGJ/0C4n3Kx6npdIiG8SLOiWAo4 bl/fAdltCbqoQcGd9SiF3/0iNCKXABscxO6S+0NnP4RCEWD2MdlTlLHEPP1edzieCVxv oS/9QEIMsYgpXEHN4sS8igKql9b1v2qC73yDpR+kJlezUjHWCtkPviX88a4dxPrlL5dV /Ab2RbYj2/bo7laUativk8CGxl/HAGgZh/3TS7qxMyNXd4HYJXIV9RuJsjIYYbvn7mn5 cK6w== X-Gm-Message-State: AJIora9RZPzNrnnAiFYwjZHYN1ydiMTT8Wj9aRQs6gka/CyJVamuKh29 MTIalDOuIjdU/rG9hFBuDU8= X-Google-Smtp-Source: AGRyM1s3ABuJ5Rs4YNmUtYSHTpyCuFYVnS+sK83V2uuFqCcwAy9zWvOS/H0Vol7ECwJ7WWBHG751kw== X-Received: by 2002:a17:90b:1c09:b0:1ef:f82c:174b with SMTP id oc9-20020a17090b1c0900b001eff82c174bmr4411389pjb.88.1658311549965; Wed, 20 Jul 2022 03:05:49 -0700 (PDT) Received: from ip-172-31-24-42.ap-northeast-1.compute.internal (ec2-35-78-228-6.ap-northeast-1.compute.amazonaws.com. [35.78.228.6]) by smtp.gmail.com with ESMTPSA id r5-20020aa79885000000b00525442ac579sm13137201pfl.212.2022.07.20.03.05.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jul 2022 03:05:49 -0700 (PDT) Date: Wed, 20 Jul 2022 10:05:44 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Marco Elver Cc: Christoph Lameter , 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() Message-ID: References: <20220712133946.307181-1-42.hyeyoo@gmail.com> <20220712133946.307181-17-42.hyeyoo@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=U93OjkVX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658311551; a=rsa-sha256; cv=none; b=Q/2uciueWwYRFQQG1Ob0D4wtOhPreo+tTLzzmOF41YwRBAoZ5pAHa6cUA5ZBB1PeQUejmH oxCJzORmo/qyQhi3BitiinGqLl6xmv3g7cmJZU0pKDIlpZH2IO3keORZWVVlXv3UhpYh3+ MSBPjSt6xQ85qwhQGJHgUKfMSryVhEs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658311551; 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=C6Z6JqwqSHD1Pxl7j+M9Xv/wk5TAAqbSiRlE2ihHvyk=; b=CISWgkHeYEG3QB+ppGhLw4gba0hb7zYtCnBH05M8AP1EJGK9IOqqpWv03bMDmzO2HiGdZ8 r/7txvdEy0fRYu0xoJw/XHJ3McSISbwOijdvYtw0P9uzM4RLVdvxxptsHA06I6SAiDgFry R2GmIb1tsYMVBci/LHRX5wzDK8244o0= X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1EF9B140085 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=U93OjkVX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Stat-Signature: aeuy451zos7najiq8e9kjic11bqkchnp X-HE-Tag: 1658311550-17476 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, Jul 14, 2022 at 12:30:09PM +0200, Marco Elver wrote: > 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? Let's try BUG() for both conditions and replace it with WARN() later if kernel hit those often. I'll update this patch in next version. And I have no strong opinion on returning 0, but if kernel hits it a lot, I think returning 0 would be more safe as you said. Thanks, Hyeonggon