Subject: Re: linux-next: manual merge of the random tree with the jc_docs tree

From: Eric Biggers <[email-masked]>
Date: Thu, 21 Apr 2022 23:32:38 -0700

On Fri, Apr 22, 2022 at 01:59:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the random tree got a conflict in:
> 
>   Documentation/security/siphash.rst
> 
> between commits:
> 
>   dc701cfc5b26 ("Documentation: siphash: convert danger note to warning for HalfSipHash")
>   561fb3cd5ec2 ("Documentation: siphash: enclose HalfSipHash usage example in the literal block")
> 
> from the jc_docs tree and commit:
> 
>   91afe794c070 ("siphash: update the hsiphash documentation")
> 
> from the random tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc Documentation/security/siphash.rst
> index 06d793e68086,79ac8101406c..000000000000
> --- a/Documentation/security/siphash.rst
> +++ b/Documentation/security/siphash.rst
> @@@ -121,15 -121,23 +121,25 @@@ even scarier, uses an easily brute-forc
>   instead of SipHash's 128-bit key. However, this may appeal to some
>   high-performance `jhash` users.
>   
> + HalfSipHash support is provided through the "hsiphash" family of functions.
> + 
>  -**Danger!** Do not ever use the hsiphash functions except for as a hashtable key
>  -function, and only then when you can be absolutely certain that the outputs will
>  -never be transmitted out of the kernel. This is only remotely useful over
>  -`jhash` as a means of mitigating hashtable flooding denial of service attacks.
>  +.. warning::
>  +   Do not ever use HalfSipHash except for as a hashtable key function, and
>  +   only then when you can be absolutely certain that the outputs will never
>  +   be transmitted out of the kernel. This is only remotely useful over
>  +   `jhash` as a means of mitigating hashtable flooding denial of service
>  +   attacks.

That's not exactly the correct resolution, since it dropped the change to the
text of this paragraph that my patch made ("HalfSipHash" => "the hsiphash
functions").

We should get the updates to this file to go through one tree.  Jason, probably
you'd want it to be yours?

- Eric