On Mon, Jan 11, 2021 at 10:15:44AM +0100, Marco Elver wrote:
> Show the access type in KFENCE reports by plumbing through read/write
> information from the page fault handler. Update the documentation and
> test accordingly.
>
> Suggested-by: Jörn Engel
> Signed-off-by: Marco E
E allocation should be
> set up.
>
> Suggested-by: Jörn Engel
> Signed-off-by: Marco Elver
Reviewed-by: Jörn Engel
Jörn
--
One of the things I’ve discovered over the years, is that you can
create change or you can receive credit – not both.
-- Stephen Downes
On Sat, Oct 19, 2019 at 12:49:52PM +0200, Thomas Gleixner wrote:
>
> One slightly related thing I was looking into is that the mixing of
> interrupt entropy is always done from hard interrupt context. That has a
> few issues:
>
> 1) It's pretty visible in profiles for high frequency interrupt
On Fri, Oct 18, 2019 at 01:37:04PM -0700, Jörn Engel wrote:
> Sorry for coming late to the discussion. I generally like the approach
> in try_to_generate_entropy(), but I think we can do a little better
> still. Would something like this work?
Fixed lkml address
I agree that the code is garbage. In my defense, creating generic
iterator-type functions for multiple data types appears to be one of the
hardest problems in CS with many bad examples of what not to do.
Patch below should fix it. We have tcm_qla2xxx systems, so I will stick
it into our test sys
On Sat, Nov 11, 2017 at 01:22:38PM -0500, Theodore Ts'o wrote:
> On Fri, Nov 10, 2017 at 04:23:21PM -0800, Jörn Engel wrote:
> > On Fri, Nov 10, 2017 at 06:52:12PM -0500, Theodore Ts'o wrote:
> > > Couple of quick comments. The code as it exists is horrifically x86
Forgot to Cc: linux-kernel.
On Fri, Nov 10, 2017 at 01:30:39PM -0800, Jörn Engel wrote:
> Regrand is a replacement for drivers/char/random.c. It is supposed to
> achieve the following design goals:
>
> 1. /dev/random shall never block.
> 2. /dev/urandom shall never return bad
On Fri, Jun 30, 2017 at 09:34:24AM +0200, Helge Deller wrote:
>
> I see there are some architectures which define TASK_SIZE not as
> multiple of PAGE_SIZE and as 0x for which the (address >=
> TASK_SIZE) check will not trigger:
>
> arch/arm/include/asm/memory.h:#define TASK_SIZE U
On Fri, Jun 30, 2017 at 08:57:27AM +0200, Helge Deller wrote:
> On 30.06.2017 01:02, Jörn Engel wrote:
> > I believe the overflow check was correct, then got subtly broken by
> > commit bd726c90b6b8
> > Author: Helge Deller
> > Date: Mon
I believe the overflow check was correct, then got subtly broken by
commit bd726c90b6b8
Author: Helge Deller
Date: Mon Jun 19 17:34:05 2017 +0200
Allow stack to grow up to address space limit
The old overflow check may have been a bit subtle and I suppose He
This has been reported (and ignored) before:
http://lkml.iu.edu/hypermail/linux/kernel/1407.2/03790.html
https://bugzilla.kernel.org/show_bug.cgi?id=89161
Regression was introduced by:
commit 00503b6f702e (refs/bisect/bad)
Author: dingtianhong
Date: Sat Jan 25 13:00:29 2014 +0800
bonding:
On Thu, Aug 27, 2015 at 08:48:18AM +0200, Michal Hocko wrote:
>
> > On x86, HUGE_MAX_HSTATE == 2. I don't consider that to be expensive.
> >
> > If you are concerned about the memory allocation of struct hugetlb_usage,
> > it could easily be embedded directly in struct mm_struct.
>
> Yes I am
On Fri, Aug 21, 2015 at 08:32:33AM +0200, Michal Hocko wrote:
>
> Both mmotm and linus tree have
> REG("smaps", S_IRUGO, proc_pid_smaps_operations),
>
> and opening the file requires PTRACE_MODE_READ. So I do not see any
> requirement for root here. Or did you mean that you need root
On Fri, Aug 21, 2015 at 08:53:21AM +0200, Michal Hocko wrote:
> On Thu 20-08-15 23:34:51, Naoya Horiguchi wrote:
> [...]
> > > Reading a single file is, of course, easier but is it really worth the
> > > additional code? I haven't really looked at the patch so I might be
> > > missing something but
On Wed, Aug 12, 2015 at 01:25:59PM -0700, David Rientjes wrote:
> On Wed, 12 Aug 2015, Naoya Horiguchi wrote:
>
> > Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
> > is inconvenient when we want to know per-task or per-vma base hugetlb usage.
> > To solve this, this p
On Thu, Aug 13, 2015 at 12:45:33AM +, Naoya Horiguchi wrote:
> From: Naoya Horiguchi
> Subject: [PATCH] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status
>
> Currently there's no easy way to get per-process usage of hugetlb pages, which
> is inconvenient because userspace applicat
On Wed, Aug 12, 2015 at 01:30:27PM -0700, David Rientjes wrote:
>
> I'd be interested in the comments of others, though, to see if there is
> any reservation about the hstate size breakdown. It may actually find no
> current customer who is interested in parsing it. (If we keep it, I would
>
rea_struct *vma = v;
> struct mem_size_stats mss;
> struct mm_walk smaps_walk = {
> .pmd_entry = smaps_pte_range,
> +#ifdef CONFIG_HUGETLB_PAGE
> + .hugetlb_entry = smaps_hugetlb_range,
> +#endif
Not too fond of the #ifdef. But I won't bl
On Wed, Jul 29, 2015 at 04:20:59PM -0700, Mike Kravetz wrote:
> >
> >Since the hugetlb pool is a global resource, it would also be helpful to
> >determine if a process is mapping more than expected. You can't do that
> >just by adding a huge rss metric, however: if you have 2MB and 1GB
> >hugepage
On Thu, Jul 30, 2015 at 05:22:55PM +0200, Mike Galbraith wrote:
>
> I piddled about with the thought that it might be nice to be able to
> sprinkle cond_resched() about to cut rt latencies without wrecking
> normal load throughput, cobbled together a cond_resched_rt().
>
> On my little box that w
On Tue, Jul 28, 2015 at 04:30:19PM -0700, David Rientjes wrote:
>
> It's not only the oom killer, I don't believe hugeltb pages are accounted
> to the "rss" in memcg. They use the hugetlb_cgroup for that. Starting to
> account for them in existing memcg deployments would cause them to hit
> t
On Tue, Jul 28, 2015 at 03:15:17PM -0700, David Rientjes wrote:
>
> Starting to account hugetlb pages in rss may lead to breakage in userspace
> and I would agree with your earlier suggestion that just removing any test
> for rss would be appropriate.
What would you propose for me then? I have
On Mon, Jul 27, 2015 at 04:26:47PM -0700, Mike Kravetz wrote:
> I started looking at the hugetlb self tests. The test hugetlbfstest
> expects hugetlb pages to be accounted for in rss. However, there is
> no code in the kernel to do this accounting.
>
> It looks like there was an effort to add th
On Tue, Jul 28, 2015 at 03:32:55PM +0200, Michal Hocko wrote:
> >
> > We have kernel preemption disabled. A lower-priority task in a system
> > call will block higher-priority tasks.
>
> This is an inherent problem of !PREEMPT, though. There are many
> loops which can take quite some time but we
On Mon, Jul 27, 2015 at 09:08:42AM +0200, Michal Hocko wrote:
> On Fri 24-07-15 09:56:27, Jörn Engel wrote:
> > On Fri, Jul 24, 2015 at 09:04:21AM +0200, Michal Hocko wrote:
> > > On Thu 23-07-15 14:54:33, Spencer Baugh wrote:
> > > > From: Joern Engel
> > >
On Fri, Jul 24, 2015 at 12:49:14PM -0700, David Rientjes wrote:
>
> I don't see the cond_resched() you propose to add, but the need for it is
> obvious with a large user-written nr_hugepages in the above loop.
>
> The suggestion is to check the conditional, reschedule if needed (and if
> so, re
On Fri, Jul 24, 2015 at 08:59:59AM +0200, Michal Hocko wrote:
> On Thu 23-07-15 14:54:31, Spencer Baugh wrote:
> > From: Joern Engel
> >
> > ~150ms scheduler latency for both observed in the wild.
>
> This is way to vague. Could you describe your problem somehow more,
> please?
> There are schdu
On Thu, Jul 23, 2015 at 05:32:03PM -0600, Toshi Kani wrote:
> On Thu, 2015-07-23 at 14:54 -0700, Spencer Baugh wrote:
> > From: Joern Engel
> >
> > Mapping large memory spaces can be slow and prevent high-priority
> > realtime threads from preempting lower-priority threads for a long time.
>
> Y
On Fri, Jul 24, 2015 at 09:04:21AM +0200, Michal Hocko wrote:
> On Thu 23-07-15 14:54:33, Spencer Baugh wrote:
> > From: Joern Engel
> >
> > Mapping large memory spaces can be slow and prevent high-priority
> > realtime threads from preempting lower-priority threads for a long time.
>
> How can
On Thu, Jul 23, 2015 at 03:54:43PM -0700, David Rientjes wrote:
> On Thu, 23 Jul 2015, Jörn Engel wrote:
>
> > > This is wrong, you'd want to do any cond_resched() before the page
> > > allocation to avoid racing with an update to h->nr_huge_pages or
&
On Thu, Jul 23, 2015 at 03:08:58PM -0700, David Rientjes wrote:
> On Thu, 23 Jul 2015, Spencer Baugh wrote:
> > From: Joern Engel
> >
> > ~150ms scheduler latency for both observed in the wild.
> >
> > Signed-off-by: Joern Engel
> > Signed-off-by: Spencer Baugh
> > ---
> > mm/hugetlb.c | 2 ++
On Thu, Jul 23, 2015 at 11:02:55AM -0700, Jörn Engel wrote:
> Spencer spotted something nasty in the round_up macro. We were
> wondering why round_up() worked differently from ALIGN. The only real
> difference between the two patterns is overflow behaviour. And both
> version ar
Spencer spotted something nasty in the round_up macro. We were
wondering why round_up() worked differently from ALIGN. The only real
difference between the two patterns is overflow behaviour. And both
version are buggy when used for signed integer types, round_up will
underflow on INT_MIN, ALIGN
On Wed, Jul 22, 2015 at 03:54:36PM -0700, Andrew Morton wrote:
> On Tue, 21 Jul 2015 15:07:57 -0700 Spencer Baugh wrote:
>
> > From: Joern Engel
> >
> > We have observed cases where the soft lockup detector triggered, but no
> > kernel bug existed. Instead we had a buggy realtime thread that
>
On Wed, Jul 22, 2015 at 09:35:28AM +0200, Mike Galbraith wrote:
> On Tue, 2015-07-21 at 23:33 -0700, Jörn Engel wrote:
>
> > One could argue that killing the realtime thread is even better than
> > panic, as things can restart with a blank slate even faster. But the
> >
On Wed, Jul 22, 2015 at 07:41:48AM +0200, Mike Galbraith wrote:
> On Tue, 2015-07-21 at 22:18 -0700, Jörn Engel wrote:
> >
> > Not sure if this patch is something for mainline, but those two
> > alternatives have problems of their own. Not panicking on lockups can
> &
On Wed, Jul 22, 2015 at 06:36:30AM +0200, Mike Galbraith wrote:
> On Tue, 2015-07-21 at 15:07 -0700, Spencer Baugh wrote:
>
> > We have observed cases where the soft lockup detector triggered, but no
> > kernel bug existed. Instead we had a buggy realtime thread that
> > monopolized a cpu. So le
add_interrupt_randomness() can cause significant cpu overhead on
interrupt-heavy workloads. We try to limit that overhead by bailing out
quickly once we have sampled a few bits of entropy this second. If
there is enough entropy around it doesn't hurt to waste the excess.
However, we also waste e
On Tue, Feb 24, 2015 at 10:33:44AM -0500, Steven Rostedt wrote:
> On Tue, 24 Feb 2015 09:55:09 -0500
> Jörn Engel wrote:
>
> > I came across a silly problem that tempted me to revert 43fa5460fe60.
> > We had a high-priority realtime thread woken, TIF_NEED_RESCHED was se
Looks like Gregory Haskins' email bounces. Should have figured as much.
Jörn
--
The only real mistake is the one from which we learn nothing.
-- John Powell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More major
Hello Steven!
I came across a silly problem that tempted me to revert 43fa5460fe60.
We had a high-priority realtime thread woken, TIF_NEED_RESCHED was set
for the running thread and the realtime thread didn't run for >2s.
Problem was a system call that mapped a ton of device memory and never
hit a
On Wed, 4 June 2014 19:15:06 -0400, Jörn Engel wrote:
> On Mon, 28 April 2014 17:22:19 -0700, Andrew Morton wrote:
> > On Mon, 28 Apr 2014 19:40:39 -0400 J__rn Engel wrote:
> > > On Thu, 24 April 2014 15:40:24 -0400, J__rn Engel wrote:
> > > > On Wed, 23 April 20
On Mon, 8 September 2014 16:04:40 -0400, Rodrigo Freire wrote:
>
> From: Felix Fietkau
>
> block2mtd: Ensure that block2mtd is presented in a timely fashion
>
> Currently, a block MTD device is not presented to the system on time, in
> order to start mounting the filesystems. This patch ensur
On Fri, 8 August 2014 08:28:47 -0600, Jens Axboe wrote:
> On 08/08/2014 08:24 AM, Jens Axboe wrote:
> > On 08/07/2014 06:54 PM, Jörn Engel wrote:
> >>
> >> If __get_request() returns NULL, get_request will call
> >> prepare_to_wait_exclusive() followed by io_
Hello Jens!
I came across the below while investigating some other problem.
Something here doesn't seem right. This looks like an obvious bug and
something roughly along the lines of my patch would fix it. But I
must be in the wrong decade to find such a bug in the block layer.
Is this for real
On Mon, 16 June 2014 20:46:32 -0400, Nick Krause wrote:
>
> You are right about the compile errors it compiles but with warning.
> I am curious since the function is void how do you want me to
> give the error back to logfs and in turn the other subsystems
> of the kernel.
My first question would
On Wed, 11 June 2014 11:27:42 -0400, Theodore Ts'o wrote:
> On Tue, Jun 10, 2014 at 08:10:09PM -0400, Jörn Engel wrote:
> > > I'm also concerned about how much overhead this might eat up. I've
> > > already had someone who was benchmarking a high perfo
On Tue, 10 June 2014 20:10:09 -0400, Jörn Engel wrote:
> On Tue, 10 June 2014 12:14:01 -0400, Theodore Ts'o wrote:
> > On Mon, May 19, 2014 at 05:17:19PM -0400, Jörn Engel wrote:
> > > +/*
> > > + * Ratelimit to a steady state of about once per jiffy. A naïve appro
On Tue, 10 June 2014 12:14:01 -0400, Theodore Ts'o wrote:
> On Mon, May 19, 2014 at 05:17:19PM -0400, Jörn Engel wrote:
> > +/*
> > + * Ratelimit to a steady state of about once per jiffy. A naïve approach
> > + * would be to return 1 every time jiffies chan
On Wed, 4 June 2014 16:28:32 -0700, Andrew Morton wrote:
>
> Sorry, it seems I'm better at losing stuff than I thought I was.
The trouble with forgetting stuff is that few people remember ever
doing so. But they do remember other people forgetting stuff.
> I've restored the patch to the input q
Ping.
Jörn
--
Computer system analysis is like child-rearing; you can do grievous damage,
but you cannot ensure success."
-- Tom DeMarco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
On Mon, 28 April 2014 17:22:19 -0700, Andrew Morton wrote:
> On Mon, 28 Apr 2014 19:40:39 -0400 J__rn Engel wrote:
> > On Thu, 24 April 2014 15:40:24 -0400, J__rn Engel wrote:
> > > On Wed, 23 April 2014 20:52:47 -0400, J__rn Engel wrote:
> > > >
> > > > I use the patch below for some time now.
On Wed, 21 May 2014 21:39:05 +0200, Andi Kleen wrote:
>
> > I think leaking of private keys or similar information is not a
> > concern. But please prove me wrong. Better you now than someone else
> > later.
>
> While I don't have a concrete exploit it seems seems dangerous to me.
> The LibreS
On Wed, 21 May 2014 21:39:05 +0200, Andi Kleen wrote:
>
> > I think leaking of private keys or similar information is not a
> > concern. But please prove me wrong. Better you now than someone else
> > later.
>
> While I don't have a concrete exploit it seems seems dangerous to me.
> The LibreS
On Tue, 20 May 2014 05:12:07 -0700, Andi Kleen wrote:
> Jörn Engel writes:
> >
> > An alternate high-resolution timer is the register content at the time
> > of an interrupt.
>
> So if you interrupt a cryptographic function you may hash in parts
> of the k
On Mon, 19 May 2014 16:05:06 -0700, H. Peter Anvin wrote:
> On 05/19/2014 03:39 PM, Jörn Engel wrote:
> >
> > I would feel fairly confident giving this .25 bits of entropy per
> > event. With 40% unique hashes and assuming at most 1 bit of entropy
> > for a un
On Mon, 19 May 2014 15:18:01 -0700, H. Peter Anvin wrote:
>
> I think this is likely to be particularly valuable during boot. I can
> see it becoming substantially less valuable after that point, but during
> boot is when the most critical.
>
> What I do see as an issue is that the value is prob
On Mon, 19 May 2014 17:17:19 -0400, Jörn Engel wrote:
>
> Experimentation show this to be an excellent entropy source. Doing 1000
> boottests with kvm and dumping a hash of the registers for the first
> 1024 interrupts each, >40% of all hashes were unique and >80% of all
>
The single biggest entropy source is a high-resolution timer running
asynchronous to the triggering event. That leaves systems without a
useful get_cycles() implementation with significantly less entropy.
Significant means orders of magnitude, not a few percent.
An alternate high-resolution timer
On Thu, 24 April 2014 15:40:24 -0400, Jörn Engel wrote:
> On Wed, 23 April 2014 20:52:47 -0400, Jörn Engel wrote:
> >
> > I use the patch below for some time now. While it doesn't avoid the
> > log pollution in the first place, it lessens the impact somewhat.
>
On Fri, 25 April 2014 00:21:20 +0200, Jiri Kosina wrote:
> On Thu, 24 Apr 2014, David Rientjes wrote:
>
> > > Well, if you have dmesg dump from panic that happens every other year,
> > > and
> > > you have to do post-mortem analysis on it, I am pretty sure you would
> > > love
> > > to be able
On Thu, 24 April 2014 12:58:21 -0700, Greg Kroah-Hartman wrote:
> > @@ -868,11 +870,20 @@ static size_t print_time(u64 ts, char *buf)
> >
> > rem_nsec = do_div(ts, 10);
> >
> > +#ifdef CONFIG_PRINTK_CPU
> > + if (!buf)
> > + return snprintf(NULL, 0, "[%5lu.00,%02x] "
On Wed, 23 April 2014 20:52:47 -0400, Jörn Engel wrote:
>
> I use the patch below for some time now. While it doesn't avoid the
> log pollution in the first place, it lessens the impact somewhat.
Added a config option and ported it to current -linus. Andrew, would
you t
On Wed, 23 April 2014 23:37:54 +0200, Jiri Kosina wrote:
>
> This, however, will make RCU stall detector to send NMI to all online CPUs
> so that they can dump their stacks.
>
> IOW, this might actually make the whole sysrq dump last for much longer,
> and have the log polluted with all-CPU dum
On Mon, 3 February 2014 13:48:57 -0500, Jörn Engel wrote:
> On Mon, 3 February 2014 11:37:29 -0500, Theodore Ts'o wrote:
> >
> > So we could take the struct pt_regs which we get from get_irq_regs(),
> > XOR them together and use them to feed int
On Wed, 12 February 2014 19:06:37 -0500, David Miller wrote:
>
> It isn't being used to determine when to destroy things.
>
> They use it to as a heuristic of when to trigger polling.
>
> Each ubuf attached gets a kref to the higher level virtio_net buffer
> holding object, they want to trigger
On Tue, 4 February 2014 12:39:28 -0800, H. Peter Anvin wrote:
>
> USB and the Ethernet PHY frequently do still have their own crystals,
> for reasons not entirely clear to me. However, what all of these have
> in common is that they are way out in the periphery.
Storage might be another source.
On Thu, 6 February 2014 14:20:02 -0800, Kees Cook wrote:
> On Sun, Feb 02, 2014 at 03:36:17PM -0500, Jörn Engel wrote:
> > Collects entropy from random behaviour all modern cpus exhibit. The
> > scheduler and slab allocator are instrumented for this purpose. How
> > m
On Mon, 3 February 2014 11:37:29 -0500, Theodore Ts'o wrote:
>
> So we could take the struct pt_regs which we get from get_irq_regs(),
> XOR them together and use them to feed into input[2] amd input[3] in
> add_interrupt_randomness(). Or some other way of distributing the
> values of all of the
On Sun, 2 February 2014 15:36:17 -0500, Jörn Engel wrote:
>
> Measuring the randomness from random_get_entropy() with above approach
> failed because there was so much randomness. All numbers in all runs
> were different. Taking the delta between the numbers, again almost all
&g
On Sun, 2 February 2014 20:39:22 -0500, Theodore Ts'o wrote:
>
> The real question is how much overhead does it add, and is it worth
> it. Jörn, I take it that was the reason for creating an even faster,
> but weaker mixing function? Was the existing "fast mix" causing a
> measurable overhead, o
On Sun, 2 February 2014 22:25:31 +0100, Stephan Mueller wrote:
> Am Sonntag, 2. Februar 2014, 15:36:17 schrieb Jörn Engel:
>
> > Collects entropy from random behaviour all modern cpus exhibit. The
> > scheduler and slab allocator are instrumented for this purpose. How
> >
Collects entropy from random behaviour all modern cpus exhibit. The
scheduler and slab allocator are instrumented for this purpose. How
much randomness can be gathered is clearly hardware-dependent and hard
to estimate. Therefore the entropy estimate is zero, but random bits
still get mixed into
On Wed, 25 September 2013 16:28:53 +0200, Thomas Meyer wrote:
>
> I wonder how hard it would be to implement this on vfs layer?
As an ugly hack: a few weeks maybe. Did it back in 2005 or so. If
you have higher standards, you will need support from the underlying
filesystem. Especially in order
On Mon, 7 October 2013 10:49:43 -0700, Brian Norris wrote:
>
> [After more research:] It looks like this topic may be the subject of
> some long-past flame wars. If I am digging up past demons, then I'd
> prefer to let sleeping Balrogs lie.
Most of the time it is obvious from context whether you
On Tue, 1 October 2013 13:07:17 +0200, Thierry Reding wrote:
>
> Today's linux-next merge of the bcon tree got conflicts in:
>
> drivers/block/Kconfig
> kernel/printk.c
>
> I fixed them up (see below). Please check if the resolution looks correct.
I think for the moment you can drop
On Sun, 22 September 2013 22:43:38 -0400, Theodore Ts'o wrote:
> On Sun, Sep 22, 2013 at 08:16:23PM -0400, Jörn Engel wrote:
> > How about we switch between the two mixing functions depending on the
> > interrupt load? If this CPU has seen fewer than 1000 interrupts in
>
On Sun, 22 September 2013 19:36:41 -0400, Theodore Ts'o wrote:
> On Sun, Sep 22, 2013 at 04:53:34PM -0400, Jörn Engel wrote:
> >
> > And I want to keep that function. Essentially the point of fast_mix()
> > is to ratelimit _mix_pool_bytes(). Naïve ratelimiting would si
On Sun, 22 September 2013 17:27:52 -0400, Theodore Ts'o wrote:
>
> The structure of the mixing functions in /dev/random has been well
> studied, and validatetd in a number of different academic papers. So
> I prefer to stick with the basic architecture, even as it is scaled
> down for speed reaso
On Sat, 21 September 2013 17:41:18 -0400, Theodore Ts'o wrote:
>
> BTW, just to give another example of the difference between the mixing
> funtions, try compiling the following with and without ORIG_MIX defined...
Garbage in, garbage out again. If there is absolutely no randomness
in the input
On Sat, 21 September 2013 17:25:10 -0400, Theodore Ts'o wrote:
> On Mon, Sep 16, 2013 at 11:40:27AM -0400, Jörn Engel wrote:
> >
> > Here is a patch to make add_interrupt_randomness() significantly
> > cheaper without significantly impacting the quality. The seco
On Thu, 12 September 2013 19:31:55 -0400, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 05:07:17PM -0400, Jörn Engel wrote:
> >
> > I happen to have a real-world system with >100k interrupts per second
> > and - surprise - add_interrupt_randomness() showed up promin
On Fri, 13 September 2013 07:36:20 +0200, Stephan Mueller wrote:
> Am Donnerstag, 12. September 2013, 17:31:48 schrieb Jörn Engel:
> >
> >The basic principle of Ted's RNG is very simple and quite sane:
> >- You collect as much data as possible, some of which is (hop
On Thu, 12 September 2013 22:13:49 -0400, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 06:23:09PM -0400, Jörn Engel wrote:
> > It is worse in three ways:
> > - it costs performance,
> > - it may create a false sense of safety and
> > - it actively does
On Thu, 12 September 2013 19:35:36 -0400, Jörn Engel wrote:
>
> I think the existing code is doing just fine for low interrupt loads.
> It makes sense to spend a bit more work to squeeze the last bit of
> randomness out. But when you get lots of interrupts, you can be
> slop
On Thu, 12 September 2013 19:31:55 -0400, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 05:07:17PM -0400, Jörn Engel wrote:
> >
> > I happen to have a real-world system with >100k interrupts per second
> > and - surprise - add_interrupt_randomness() showed up promin
On Thu, 12 September 2013 16:51:15 -0700, Andy Lutomirski wrote:
>
> Supposedly, the Linux entropy pool has the property that mixing in
> even actively malicious data is no worse than not mixing in anything
> at all.
It is worse in three ways:
- it costs performance,
- it may create a false sense
On Thu, 12 September 2013 19:39:47 -0400, Jeff Garzik wrote:
> On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel wrote:
> > On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
> >> But I also think that the existing (certified) TPMs are good enough
> >> for
On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>
> But I also think that the existing (certified) TPMs are good enough
> for direct use.
That is equivalent to trusting the TPM chip not to be malicious. It
requires trusting the chip designer, trusting every single employee of
the
On Tue, 10 September 2013 15:08:12 -0700, John Stultz wrote:
> Though
> I probably should be hesitant with my suggestions, as I'm not well
> versed in RNG theory.
The basic principle of Ted's RNG is very simple and quite sane:
- You collect as much data as possible, some of which is (hopefully)
On Thu, 12 September 2013 14:15:35 +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller wrote:
> >>BTW, I prefer a different name than "random_get_fast_cycles()", as it's
> >>better to have something that returns different and unpredictable
> >>numbers than an actual
On Tue, 10 September 2013 20:50:47 -0400, Theodore Ts'o wrote:
>
> Yep. The worse case would probably a serial port running at 230400
> bps. Even with a 16550A UART with the 16-byte FIFO, we're talking
> about close to 2,000 interrupts per second. A 16450 running at 115200
> bps would give us 1
On Fri, 6 September 2013 09:57:31 -0400, Theodore Ts'o wrote:
> according to its specifications. But a HWRNG is by definition
> something that can't be tested. Statistical tests are not sufficient
> to prove that the HWRNG has not been gimmicked.
And just to prove your point even more:
http://pe
On Sat, 10 August 2013 20:23:09 +0200, Borislav Petkov wrote:
>
> Sounds like the debug aspect and the preemption point addition need
> to be sorf-of split into two different functions/macros and each used
> separately.
>
> Something like keep the current might_sleep and have debug_sleep or
> sim
On Wed, 7 August 2013 03:21:47 -0600, Andreas Dilger wrote:
>
> I'm not saying that a tool to check this would be a bad thing, but
> if the compression support is a generic feature of the VFS, then it
> makes sense that the checker can also be generic and unrelated to
> the filesystem metadata che
On Mon, 5 August 2013 01:26:46 -0700, Christoph Hellwig wrote:
> On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
> > The patch looks right to me - we should pass in similar flags for the
> > create case as for tmpfile to the filesystem.
> >
> > But let's make sure we're all on the
On Sat, 3 August 2013 20:33:16 -0400, Theodore Ts'o wrote:
>
> P.P.S. At least in theory, nothing of what I've described here has to
> be ext4 specific. We could implement this in the VFS layer, at which
> point not only ext4 would benefit, but also btrfs, xfs, f2fs, etc.
Except for an inode bi
On Thu, 1 August 2013 10:45:15 -0700, Linus Torvalds wrote:
> On Thu, Aug 1, 2013 at 8:37 AM, Jörn Engel wrote:
> >
> > Looks like two of Linus' mails didn't make it to vger.kernel.org.
> > They are missing from my inbox and seem to be missing from lkml.org as
>
On Wed, 31 July 2013 19:12:30 -0400, Rik van Riel wrote:
> On 07/31/2013 06:46 PM, Linus Torvalds wrote:
> > > On 07/31/2013 06:21 PM, Linus Torvalds wrote:
Looks like two of Linus' mails didn't make it to vger.kernel.org.
They are missing from my inbox and seem to be missing from lkml.org as
well
On Fri, 26 July 2013 12:01:23 +0400, Vyacheslav Dubeyko wrote:
>
> We are discussing not about good or bad idea. We need to elaborate a
> right solution. I think that suggested idea is not clear. Do you want to
> support compression in ext4? Or do you want to add some new compression
> feature (li
1 - 100 of 573 matches
Mail list logo
