Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3001431pxm; Mon, 28 Feb 2022 10:04:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJwRdpDbTeOEPan8Jx5ztMn02MiTFiImLAaVFY4vSwYqydzyXC6w2aK/Ruz7mvEtMoutm5CV X-Received: by 2002:a05:6402:90a:b0:408:4f50:c566 with SMTP id g10-20020a056402090a00b004084f50c566mr20601597edz.41.1646071449823; Mon, 28 Feb 2022 10:04:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646071449; cv=none; d=google.com; s=arc-20160816; b=IMXtsnkIdPTl2E5VQ93vS0ECsZLtJHPtBGByE9x3X1TNpr45jtrg+VyH19fwKC/2n2 cYcT2JAItk099SSS63USVdEUxTTYEKCw40eBWN8dgc2EJwizNDGMch+RQUE+qu5BZCNk xk38cAq+rd9t3E/PtfybyHoS/CLHW0HrV4G3I29dgW5e3dhgx8qXM9mw+2noiGdczaBT WONNEBWedvj/gKPXtj+dgVWa1BsFgGBSBSSSz4C2P2m2ROB7zzSCmJ4oLdLr7KFQCbSw qkwW/mcQpfNLQmETzKsTzSgPpHnasKfmSgTUJanwZiWAeEhYBWXr7sFhaqbZDT9RO3ij wJIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=VlG4fI6bBYkPpFcbAcTm6hy8fXOzxdf1xdGq3BMqoYc=; b=Ez94M7bbFRmzIxrzALvNL+3ZQdUiwyD/L0pmnVfvzZ4trleVTJ4nFq7yc9hlyHhESO eLUBryegjdT7QubI9T/bgcuBWL8F9F/W7ltA86BfYtRV7l3Y/gSlh4+zXTlGOWR6wL3G RxMkcNTbmoPTMmY3j3we+6262yX8OMzzbv/KXhLEXt+fQ85yMgKMbWm5Uao3f8rI4WNK uAM5XJY99fulBKLa77zEQt/vH2qZHODXKnjE+SbFLYkPnif998UeEIKWhhOijB9yM4lk /90XVeGZsIlZnU8Mt8W4f4T5YDlgQDQ2dmVSM/OCfIE0DqkYiEJVArbXcS8P/6tcmtNL y3Ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=IW8WA+AH; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v19-20020aa7d9d3000000b00412b2d0d205si6895643eds.487.2022.02.28.10.03.47; Mon, 28 Feb 2022 10:04:09 -0800 (PST) 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=@gmail.com header.s=20210112 header.b=IW8WA+AH; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235808AbiB1Oth (ORCPT + 99 others); Mon, 28 Feb 2022 09:49:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229926AbiB1Otg (ORCPT ); Mon, 28 Feb 2022 09:49:36 -0500 Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CE743BA56; Mon, 28 Feb 2022 06:48:57 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id ay7so13376976oib.8; 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=ahKdvqfFwi8ByCEP3GL5SFSFUoHtq4KH+ezV9hRcydoUpoNONF2lKUJ5O2vcAhVywK Y2xs5b5Fuiqtve+7UOGlsWCaOjqpZXQVK7MEcxgArooZcq+q1pJBz7RfrkLTFiqJmamJ tXMODDwNVKzELfHCs+EInLT8pZatHJPKxe2p68pzPkpCaiatuXbVT9jLWig9yj1qC/cN Cid8a/gAUmd7cG9ZjttBia6LOjMoMbSEz5ntYcZg9RlB2/1v+V9w62jJ0VqgI2B0gA8x tQKtZBtpNJMd5beqraC1yYi4RB0aSiyVguD84NvOJzV8RLOSVtwV34uAhz9YJZD8JxTC YMzQ== X-Gm-Message-State: AOAM531gATUR0IFi3zNjBQ94VtG/HTa2hbQTPHMT20ZAlzDJSmnyDi6l isvVFjnhhZjPp0/LUyg2HiP0yWaHb1Ve+ZCGk9M= 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-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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 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.