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 C9186C433FE for ; Fri, 4 Mar 2022 13:12:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 22FCD8D0002; Fri, 4 Mar 2022 08:12:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E0458D0001; Fri, 4 Mar 2022 08:12:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D0338D0002; Fri, 4 Mar 2022 08:12:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id EEC258D0001 for ; Fri, 4 Mar 2022 08:12:27 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C0B122568E for ; Fri, 4 Mar 2022 13:12:27 +0000 (UTC) X-FDA: 79206742734.15.C8FB5C8 Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 27541100011 for ; Fri, 4 Mar 2022 13:12:27 +0000 (UTC) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-2dc242a79beso80396427b3.8 for ; Fri, 04 Mar 2022 05:12:26 -0800 (PST) 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=+H2bUE5UsRsJ8ptX5NtZZM4AcJoObuD1URIhhCGz76U=; b=WhB6Wh48TEvBjTMv5sZSD54nnulAJ98TiG3gAlpuBqQcLeaGikVqYWVb/nhT8a5XdL yy2hwNvFmjgolm5P3uKxHN+2usV3ZsLzdIR9+xopAPcebCiRHAT26e6UquIRe9sP3NFk b4uQfK4KXV9leOilYP5YntZClBt/2p3OhyB7FypzGZiCzvYud137u1x/16P5AnpwKPXA MATxTbv4ooL9VCRFkrLEFjYTVhVPDa9oKeLFHNVFMTxvKXwl3S5xjrz2UMwYLJ2804kn FIcK4vbe6j4VBpwCQi8MLvPLCsLluqvS6oyRyjWXsfDkXXgSEcuR7Hq/OrZ1eGRwvSdx 0hRA== 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=+H2bUE5UsRsJ8ptX5NtZZM4AcJoObuD1URIhhCGz76U=; b=4FSbjJ9wpHX25bZQhKSANq2mmIkw2fpQ+r7P+f4osAw7Bx/7gdw39bWNO0a4hMQoCS DJoZ7Wqa0bhzYCylocR7XLT58+yo94Hg6t2uhe/WHAoRIIgyoBK/6BIiKb9F6rR5uFiQ JDhzjkMQosy2FJcVSyMSFCbn6gxhOJAVqTh2HRYDycXLyySZTmFFKpMR2CPiFdxtMumg QOu2O+g9BH7/7D0jQ5epfytcbnX5EwZN4tEsl+gejL9LUS/VWc5hex+NUbwOU+JzA4/P eaeJHu+ODoC+dsvGIxB3siSIVteaCAuVoEKqOA4sQIqF5WfALlBmCD387FATtW5MdnUa Hz6w== X-Gm-Message-State: AOAM5311uzGVN3M1dk3ondn80I4wXknHH6USwFFWqUf9ALEWbHr2dZzm 9W8Vvgi3p+UhFn3jsuq7EnHYL1nlUx7tRrXZCjuY2A== X-Google-Smtp-Source: ABdhPJxjkfwG98FgwOAXl83TLDHcTm1Al4pPfH1i7QQy4ifqoR9WTmSoh3auS2zPcJ0r2ugyjkD9CXiSzzilelN6HjQ= X-Received: by 2002:a81:8985:0:b0:2dc:472:ff3f with SMTP id z127-20020a818985000000b002dc0472ff3fmr14307942ywf.333.1646399546204; Fri, 04 Mar 2022 05:12:26 -0800 (PST) MIME-Version: 1.0 References: <20220304063427.372145-1-42.hyeyoo@gmail.com> In-Reply-To: From: Marco Elver Date: Fri, 4 Mar 2022 14:11:50 +0100 Message-ID: Subject: Re: [PATCH v2 0/5] slab cleanups To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm@kvack.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Matthew WilCox , Roman Gushchin , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 27541100011 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WhB6Wh48; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of elver@google.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=elver@google.com X-Stat-Signature: jw7cy17ehanddrwui35sdt61qcazwprp X-HE-Tag: 1646399547-810936 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 Fri, 4 Mar 2022 at 13:02, Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > On Fri, Mar 04, 2022 at 12:50:21PM +0100, Marco Elver wrote: > > On Fri, 4 Mar 2022 at 07:34, Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > > > > > Changes from v1: > > > Now SLAB passes requests larger than order-1 page > > > to page allocator. > > > > > > Adjusted comments from Matthew, Vlastimil, Rientjes. > > > Thank you for feedback! > > > > > > BTW, I have no idea what __ksize() should return when an object that > > > is not allocated from slab is passed. both 0 and folio_size() > > > seems wrong to me. > > > > Didn't we say 0 would be the safer of the two options? > > https://lkml.kernel.org/r/0e02416f-ef43-dc8a-9e8e-50ff63dd3c61@suse.cz > > > > Oh sorry, I didn't understand why 0 was safer when I was reading it. > > Reading again, 0 is safer because kasan does not unpoison for > wrongly passed object, right? Not quite. KASAN can tell if something is wrong, i.e. invalid object. 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. The other reason is that a caller could actually check the size, and if 0, do something else. Few callers will do so, because nobody expects that their code has a bug. :-)