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: <20220927004617.xwlicwiwekxp2dna@tarta.nabijaczleweli.xyz>
Date:   Tue, 27 Sep 2022 02:46:17 +0200
From:   наб <nabijaczleweli@...ijaczleweli.xyz>
To:     Mark Brown <broonie@...nel.org>
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:44:10AM +0100, Mark Brown wrote:
> 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.
>
> > (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.

It seems I've overestimated the degree to which this matters
in this case, my b. Put me down as "don't care".

наб

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ