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: <YzI5SmGq9sK4gnFT@sirena.org.uk>
Date:   Tue, 27 Sep 2022 00:44:10 +0100
From:   Mark Brown <broonie@...nel.org>
To:     наб <nabijaczleweli@...ijaczleweli.xyz>
Cc:     Greg KH <greg@...ah.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        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

On Tue, Sep 27, 2022 at 12:46:21AM +0200, наб wrote:

> 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 preserved NBD_REPLY_MAGIC since the conflict was due to it being
updated by the NBD maintainer, I went with their logic instead.  IIRC
they'd also moved it within the file which might make the resolution
harder to read.  LO_MAGIC is gone.

It's not at all clear from what's in the file that your logic about not
including magic numbers defined elsewhere means we shouldn't include
them in the table here, though the commit messages are rather brief so
perhaps there is more to it.  It's certainly a very strong definition of
need as far as I can tell.

> The process here is unclear to me; I assume the "linux-next" here is
>   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
> but the latest update to the default branch appears to be from
> 4 days ago (and pending-fixes at 7h old has this file last modified in
>  2021), so I can't really validate if this merge is as I read it

I'm still in the process of building today's tree, all being well it
will be updated soonish (or I'll give up and hopefully things will go
more smoothly tomorrow).

> (or, indeed, if it does include... the conflict markers?
>  because it does appear to introduce them
>  (or, at least, if I leave in the conflict markers and commit a merge,
>   it sure looks like what's represented below)?),
> so idk.

I skipped out on resolving the conflicts in the translated copies of the
file but messed up on resetting the to the base state.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)