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 0F61FC433F5 for ; Mon, 28 Feb 2022 14:48:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A21C38D0002; Mon, 28 Feb 2022 09:48:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D1658D0001; Mon, 28 Feb 2022 09:48:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 872638D0002; Mon, 28 Feb 2022 09:48:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 75CE98D0001 for ; Mon, 28 Feb 2022 09:48:58 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2D91D180972B8 for ; Mon, 28 Feb 2022 14:48:58 +0000 (UTC) X-FDA: 79192470756.27.B9557C9 Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by imf04.hostedemail.com (Postfix) with ESMTP id B85DB40017 for ; Mon, 28 Feb 2022 14:48:57 +0000 (UTC) Received: by mail-oi1-f170.google.com with SMTP id s5so13378521oic.10 for ; Mon, 28 Feb 2022 06:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VlG4fI6bBYkPpFcbAcTm6hy8fXOzxdf1xdGq3BMqoYc=; b=IW8WA+AHr1t9GtRiZH0kfoy7+BwA7nt0t5LtGYYh6UC7qVANOORD8+NYp2VDFEaLih 69yLwp5vFOImHYnnHKAJmqMXiOYpYu5K40FCN6EVsxs4NDhi/NAR/kMTupV72PHmZj8/ s27FvOXqNvosbqWAjlfjIbTZCj7XHNIYPS+keTAhKiZKucS6GFOq3Td2UarGICuQcZSE vqSzUttCvRBlCk/2ueOnGTzX4Ij7/hC0cHKg2S1zkjYzwbz8VRaOZ+6asW17dU8XAoxZ vE0GBKMiItHZd6MXyzf1WiDykJme8psjV0JdWoqGlPVDq4XSWEeLUmH3g6knc+e9oczC JmzA== 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=VlG4fI6bBYkPpFcbAcTm6hy8fXOzxdf1xdGq3BMqoYc=; b=BvESIxaCLo+68cY+/VIJuMMYYbCSqJljPfyGcQpzFT2aKV5vXRlTmT3MjV7eIjNPH2 mNNoLHDEdLEJpX+MNBj3v4pU5FAO/u2NXnJnFMbxXqzEuPfkPt5VZFdsxTZyO/wBQTGE oSqEVKLj0EwkIkx42GsfXAa0cXbgf12oc+QFocAJprRvLUwblHITDdtoBCpNisA13Mp5 l2cYdLy0u5uG+R1sVd2w+8fwimz/pCRhizxq8oJN2se3ZzWEgd8VYRMBZFRTRS0tnHq5 LEsVVy30e7Na54aw+CJ/G4YTLfxcgplUv2KC+LIxJADviwaaVh5Jks50p2Y5hvuT21Bw XdmA== X-Gm-Message-State: AOAM531FHR1KDcn0uUuR54Myq/LHJZm7Hxv+uugkLvjHK6hmutjj7Dyo nE0uNNHrgOMN+U+xYlA1gNgzwUtd3GUXYf5S+Wk= X-Google-Smtp-Source: ABdhPJxyeCNuUoc7Rc3If7ObB7hMpxFXHG9BXhesgjQMW03kyvafsvGo0AMIsg//K2PlG2nzgM4LsOSq+L/xbj8gEgI= X-Received: by 2002:a05:6808:124d:b0:2d7:f6e:74b0 with SMTP id o13-20020a056808124d00b002d70f6e74b0mr10939977oiv.141.1646059737002; Mon, 28 Feb 2022 06:48:57 -0800 (PST) MIME-Version: 1.0 References: <20220225221625.3531852-1-keescook@chromium.org> In-Reply-To: From: Daniel Micay Date: Mon, 28 Feb 2022 09:48:41 -0500 Message-ID: Subject: Re: [PATCH] mm: Handle ksize() vs __alloc_size by forgetting size To: Marco Elver Cc: Kees Cook , llvm@lists.linux.dev, Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org, stable@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Christoph Lameter , Nathan Chancellor , Nick Desaulniers , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: nuyztncpe1gaeazm4bo5pz61m3km1pn9 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IW8WA+AH; spf=pass (imf04.hostedemail.com: domain of danielmicay@gmail.com designates 209.85.167.170 as permitted sender) smtp.mailfrom=danielmicay@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Queue-Id: B85DB40017 X-HE-Tag: 1646059737-876160 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: There aren't many calls to ksize in the entire Linux kernel source tree. Most use cases are using the memory as some kind of (chunked) dynamic array, where they either need to realloc or kmalloc a new chunk when it runs out of space. Changing the approach to this API would be both more efficient and fully compatible with alloc_size since it would simply not be added to these functions: kmalloc_size(size, &result_size) krealloc_size(p, new_size, &result_size) Nearly every use of ksize could be easily phased out this way. There are probably a few which are harder to remove. It can be gradually phased out by keeping around ksize temporarily but documenting that it's only correct to use it on memory allocated with kmalloc_size/krealloc_size. I think it can be phased out quite quickly though. Look at how many calls there are to it. It's really not a lot, especially if you filter out the uses of the identifier 'ksize' for variables rather than calls to that function. I brought this up when I originally submitted CONFIG_FORTIFY_SOURCE. It's the main reason that I didn't bother trying to submit the alloc_size attributes myself. The most important ones are for kmalloc and it isn't technically correct to use it.