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 20085CA0ECA for ; Tue, 12 Sep 2023 09:41:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41F816B00CD; Tue, 12 Sep 2023 05:41:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CF2D6B00D0; Tue, 12 Sep 2023 05:41:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BDC66B00D1; Tue, 12 Sep 2023 05:41:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1AD6C6B00CD for ; Tue, 12 Sep 2023 05:41:42 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E086AC0DFC for ; Tue, 12 Sep 2023 09:41:41 +0000 (UTC) X-FDA: 81227453202.16.6915D0D Received: from sipsolutions.net (s3.sipsolutions.net [168.119.38.16]) by imf13.hostedemail.com (Postfix) with ESMTP id 34D2420004 for ; Tue, 12 Sep 2023 09:41:38 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=sipsolutions.net header.s=mail header.b=gyXzZN77; spf=pass (imf13.hostedemail.com: domain of johannes@sipsolutions.net designates 168.119.38.16 as permitted sender) smtp.mailfrom=johannes@sipsolutions.net; dmarc=pass (policy=none) header.from=sipsolutions.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694511699; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5mkwbqFuSv2hlymMhsu3M4LU2jbDB6uW9iOmS/v2SLU=; b=q+fSgs4ClERyKpsPRmjaeFgjbZHFGkIdbXYwRwbIoF0niJ9/w/8k9V0sogvRJzUMETl1vw Nkn0D+E0P12nlk+v/9JNdZw9dAsmhnpsO/r22lGgAnyfZ7dSBNUTwptgU5V0+UKhMBjJZL +pvVMbKudHyN31odKS8MVjRuXG02kcs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694511699; a=rsa-sha256; cv=none; b=R8Q1L4Wn31zOpOm68BxPAmuw9V7vo7eVenQD7/u0M3WeU+ED59mKBgvUTX1eLblKFLHwGT wI7YwvFu0wK48JhEOR6WDZ3XuPyl057CwlWWiiyG4gVofCwhP44vOXO9ugllZGtO+gBC1F dUCmjXY2trYlU7LDh2FpnOKWZdXq+4k= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=sipsolutions.net header.s=mail header.b=gyXzZN77; spf=pass (imf13.hostedemail.com: domain of johannes@sipsolutions.net designates 168.119.38.16 as permitted sender) smtp.mailfrom=johannes@sipsolutions.net; dmarc=pass (policy=none) header.from=sipsolutions.net DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=5mkwbqFuSv2hlymMhsu3M4LU2jbDB6uW9iOmS/v2SLU=; t=1694511699; x=1695721299; b=gyXzZN77XqJU0Sm1FTcN094IlyRQOZUSW4shMjwMd5iBQdj FqsgbE78ngJMEqdy4RN3/wqUFcFNcmWx5AbRT/eDBRBN4Tl4N5kIgU+o3q+tAr33ElW4YfszZqmX9 Xcs2qmpjn+F6r81mOZpu9S0z8zTVmEONpLgJ/5JWin1pSOxliMqQHrlLxZoP3TZXzcuoAH9naqS3R /DQcJ7wvVA2m0YK+tcuo2KNDDEonBx5HC0DYz8CV9AO04krBSm9ouHweIhsCYPqOziWSoYgG83WGs jDjGfS8pIFjrkLsB/HFYwmj0aQ/kidReMQ1XwiMskSJRDmR+HRE3ZCIxG3iCVkYw==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1qfztl-00CXmL-1Z; Tue, 12 Sep 2023 11:41:33 +0200 Message-ID: Subject: Re: [PATCH v2 1/8] scripts/gdb/symbols: add specific ko module load command From: Johannes Berg To: Kuan-Ying Lee , Jan Kiszka , Kieran Bingham , Matthias Brugger , AngeloGioacchino Del Regno Cc: chinwen.chang@mediatek.com, qun-wei.lin@mediatek.com, linux-mm@kvack.org, linux-modules@vger.kernel.org, casper.li@mediatek.com, akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Date: Tue, 12 Sep 2023 11:41:29 +0200 In-Reply-To: <20230808083020.22254-2-Kuan-Ying.Lee@mediatek.com> References: <20230808083020.22254-1-Kuan-Ying.Lee@mediatek.com> <20230808083020.22254-2-Kuan-Ying.Lee@mediatek.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-malware-bazaar: not-scanned X-Rspamd-Queue-Id: 34D2420004 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 47qxibxmuiguf6m9ief7ynn7xk4jfu5z X-HE-Tag: 1694511698-651719 X-HE-Meta: U2FsdGVkX19eswzzD1na3zYtQcffLpC0jFCs+fiR45rl2SXhvFOo6ELyhvc0RjjRDi/TBO3QTxuWKxAqTrlH0gKoRa6fpoTDqnHaGVi09O3iXZEAN9Sw6ErgTN6rpIH2Rboq+60vXrD//GaTImDHYDHBWDtYAN4yEF4spQaHT8YUH/6WPm04uIcMQ2zCE5/ou3428Ncyy0DlMZnuiSsY1MNtNQBqdp6q5Yl4lR5Tt4vzw2NB1+l0Qbc6+rprGJk16xyx1iKZw+oyP/kSnOCzec2UqUHRbsf5W+zsB6IEFiwnNZuANJwinQINwOnmQQpvLee4jEjIrtIJ4jMMlQBBhc0WhLJdxhR4YoOCwQFRcpduv7mwF2JL+b3NFafHGHsK5T+vrLP0z6KqAW0nQrT8CQ5u//Cc2TpplnB96gffrhgco3x5kt3O9tqHsH7qFHND60+CvvspIoEyKQqmth18N7w/TLlC+S/uUVzNB9dCCVHJbDjIB+z+dylZWx1jYatGSKSc7U4j0+ev0f1dceADvBQD6KNGSwW5sJhfG5nB9mMWhDC8sWTAFn25pAFtSSKeW7TaoNspJU4iRiHw5thgo2r1XiJ6zTdol7T2KFTprQhy1SwFOYAXW4ERTygfK+DS9qzXHvbU3SNk8SEHS93id56364Le49kOpcxLUq4To95xV+0VeiPkUowq12LIj2b1AU2rFHIoABdA3vDFyVnYCNNWkm29IGDmHQK9bMP2bkQCinOl9OTxQdNowBTAYduhaG/ee9yOJpNAe80Rp8saUTdgzK9Zv4o/9WjBeLhHLmAuPnarzFPxW1V8lY43T4LNAfpC0a4RYl0zVJ4x8prQg4p/0EUQgz/CRGWShAIMm1F/LSX8xXWMmQtwqij9v6rJSYPrEAF3lhGxGSxYmH27S6uBPwgtzdRHrdq3IW9i58rGkQ9P268e80QfDZmJJZXcGaVX/nZW2yIXXsBv2/u AUr/RUn2 YLdAnVHdLMjytP8g9gsH01HZ4b88xAkF86KAN/l+vj8ArKmcq1unktx4UBpEkugnq+J9tCIBg5yyJM95PsKZFRFd8kxwXm5fD/Q+WGxw8hpunmSPyASEWVLq1+cbt1NS2L+PFoByoIvqno7njoh+geeyWEWs8fztEcU62qi81a73OuLn3+r0yaJrsS46MM9ij8a2v1NPakR2cdhCb02e59YmRLU2JTB4Wywht9/XZkfkO2Q/7Nm5NSOeOLOtt6Asyifr2pr/b44Klhja3KU6Q8D3Ef67c7/X1Y2zTCoCTtZ+to5s= 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 Tue, 2023-08-08 at 16:30 +0800, Kuan-Ying Lee wrote: > Add lx-symbols command to support add specific > ko module. I'm not sure how this was supposed to work? It should have updated the documentation, but more importantly, it shouldn't have broken the documented usage of this command: The kernel (vmlinux) is taken from the current working directly. Modu= les (.ko) are scanned recursively, starting in the same directory. Optionally, = the module search path can be extended by a space separated list of paths passed= to the lx-symbols command. Note how that talks about a "space separated list of paths" for which clearly a single path seems like it should be accepted? > @@ -138,6 +139,19 @@ lx-symbols command.""" > else: > gdb.write("no module object found for '{0}'\n".format(module= _name)) > =20 > + def load_ko_symbols(self, mod_path): > + self.loaded_modules =3D [] > + module_list =3D modules.module_list() > + > + for module in module_list: > + module_name =3D module['name'].string() > + module_pattern =3D ".*/{0}\.ko(?:.debug)?$".format( > + module_name.replace("_", r"[_\-]")) > + if re.match(module_pattern, mod_path) and os.path.exists(mod= _path): > + self.load_module_symbols(module, mod_path) > + return > + raise gdb.GdbError("%s is not a valid .ko\n" % mod_path) > + > def load_all_symbols(self): > gdb.write("loading vmlinux\n") > =20 > @@ -176,6 +190,11 @@ lx-symbols command.""" > self.module_files =3D [] > self.module_files_updated =3D False > =20 > + argv =3D gdb.string_to_argv(arg) > + if len(argv) =3D=3D 1: > + self.load_ko_symbols(argv[0]) > + return But this obviously breaks it, since passing a single path will go into the if, then complain "some/folder/ is not a valid .ko" and exit. But I'm not even sure how you intended this to work _at all_, because in the context before this if, we have: self.module_paths =3D [os.path.abspath(os.path.expanduser(p)) for p in arg.split()] self.module_paths.append(os.getcwd()) so you first add the (file!) to the list of paths, and then try to load the file by finding modules in the paths, and filtering by the specified file? That seems ... very roundabout, and can even only work if the file can be found via os.getcwd(), so you could never specify an absolute filename? All that seems counter to what the patch was meant to do. I suspect that really you need to individually check "is it a file or a directory" before handling any of this, and if it's actually a file, don't use it as a _filter_ as you do in load_ko_symbols() now but directly use it as is with load_module_symbols()? @Jan, can we revert this? I came up with the following trivial fix that makes it at least not break the original use case of passing a single- entry directory list, but it really doesn't seem right one way or the other. --- a/scripts/gdb/linux/symbols.py +++ b/scripts/gdb/linux/symbols.py @@ -191,7 +191,7 @@ lx-symbols command.""" self.module_files_updated =3D False =20 argv =3D gdb.string_to_argv(arg) - if len(argv) =3D=3D 1: + if len(argv) =3D=3D 1 and os.path.isfile(argv[0]): self.load_ko_symbols(argv[0]) return =20 johannes