linux-kernel - Re: linux-next: manual merge of the driver-core tree with the jc

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: <878rm5rbka.fsf@meer.lwn.net>
Date:   Mon, 26 Sep 2022 16:54:45 -0600
From:   Jonathan Corbet <corbet@....net>
To:     наб <nabijaczleweli@...ijaczleweli.xyz>,
        broonie@...nel.org
Cc:     Greg KH <greg@...ah.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Manfred Spraul <manfred.spraul@...bosch.com>
Subject: Re: linux-next: manual merge of the driver-core tree with the
 jc_docs tree

наб <nabijaczleweli@...ijaczleweli.xyz> writes:

> Hi!
>
> On Mon, Sep 26, 2022 at 10:06:31PM +0100, broonie@...nel.org wrote:
>> Today's linux-next merge of the driver-core tree got a conflict in:
>> 
>>   Documentation/process/magic-number.rst
>> 
>> between commit:
>> 
>>   32ba63d4b2e1a ("Doc update: Correct magic values from nbd protocol, V2")
>> 
>> from the jc_docs tree and commits:
>> 
>>   82805818898dd ("Documentation: NBD_REPLY_MAGIC isn't a magic number")
>>   bd5926220ffe0 ("nbd: remove define-only NBD_MAGIC, previously magic number")
>> 
>> from the driver-core tree (and probably more for context).
>
> If I'm reading the merge right (very much not a given!),
> it seems that the NBD_REPLY_MAGIC (and LO_MAGIC?) constant(s) survived:
> they both need to go for reasons listed in
>   bd5926220ffe0: LO_MAGIC doesn't exist
>   82805818898dd: NBD_REPLY_MAGIC is part of the line protocol,
>                  not a magic number 
>
> This also reveals that I missed NBD_REQUEST_MAGIC
> (needs to go, same reason as NBD_REPLY_MAGIC)
> in the first pass, but that's unrelated here.

I've been trying to make sense of that merge myself.  Is the right
solution that I should just drop 32ba63d4b2e1a ?  Manfred, thoughts on
that?

Thanks,

jon