Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2992952pxm; Mon, 28 Feb 2022 09:54:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJwlWBf5YisruG+Ox3ueVk9kl12LJasJ1RGG6NRmMJP8IvDe4H2UXav/9sH8uSr2cMgHVNVA X-Received: by 2002:a65:5888:0:b0:374:5575:ba08 with SMTP id d8-20020a655888000000b003745575ba08mr17913076pgu.375.1646070891038; Mon, 28 Feb 2022 09:54:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646070891; cv=none; d=google.com; s=arc-20160816; b=B0t23hk8dNc1Q8KsTw2hE3S7AXfwWRHAO2JGay0PBfvBNbRGQV4gaNXAHsTti3XyWS Bsz39gKlbyP7UH3BweVFRGWiXayLS2e3w9QL1fpK5mdjYjk6HihaIprr7PhCgm6fA456 /ejsmP9rOkHXOO2j+aKNtv2X0Q9nY2qCgZg6M7jTXN/BR0/4uHZGKA72/AX1KEn9tDrj Oq3T2+Pvl5ZBKX1k5S2zYtXbmU6AtDbYcCSqavky8NhD+qhfkmpAZtjjNYj3p8EQwQkT QfX1keRK1bzwQ0P61UQ4PElNX/IpBdjAxJZFhMDNCax0VAkblF/WrUN/qqCty+ePRbaA GbpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Se4zhHEaPU9V1yfCSSf057AkUax+xeAkyFZTtecsvOk=; b=yYlnPsUc9+v0yOyaEl89+DcLAhNcANnpnPVyFS7wWiYs2xCQHBIYu2EO7yANy488pv 059q+TSzLfR2DeR079DCXbcgyltVZypXBaP0sEykmTZpOxBA6O+gblgummtBPJgBk7f3 yWBEF5pd8H7n+SKa0q8ugg63vI5FSpPtfCx1qelIX2Y4U3r3gVXVA7UK53QZnNf6w6xS JkyfC4FNJgxbKdkNiLuUR0n0C40+yK2Pf1jDMW7GNmY3xSvlgyet+TNeVNVHU5Lnmjnd sa+xsugd67dOUwplXmEeEovy9PhOQecXubWP36P4qD9tkSA4Ae53g5tQqlMdUQeM87tN UTTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=PnNjZmmz; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q75-20020a632a4e000000b0037843b0a6dasi9026779pgq.3.2022.02.28.09.54.35; Mon, 28 Feb 2022 09:54:50 -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=@suse.com header.s=susede1 header.b=PnNjZmmz; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237006AbiB1RLI (ORCPT + 99 others); Mon, 28 Feb 2022 12:11:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230161AbiB1RLI (ORCPT ); Mon, 28 Feb 2022 12:11:08 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33EFE7486F; Mon, 28 Feb 2022 09:10:29 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id B991C219A4; Mon, 28 Feb 2022 17:10:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1646068227; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Se4zhHEaPU9V1yfCSSf057AkUax+xeAkyFZTtecsvOk=; b=PnNjZmmzjdTC81o0wLPptLX10/+Iqzu9UE7f1fYDvqrY9DjWKwDYuchbuOlnzNHqKiz7i/ VgsVDpACPfAOiCFoQgHhtieQhBQ0PYUePRxXsQo74Sgh7/dwKZjhxAc2xZ1jOwHdFlpCAB kGthl5H97S97NGMn34uqJdlHcSsP4fg= Received: from suse.cz (unknown [10.100.216.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id B3B8FA3B81; Mon, 28 Feb 2022 17:10:26 +0000 (UTC) Date: Mon, 28 Feb 2022 18:10:26 +0100 From: Petr Mladek To: Andy Shevchenko Cc: Maninder Singh , mcgrof@kernel.org, rostedt@goodmis.org, senozhatsky@chromium.org, linux@rasmusvillemoes.dk, akpm@linux-foundation.org, wangkefeng.wang@huawei.com, v.narang@samsung.com, swboyd@chromium.org, ojeda@kernel.org, linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org, avimalin@gmail.com, atomlin@redhat.com, Kees Cook Subject: Re: [PATCH 1/1] kallsyms: enhance %pS/s/b printing when KALLSYSMS is disabled Message-ID: References: <20220228053447.1584704-1-maninder1.s@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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 Adding Kees into Cc. This patch allows to see non-hashed base address of the module and eventually of vmlinux, see below. On Mon 2022-02-28 14:03:30, Andy Shevchenko wrote: > On Mon, Feb 28, 2022 at 11:04:47AM +0530, Maninder Singh wrote: > > with commit '82b37e632513 ("kallsyms: print module name in %ps/S > > case when KALLSYMS is disabled"), module name printing was enhanced. The commit does not exist. Note that linux-next is regularly rebased. Commit IDs might still be stable when they are merged from a maintainer git tree. But Andrew's -mm tree is imported from quilt and the patches always get new commit ID. The best solution is to handle the changes in a single patchset. > > As per suggestion from Petr Mladek , covering > > other flavours also to print build id also. > > > > for %pB no change as it needs to know symbol name to adjust address > > value which can't be done without KALLSYMS. > > > > original output with KALLSYMS: > > [8.842129] ps function_1 [crash] > > [8.842735] pS function_1+0x4/0x2c [crash] > > [8.842890] pSb function_1+0x4/0x2c [crash b367e79021b9f3b0172f9a36d4261c1f528ca1b3] > > [8.843175] pB function_1+0x4/0x2c [crash] > > [8.843362] pBb function_1+0x4/0x2c [crash b367e79021b9f3b0172f9a36d4261c1f528ca1b3] > > > > original output without KALLSYMS: > > [12.487424] ps 0xffff800000eb008c > > [12.487598] pS 0xffff800000eb008c > > [12.487723] pSb 0xffff800000eb008c > > [12.487850] pB 0xffff800000eb008c > > [12.487967] pBb 0xffff800000eb008c > > > > With patched kernel without KALLSYMS: > > [9.205207] ps 0xffff800000eb008c [crash] > > [9.205564] pS 0xffff800000eb0000+0x8c [crash] > > [9.205757] pSb 0xffff800000eb0000+0x8c [crash b367e79021b9f3b0172f9a36d4261c1f528ca1b3] > > [9.206066] pB 0xffff800000eb0000+0x8c [crash] > > [9.206257] pBb 0xffff800000eb0000+0x8c [crash b367e79021b9f3b0172f9a36d4261c1f528ca1b3] > > ... > > > +static int sprint_module_info(char *buf, char *end, unsigned long value, > > + const char *fmt) > > +{ > > + struct module *mod; > > + unsigned long offset = 1; > > + unsigned long base; > > > + int ret = 0; > > This is hard to find if it's not close to the first use. > Since you are using positive numbers... The name of the variable is misleading. It is not a return value. It is set when: if (mod) { ret = 1; and used: if (!ret) return 0; In fact, we do not need the value at all. It is enough to do: if (!mod) return 0; > > + const char *modname; > > + int modbuildid = 0; > > + int len; > > +#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) > > + const unsigned char *buildid = NULL; > > +#endif > > + > > + if (is_ksym_addr(value)) > > + return 0; > > > + if (*fmt == 'B' && fmt[1] == 'b') > > + modbuildid = 1; > > + else if (*fmt == 'S' && (fmt[1] == 'b' || (fmt[1] == 'R' && fmt[2] == 'b'))) > > Why not to split to two conditionals? Would be easier to get, This is copy&paste from symbol_string(). > > + modbuildid = 1; > > + else if (*fmt != 's') { > > These all are inconsistent, please switch to fmt[0]. > > > + /* > > + * do nothing. > > + */ > > + } else > > + offset = 0; > > + > > + preempt_disable(); > > + mod = __module_address(value); > > + if (mod) { > > + ret = 1; > > + modname = mod->name; > > +#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) > > + if (modbuildid) > > + buildid = mod->build_id; > > +#endif > > + if (offset) { > > + base = (unsigned long)mod->core_layout.base; > > + offset = value - base; > > + } > > + } > > + > > + preempt_enable(); > > > + if (!ret) > > This looks a bit strange, but okay, I'm not familiar with the function of this > code. Yes, this can be replaced by /* We handle offset only against module base. */ if (!mod) return 0; Hmm, why don't we compute offset against vmlinux base when the symbol is from vmlinux? Wait, this would show base address of vmlinux. It would be security hole. Wait, if the base address of vmlinux is security hole then the base address of module is security hole as well. IMHO, we must hash the base address when the hashing is not disabled! > > + return 0; > > + > > + /* address belongs to module */ > > + if (offset) > > + len = sprintf(buf, "0x%lx+0x%lx", base, offset); > > + else > > + len = sprintf(buf, "0x%lx", value); > > + > > + len += sprintf(buf + len, " [%s", modname); > > +#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) > > + if (modbuildid && buildid) { > > + /* build ID should match length of sprintf */ > > + static_assert(sizeof(typeof_member(struct module, build_id)) == 20); > > + len += sprintf(buf + len, " %20phN", buildid); > > + } > > +#endif > > + len += sprintf(buf + len, "]"); And all these sprint() calls are copy&pasted from __sprint_symbol(). We really should reduce the cut&pasting. > > + > > + return len; > > +} Best Regards, Petr