linux-kernel - Re: [PATCH modules-next v10 00/13] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87edqhsy1f.fsf@esperi.org.uk>
Date:   Wed, 22 Feb 2023 12:08:12 +0000
From:   Nick Alcock <nick.alcock@...cle.com>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     linux-modules@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
        linux-kernel@...r.kernel.org, elena.zannoni@...cle.com
Subject: Re: [PATCH modules-next v10 00/13] kallsyms: reliable
 symbol->address lookup with /proc/kallmodsyms

On 21 Feb 2023, Luis Chamberlain stated:

> On Thu, Feb 09, 2023 at 11:53:29PM +0000, Nick Alcock wrote:
>> [most people trimmed from the Cc: list for this procedural question]
>> 
>> On 9 Feb 2023, Nick Alcock outgrape:
>> > I am going to split this whole series into:
>> >
>> > 1. A series of patches (123 of them at present) Cc:ed to subsystem
>> > maintainers as well as you, to comment out the MODULE_LICENSE usage.
>> > These patches will have Suggested-by you. This series is rebased against
>> > the latest modules-next and revalidated, and is ready to be mailed out;
>> > will do so shortly.
>> 
>> One quick question: if/when you're happy with this series, are you
>> planning to take it yourself via modules-next?
>
> It seems some maintainers are already taking patches in, so let's see
> what folks take in, then if there are not takers I can just take what is
> not merged on linux-next through modules-next.
> 
> So try to get them into each subsystem tree, and around rc3 send the
> ones that are not merged and I'll just take them into modules-next.

Sounds good! I can trivially regenerate a new patch series containing
only the still-missing bits without needing to do anything like track
who took things, because nearly all of this is automated anyway.

... at least I can if I can figure out where all the subsystem trees
that people took them into are (not everyone might mention when they
take one). I might miss a few, but I suspect that's not a problem:
taking the same commit by two different routes does not constitute a
conflict, at least on its own.