Re: [PATCH 1/1] um: fix error return code in winch_tramp()

Hi, this is your Linux kernel regression tracker. Top-posting for once, to make this easily accessible to everyone. Zhen Lei, Richard, what's up here? Below regression report is more than two weeks old now and afaics didn't even get a single reply. Ciao, Thorsten (wearing his 'the Linux kernel's

Re: [PATCH 1/1] um: fix error return code in winch_tramp()

- Ursprüngliche Mail - > Von: "Thorsten Leemhuis" > Hi, this is your Linux kernel regression tracker. Top-posting for once, > to make this easily accessible to everyone. > > Zhen Lei, Richard, what's up here? Below regression report is more than > two weeks old now and afaics didn't even

Re: [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() if no cycle counter

Hi Thomas, On Sun, Apr 10, 2022 at 01:29:32AM +0200, Thomas Gleixner wrote: > But the below uncompiled hack gives you access to the 'best' clocksource > of a machine, i.e. the one which the platform decided to be the one > which is giving the best resolution. The minimal bitwidth of that is > AFAI

Re: [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() if no cycle counter

Jason, On Sun, Apr 10 2022 at 16:25, Jason A. Donenfeld wrote: > On Sun, Apr 10, 2022 at 01:29:32AM +0200, Thomas Gleixner wrote: >> But the below uncompiled hack gives you access to the 'best' clocksource >> of a machine, i.e. the one which the platform decided to be the one >> which is giving th

Re: [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() if no cycle counter

Hi Thomas, On Sun, Apr 10, 2022 at 10:57 PM Thomas Gleixner wrote: > > Not yet having too much knowledge, I'm tentatively leaning toward the > > safe side, of just using ktime_read_raw_clock() in the current places > > that return zero all the time -- that is, for the purpose this patchset > > ha

[PATCH v2 00/11] archs/random: fallback to using ktime_read_raw_clock() if no cycle counter

Hi folks, The RNG uses a function called random_get_entropy() basically anytime that it needs to timestamp an event. For example, an interrupt comes in, and we mix a random_get_entropy() into the entropy pool somehow. Somebody mashes their keyboard or moves their mouse around? We mix a random_get_

[PATCH v2 01/11] timekeeping: add accessor for raw clock

This provides access to whichever time source has the highest frequency, which is useful for gathering entropy on platforms without available cycle counters. It's not necessarily as good as being able to quickly access a cycle counter that the CPU has, but it's still something, even when it falls b

[PATCH v2 02/11] timekeeping: use ktime_read_raw_clock() for random_get_entropy() if no get_cycles()

In the event that a given arch does not define get_cycles(), falling back to the get_cycles() default implementation that returns 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling b

[PATCH v2 03/11] m68k: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 04/11] riscv: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 05/11] mips: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 06/11] arm: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 07/11] nios2: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 08/11] x86: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 09/11] um: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 10/11] sparc: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

[PATCH v2 11/11] xtensa: use ktime_read_raw_clock() for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling ktime_read_raw_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventuall

Re: [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() if no cycle counter

On Fri, Apr 08, 2022 at 08:21:35PM +0200, Jason A. Donenfeld wrote: > By my first guess, we have ktime_get_boottime_ns(), jiffies, and > sched_clock(). It seems like sched_clock() has already done a lot of > work in being always available with some incrementing value, falling > back to jiffies as n

Re: [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() if no cycle counter

Hi Eric, On 4/11/22, Eric Biggers wrote: > On Fri, Apr 08, 2022 at 08:21:35PM +0200, Jason A. Donenfeld wrote: >> By my first guess, we have ktime_get_boottime_ns(), jiffies, and >> sched_clock(). It seems like sched_clock() has already done a lot of >> work in being always available with some in