mpbell ; Sergey Senozhatsky
> > ; Catalin Marinas ;
> > Will Deacon ; Steven Rostedt ;
> > Chris Fries ; Dave Weinstein ; Daniel
> > Micay ; Djalal Harouni
> > Subject: Re: [PATCH 0/3] add %pX specifier
> >
> > On Tue, Oct 10, 2017 at 4:09 PM, Tobin C. Harding w
ook
> ; Paolo Bonzini ; Tycho
> Andersen ; Roberts, William C
> ; Tejun Heo ; Jordan Glover
> ; Greg KH ;
> Petr Mladek ; Joe Perches ; Ian
> Campbell ; Sergey Senozhatsky
> ; Catalin Marinas ;
> Will Deacon ; Steven Rostedt ;
> Chris Fries ; Dave Weinstein ; Daniel
> Mic
On Wed, Oct 11, 2017 at 3:11 PM, Jason A. Donenfeld wrote:
>
> On another topic: the approach we're discussing here is using a PRF
> (pseudo-random function), also known as a keyed hash function. It's
> not reversible; it isn't encryption. Mapping 64-bit inputs to 64-bit
> outputs means there _mig
On Wed, Oct 11, 2017 at 11:29 PM, Linus Torvalds
wrote:
> Yeah, siphash is probably the sanest thing to use.
>
> How bad would it be to use HalfSipHash on 32-bit architectures?
>
> On a 32-bit machine, the full siphash is pretty expensive - big
> constants, and lots of 64-bit shifts. And 32-bit ma
On Wed, Oct 11, 2017 at 1:11 PM, Jason A. Donenfeld wrote:
>
> Indeed the correct functions to use would be siphash_1u32 or
> siphash_1u64, depending. Depending on the popularity of that, we might
> even consider making a siphash_1ulong helper, I suppose.
Yeah, siphash is probably the sanest thin
Hi Linus,
On Wed, Oct 11, 2017 at 1:15 AM, Linus Torvalds
wrote:
> (NOTE! Using jhash here is not acceptable, since it's not
> cryptographically safe, but think of it as an example of a hash that
> takes 32-bit input).
Ahh, yes, I should have continued to read the thread before replying
my first
Hi Tobin,
On Wed, Oct 11, 2017 at 1:09 AM, Tobin C. Harding wrote:
>
> +hashval = hash_three_words(
> +(unsigned long)ptr,
> +(unsigned long)ptr >> 16 >> 16,
> +boot_time_random_int);
This is most likely not what you want to be usin
On Wed, 2017-10-11 at 10:32 +1100, Tobin C. Harding wrote:
> On Tue, Oct 10, 2017 at 04:15:01PM -0700, Linus Torvalds wrote:
> > On Tue, Oct 10, 2017 at 4:09 PM, Tobin C. Harding wrote:
> > >
> > > I did not understand the code (specifically why the right shift of 16
> > > twice?)
> >
> > It's
On Tue, Oct 10, 2017 at 04:15:01PM -0700, Linus Torvalds wrote:
> On Tue, Oct 10, 2017 at 4:09 PM, Tobin C. Harding wrote:
> >
> > I did not understand the code (specifically why the right shift of 16
> > twice?)
>
> It's a traditional trick to get the upper 32 bits.
>
> So it basically splits
On Tue, Oct 10, 2017 at 04:16:55PM -0700, Linus Torvalds wrote:
> On Tue, Oct 10, 2017 at 4:09 PM, Tobin C. Harding wrote:
> >
> > This patch is a softer version of Linus' suggestion because it does not
> > change the behaviour of the
> > %p specifier. I don't see the benefit in making such a bre
On Tue, Oct 10, 2017 at 4:09 PM, Tobin C. Harding wrote:
>
> This patch is a softer version of Linus' suggestion because it does not
> change the behaviour of the
> %p specifier. I don't see the benefit in making such a breaking change
> without addressing the issue
> of %x (and I don't the ball
On Tue, Oct 10, 2017 at 4:09 PM, Tobin C. Harding wrote:
>
> I did not understand the code (specifically why the right shift of 16 twice?)
It's a traditional trick to get the upper 32 bits.
So it basically splits the (possibly 64-bit) pointer into the lower 32
bits and the upper 32 bits for a ha
This series is a result of the recent thread on LKML regarding kpt_restrict
https://lkml.org/lkml/2017/9/30/224
It seems we have not reached total consensus. This patch set does not claim to
solve the whole issue
but rather take a small step forward without taking any steps backwards.
It may be
13 matches
Mail list logo
