Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Nick Alcock <nick.alcock@oracle.com>
To:     Jiri Olsa <olsajiri@gmail.com>
Cc:     mcgrof@kernel.org, masahiroy@kernel.org, jolsa@kernel.org,
        rostedt@goodmis.org, bas@baslab.org, tglozar@gmail.com,
        Ast-x64@protonmail.com, viktor.malik@gmail.com, dxu@dxuuu.xyz,
        acme@kernel.org, adrian.hunter@intel.com, ak@linux.intel.com,
        irogers@google.com, linux-kbuild@vger.kernel.org,
        linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
        arnd@arndb.de, akpm@linux-foundation.org, eugene.loh@oracle.com,
        kris.van.hees@oracle.com
Subject: Re: [PATCH v8] kallsyms: new /proc/kallmodsyms with builtin modules
References: <20220208184309.148192-1-nick.alcock@oracle.com>
        <YgblCSWH3g0+uy48@krava>
Emacs:  because idle RAM is the Devil's playground.
Date:   Mon, 14 Feb 2022 15:40:39 +0000
In-Reply-To: <YgblCSWH3g0+uy48@krava> (Jiri Olsa's message of "Fri, 11 Feb
        2022 23:36:57 +0100")
Message-ID: <87leydpibs.fsf@esperi.org.uk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2.50 (gnu/linux)
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?eO7ieGH5hmg5tkCohhJjXTaBeefQOSPebK2X9nHOXZ29KPNBbcsN2LTngxkK?=
 =?us-ascii?Q?L679S9IUIE7YCjr73rQ5B4MbBkH6ziR6YUPI/0Bfdsw3wonR2OCzk4zfrhT5?=
 =?us-ascii?Q?OsqC0rKXjeEMrusGx5s8VzjZKy8RwslFuPFeNWREPNSz7BdwuUok82wntRPG?=
 =?us-ascii?Q?swwg+MyWUBFs8TkpQo73ZCcHMnf9aSs1TsQqhPRuiJmTqjLABhfgOsRm8EJm?=
 =?us-ascii?Q?T9G/bqj0iaESy+NP71+MYjrRB0Bw9gGU/A3bcGH4B0hL9/SKnaN6HgFsWgo8?=
 =?us-ascii?Q?AXTYWBQKydlLuF6wLyyewiWX8Eug2KysaCelp+tLPVz78rqswKPJKlw5SkIN?=
 =?us-ascii?Q?17iXQKclITzV9703Awk+iNnk1aVU7szDUFHcu39ansI3UG4eg/3Xise5aPe2?=
 =?us-ascii?Q?XZzEILn4rJwN0O1Coi50l+h36nkQX7BtUufDffQXgj54MKccmRA17Qs+QPYt?=
 =?us-ascii?Q?izSSb1TYYTR3n1HZLr8sMyrkzSrkx5p51zTvrkfN/Fm85tDs8uQ4NUIdOP1/?=
 =?us-ascii?Q?8FNBEwZ5nY+gKDdONudzr8q3/mY3nxHbxB/sZvOgJYvt7Od9sAlBFw7kSFhG?=
 =?us-ascii?Q?yVWaVl6+hVmzpH2EPllosJlH83sIvCRye/C0Gm4yg09ZG8y73bgWAk9InHXW?=
 =?us-ascii?Q?kClmqfRWQG341dCWY5veFo53EOTqv+Fir5sX4EPomY8blL1VIxXqREOOcCBd?=
 =?us-ascii?Q?OwZUHS4NJGxPh+WeXkUCN7/AqEft20NYGGGlhkOXQK+yM9TcY/myKZnU4AG9?=
 =?us-ascii?Q?94Yqz92WeSXq3q8XXa35m3nkRnYy/nvX/+nzi2UdshzFd++NvWE3hDdxcRA5?=
 =?us-ascii?Q?YzpnQKU0li4sJexUKTVJt1pjUSrZMSX5LL7gxLFDjm9nADbRdJmpDDa1J4BS?=
 =?us-ascii?Q?2GabPNfmWA21DpNVk3VCd0p9RF8ko1KcDou0vtBJsoT3K24mQkYVYSrR8Y4G?=
 =?us-ascii?Q?tqcMwd3W5TgTkans8J3uq/UZZSJMtZDD4+wKL6QFzsIn3TpiyhovNjQWbIsu?=
 =?us-ascii?Q?38bhAnc6j7eyhE0l3cuHd/69+AAtZW7ijBtbfXgCqkLvqPIJ3RKQjdymJwdd?=
 =?us-ascii?Q?V3QeFePrbbc2xRXqWrB/ly4841sBtDBZZv7JloERIPfsgYb4iZAy7aNIr0/F?=
 =?us-ascii?Q?6znn0WyWT3lzDxQ9OCSDV6ZkoI5GUowK7D7Aiz5E35xRv5/ISbbIfVtwy1MC?=
 =?us-ascii?Q?3jVpc1wCFxtLZmdRazNjBTKv/oNA/bAaiF9apPR6l/OPw67JDuOtiEfSKry0?=
 =?us-ascii?Q?Ny4j+VOIdJ76mnB9lw2bfOEvy9MaWs607Oa5pF2XZDXNQyDdyBpAkdT0GkO1?=
 =?us-ascii?Q?37RrqqUF9YKz938/zTAcvx5UO01YxqwcZI4fjb1XDpqDY0yojePwaN5eUfEi?=
 =?us-ascii?Q?pW7oRwtj5qJlC2yzu2mQrAMM/zkfVDBCAbmAnZFWi81AN9ztTBwMCYtzJRy0?=
 =?us-ascii?Q?/Uq6nocv98LMeVV0Vl/rXJLak+uPjCnMvmXj7QA7rDJyTjByIz+mGxRODxge?=
 =?us-ascii?Q?y6My/oX5DRPuynTVANKf8eHld+UVDkABIt2pyM0g0fuDTwISOnSFff/j1ChH?=
 =?us-ascii?Q?0HksJFQu08u/TiDpBTz5YLGlz1U021ORsS0iYYfn5lC7B77GISYMay5Ut2nB?=
 =?us-ascii?Q?lQo3+9vYwFMpBBxbH6CYx2uLbjXfeqye47//ocBmplhJ?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f270c44-1dd2-4dc8-03e7-08d9efd05f3c
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4715.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2022 15:40:48.4964
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: H8QPNb1wdxgGreaOYezl1ZtYJYSyNx+L6NWb3fFaiVA9d0GXa/FkX4WG3+WiyPJzvAbznYI4STDD7LcsrFGN+w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2943
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10258 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 mlxlogscore=660 bulkscore=0 spamscore=0 adultscore=0 mlxscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2201110000 definitions=main-2202140095
X-Proofpoint-ORIG-GUID: l0q1KNcQYqlLVt1prUBQsWR9E1GUGbib
X-Proofpoint-GUID: l0q1KNcQYqlLVt1prUBQsWR9E1GUGbib
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11 Feb 2022, Jiri Olsa verbalised:
> On Tue, Feb 08, 2022 at 06:43:03PM +0000, Nick Alcock wrote:
>> This is all controlled by a new config parameter CONFIG_KALLMODSYMS, which when
>> set results in output in /proc/kallmodsyms that looks like this:
>> 
>> ffffffff8b013d20 409 t pt_buffer_setup_aux
>> ffffffff8b014130 11f T intel_pt_interrupt
>> ffffffff8b014250 2d T cpu_emergency_stop_pt
>> ffffffff8b014280 13a t rapl_pmu_event_init      [intel_rapl_perf]
>> ffffffff8b0143c0 bb t rapl_event_update [intel_rapl_perf]
>> ffffffff8b014480 10 t rapl_pmu_event_read       [intel_rapl_perf]
>> ffffffff8b014490 a3 t rapl_cpu_offline  [intel_rapl_perf]
>> ffffffff8b014540 24 t __rapl_event_show [intel_rapl_perf]
>> ffffffff8b014570 f2 t rapl_pmu_event_stop       [intel_rapl_perf]
>
> hi,
> I tried this version and can't see the symbols size
>
> [root@qemu jolsa]# cat /proc/kallmodsyms | grep ksys_ | head -5
> ffffffff81094720 T ksys_ioperm
> ffffffff81141110 T ksys_unshare
> ffffffff81160410 T ksys_setsid
> ffffffff811c64b0 T ksys_sync_helper
> ffffffff813213c0 T ksys_fadvise64_64

UGH, sorry, I should have regenerated the output in the cover letter!
The cover letter is buggy :)

This is entirely expected because I dropped the symbol size patch
(because it's formally unnecessary because you can do it from userspace
by examination of vmlinux or the .ko files, and the symbol size
representation is big, adding hundreds of KiB to the kernel image).
And then I failed to regenerate the output to show this :/

In this series, /proc/kallmodsyms now looks identical in format to
/proc/kallsyms, except that you can have [multiple] [modules] on a line
and the meaning of a [module] entry is different. (This may be a small
enough change in semantics that merging the two is possible, but I doubt
it -- existing users will surely expect that a [module] entry means that
module.ko exists, which with /proc/kallmodsyms is not always true.)

-- 
NULL && (void)