linux-kernel - Re: [PATCH AUTOSEL 5.14 03/25] cxl: Move cxl

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: <YUDVFW3YjEC8tDVC@sashalap>
Date:   Tue, 14 Sep 2021 13:00:05 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Ben Widawsky <ben.widawsky@...el.com>
Cc:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        kernel test robot <lkp@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        linux-doc@...r.kernel.org, linux-cxl@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.14 03/25] cxl: Move cxl_core to new directory

On Tue, Sep 14, 2021 at 08:05:58AM -0700, Ben Widawsky wrote:
>On 21-09-14 09:57:49, Jonathan Cameron wrote:
>> On Tue, 14 Sep 2021 09:56:23 +0100
>> Jonathan Cameron <Jonathan.Cameron@...wei.com> wrote:
>>
>> > On Mon, 13 Sep 2021 18:33:17 -0400
>> > Sasha Levin <sashal@...nel.org> wrote:
>> >
>> > > From: Ben Widawsky <ben.widawsky@...el.com>
>> > >
>> > > [ Upstream commit 5161a55c069f53d88da49274cbef6e3c74eadea9 ]
>> > >
>> > > CXL core is growing, and it's already arguably unmanageable. To support
>> > > future growth, move core functionality to a new directory and rename the
>> > > file to represent just bus support. Future work will remove non-bus
>> > > functionality.
>> > >
>> > > Note that mem.h is renamed to cxlmem.h to avoid a namespace collision
>> > > with the global ARCH=um mem.h header.
>> >
>> > Not a fix...
>> >
>> > I'm guessing this got picked up on the basis of the Reported-by: tag?
>> > I think that was added for a minor tweak as this went through review rather
>> > than referring to the whole patch.
>> Or possibly because it was a precursor to the fix in the next patch.
>>
>> Hmm.  Ben, Dan, does it make sense for these two to go into stable?
>>
>> Jonathan
>
>As of now, no, but having this will make future fixes much easier to cherry

It was picked because the next patch depends on it. I'll just drop
both if you don't want the next one. Thanks!

-- 
Thanks,
Sasha