Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2362693iog; Sun, 26 Jun 2022 13:52:43 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vs75HTHEHxlu2LTYDLX5WCcM+5WQm9HEfxTndrRAxLYk/k2c119mEWRtesUfV+iRda5isZ X-Received: by 2002:a17:902:f78e:b0:168:fffc:fd57 with SMTP id q14-20020a170902f78e00b00168fffcfd57mr10905218pln.149.1656276762951; Sun, 26 Jun 2022 13:52:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656276762; cv=none; d=google.com; s=arc-20160816; b=lkXURg3eJ7sIAh0fgbZji7waxTKlN8VB2rwWh6godbOc+9Uy7hQhqL1OycWYwz+Q8G pAiHh1pEPmOBxIDGtAo8Kx8UH3xJtU3xibP+/09kGNC8wU+vEbXOw2C6jm46PZLBrII4 xTzqeRtYSVY51lgFYd+bpW9RQbx6TE9YK+xQwp06iiRkyUyX7JYfSZFNkr5BlIqQDCs+ cjIdAvyal5KGEyVk8qo5d9rdvFfF2GNoYj0w1Qlir0hNVgU5VZAB6fT/q/kPMc1UDPV5 Ubq0AEgDf+hIscpV1Oi+w0XOAMIn2Nhb/rrTTsDHEX0u+rM6cyQe7Qnl1nJbfKleGx/X gPKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id; bh=mgq7FFpH/BLPQT86y9qHKFEwOfJ72dPwX4bh/orOmZI=; b=EcuVMmISsnah5r+eq7PBBA7+fGuKPu7/VcZusD+fieYxKVFOO7j2OttEtDZcMS4iVk KWV3xuYcY/aOMSj+k0kaDT2mqa5lIw9pXp4NDuib83jDL1WiwAvfrQn+M099ACoMxLiF rFELW3K1tbDhF/maBSXJMcHFDA15/PBxjnfUjr6Upaf8WDomCej2mgZ4tDATD2RaxM8g Y2WsAJca5ZiRRF2kn0gbssYou1PiSDas/Mb14gxGbV04vXoYMzGfempTRONlGGlSU3gK LgeuVYYqbwyhJ05/9lijUM5wPFcidMwWNcqOoW6iZS5y9RXBUMzYZS4Wkb+GzfwCoOe7 4unQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u196-20020a6279cd000000b0050ddce187edsi11216639pfc.331.2022.06.26.13.52.31; Sun, 26 Jun 2022 13:52:42 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231939AbiFZUjN convert rfc822-to-8bit (ORCPT + 99 others); Sun, 26 Jun 2022 16:39:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229955AbiFZUjM (ORCPT ); Sun, 26 Jun 2022 16:39:12 -0400 Received: from relay4.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 806A0DD8 for ; Sun, 26 Jun 2022 13:39:11 -0700 (PDT) Received: from omf08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 0A933120DAD; Sun, 26 Jun 2022 20:39:09 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf08.hostedemail.com (Postfix) with ESMTPA id 77FB020025; Sun, 26 Jun 2022 20:39:02 +0000 (UTC) Message-ID: <93ab94ec92497af13c563c52fc7e1f7f81dac333.camel@perches.com> Subject: Re: [RFC[ Alloc in vsprintf From: Joe Perches To: Linus Torvalds Cc: Andrew Morton , David Laight , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Rasmus Villemoes , Matthew Wilcox , Miguel Ojeda , Kent Overstreet , Andy Shevchenko , LKML , linux-mm Date: Sun, 26 Jun 2022 13:39:01 -0700 In-Reply-To: References: <20220620004233.3805-1-kent.overstreet@gmail.com> <0a5901f8460f452a89c9b0cda32fb833@AcuMS.aculab.com> <20220620150514.3tjy5dv7pv5frcwd@moria.home.lan> <53d77ae6101a0f24cfb694174d4c7699424c57e8.camel@perches.com> <20220621005752.ohiq5besmy3r5rjo@moria.home.lan> <355e912490dbaef8fe4e12df0201c3f5b439565d.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Rspamd-Server: rspamout03 X-Rspamd-Queue-Id: 77FB020025 X-Stat-Signature: k6zu5exz6pfmapas8yidcramkpopggc3 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX1/JLXlIzYuF27J9e1KXiNp5QhT/nSZMl8E= X-HE-Tag: 1656275942-506383 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 On Sun, 2022-06-26 at 13:19 -0700, Linus Torvalds wrote: > On Sun, Jun 26, 2022 at 12:53 PM Joe Perches wrote: > > > > In a reply to the printbufs thread, I wrote a proposal to use an > > alloc to reduce stack in vsprintf when CONFIG_KALLSYMS is enabled. > > > > No one has replied to this but I think it's somewhat sensible. > > I think that's a bad idea. Somewhat sensible not sensible... > Those things are *literally* called from panic situations, which may > be while holding core memory allocation locks, or similar. True, and special_hex_number was used on alloc failure. > Now, you are correct that the stack buffer is annoying. But I think > the proper way to fix that is to say "we already *have* the target > buffer, let's use it". OK, and that's true for all the temp stack buffers in every %p. > That does require teaching the sprint_symbol() functions that they > need to take a "length of buffer" and return how much they used, but > that would seem to be a sensible thing anyway, and what the code > should always have done? Unnecessary stack and/or unnecessary buffers for printbufs are just unnecessary. > It's bad policy to just pass in a buffer without length, and I think > it was always broken. Nasty. That KSYM_SYMBOL_LEN is magically taking > care of it all, but it's ugly as heck, wouldn't you say? Yup.