Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2434191ioo; Sat, 28 May 2022 13:33:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxelaRYN42464grYzbSgt6RxVpcWWx6se43Vj4MlJ4M99j6QXdgdk3WzOkPVTWvq0xpaKoD X-Received: by 2002:a65:6d16:0:b0:3c1:b056:5f5a with SMTP id bf22-20020a656d16000000b003c1b0565f5amr41674398pgb.469.1653769999634; Sat, 28 May 2022 13:33:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653769999; cv=none; d=google.com; s=arc-20160816; b=CFLf2V0l8n/7rIbBIKrDmw1ehQ0Y7z5XId/j11bTdQ+HzzyoNUJkxdwMfrZMyhmc/j dK6CWnbI66reXMEFy76A6AtedM/7abW8zskwSSmYPWxWsLDk+EBws/xdof9vriqLC/Bx 8DYIs/Xu6/1XwvRmFAVOQlhBork9fWDeErn97wD7ZGasxFeHAD9NWSEU9HDJQlnQDA8G S1THjUwoybWOu6WWFJNgioRS83S5wX/6zKsJ3vgShkP+WbXM6Zxt7/sRnJmDeBj/Yzt7 37gyRAxUXdJBe55O2kjQrckP7bP0Ka+pzjwK5yRkt49nXFIFs9qOUXgr6+93ElLt4G/U Ku1Q== 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:dkim-signature; bh=pkeamn6614ybCu0wUTjrqrbAO7+NOojS1UgGX7Dy42U=; b=IXTVZq60RqHAdWNKlCJn1wjL/D/A8WrYjs/vab6BrBr8A9FqvCDPT5BGPkN3uKue1o pDxqQLwmCDpwb/Iz3cqYSJpX17r1ZEaqP8GpYV/hOyh/RU9PqsdwDiR2+MdmQZCuttxX /s4XJl88uH+SbCXGOu3mxzvJIRXm/zUNmV+A9HHH3dbBB/ieLfO3yLEYCosCx1n48EEl c+U11xMupjnuPz/XEa7RW5GWGuwp3eZq2iXGqSTQFV03McvC8sIriRhHhS9/5/lvl/fy KAcE2bKi6K00rWlV8IqTvCoepYjsu2mAaGPUcPCar8JHl2GK/HgHoflvpctuKdKviB/T Q+pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=AUdwYQFn; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q14-20020a056a00084e00b004fa687c28d4si11632824pfk.86.2022.05.28.13.33.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 13:33:19 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=AUdwYQFn; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 680251A0768; Sat, 28 May 2022 12:36:22 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354111AbiE0Q1u (ORCPT + 99 others); Fri, 27 May 2022 12:27:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232903AbiE0Q1q (ORCPT ); Fri, 27 May 2022 12:27:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D046B340F1; Fri, 27 May 2022 09:27:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8920AB824C9; Fri, 27 May 2022 16:27:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1C57C385A9; Fri, 27 May 2022 16:27:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653668863; bh=PRaPi35zkOUa2ee/LGAevmhlOaftEQU94uTYvSbtIYs=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=AUdwYQFnQL+oIJZpQBq82jSSk/heA2LObEFqnWPTzgh2mrOIXni7GDPG92ZByPDAk CXin4Wfey4ZAbnSrcb4b9JF9zdlkzUnIJyGTlytzZNg9j35uWmSLNL0n6xTt1iHWX6 GN5QE2cHwLcpHdl8DWmcaC6mP3HldR9n21UzSajhcjyB7DZ8b7ZNP81SzbRcaPyaK1 otrfDC0N16l12UKtoxCh5N87Wq41JO+dF94S0HDlIXuHW93p74TPJNaWaYVXufzCts UNreNLMeRwR0EM7IHX0B9C9lArH3Anry9wqsz4BPdA9v+MFBr9rL8X0o5TOhCO2ktv bWLDU2W0wVVPA== Message-ID: <459385ee7ccf4fcf3e22d4a11b4f438d648422bf.camel@kernel.org> Subject: Re: [PATCH v7 03/25] kallsyms: increase maximum kernel symbol length to 512 From: Jarkko Sakkinen To: Miguel Ojeda , David Howells Cc: Miguel Ojeda , Linus Torvalds , Greg Kroah-Hartman , rust-for-linux , linux-kernel , Kees Cook , Petr Mladek , Alex Gaynor , Wedson Almeida Filho , Gary Guo , Boqun Feng , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Joe Lawrence , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , live-patching@vger.kernel.org, linux-perf-users@vger.kernel.org Date: Fri, 27 May 2022 19:25:57 +0300 In-Reply-To: References: <20220523020209.11810-1-ojeda@kernel.org> <20220523020209.11810-4-ojeda@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1 MIME-Version: 1.0 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 On Tue, 2022-05-24 at 20:07 +0200, Miguel Ojeda wrote: > On Mon, May 23, 2022 at 10:33 PM Jarkko Sakkinen wrot= e: > >=20 > > There's no description what the patch does. >=20 > I am not sure what you mean. Both the subject and the last paragraph > describe what the patch does, while the rest gives the rationale > behind it. >=20 > Cheers, > Miguel The honest answer: I don't actually remember what I was thinking=C2=A0 (other stuff stole my focus) but my comment neither makes much sense to me. Please just ignore it, and apologies for causing confusion. There's something I'm looking into in my spare time right now. I'm experimenting with interfacing keyring types to Rust. The first step, I guess, is to provide a Rust abstraction for assoc_array. I've skimmed through the patch set and have now *rough* idea of patterns and techniques. My opens are more on the process side of things since there's no yet mainline subtree. If I send a patch or patch sets, would this be a good workflow: 1. RFC tag. 2. In the cover letter denote the patch set version, which was used the baseline. Linux keyring is without argument a kind of subsystem that would hugely benefit of the Rust work, as it is both user space facing=C2=A0 nd handling a vast amount of user's confidential data.=20 BR, Jarkko