linux-kernel - Re: [PATCH] module, fix percpu reserved memory exhaustion

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: <87pq1byzum.fsf@rustcorp.com.au>
Date:	Sat, 12 Jan 2013 11:36:09 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	linux-kernel@...r.kernel.org, Mike Galbraith <efault@....de>,
	Josh Triplett <josh@...htriplett.org>,
	Tim Abbott <tabbott@...lice.com>, "Tejun Heo" <tj@...nel.org>
Subject: Re: [PATCH] module, fix percpu reserved memory exhaustion

Prarit Bhargava <prarit@...hat.com> writes:
> On 01/10/2013 10:48 PM, Rusty Russell wrote:
> The timing were similar.  I didn't see any huge delays, etc.  Can the
> relocations really cause a long delay?  I thought we were pretty much writing
> values to memory...

For x86 that's true, but look at what ppc64 has to do for example.  I'm
guessing you don't have a giant Nvidia proprietary driver module
loading, either.

It just makes me nervous; this kind of boot slowdown typically won't get
diagnosed for several releases, if ever.  Now I've done the work, I'm
going to apply my patch (with an additional fix: I forgot to change
kgdb, which traverses the module list too).

> [I should point out that I'm booting a 32 physical/64 logical, with 64GB of memory]

I figured it had to be something big ;)

>> We currently have PERCPU_MODULE_RESERVE set at 8k: in my 32-bit
>> allmodconfig build, there are only three modules with per-cpu data,
>> totalling 328 bytes.  So it's not reasonable to increase that number to
>> paper over this.
>
> I've been thinking about that.  The problem is that at the same time the kvm
> problem occurs I'm attempting to load a debug module that I've written to debug
> some cpu timer issues that allocates a large amount of percpu data (~.5K/cpu).
> While extending PERCPU_MODULE_RESERVE to 10k might work now, it might not work
> tomorrow if I have the need to increase the size of my log buffer.

Well, it looks like PERCPU_MODULE_RESERVE is actually very generous; it
could easily be halved.  I guess this is because dynamic per-cpu data is
now such a nice alternative (thanks to Tejun).

> <snip patch>
>
> Tested-by: Prarit Bhargava <prarit@...hat.com>
>
> Rusty, you can change that to an Acked-by if you prefer that.  I know some
> engineers prefer one over the other.  I'll also continue doing some reboot
> testing and will email back in a few days to let you know what the timing looks
> like.

There seem to be two kinds of Acked-by:

1) Acked-by: <maintainer>.  ie. "this should go through my tree, but
   it's going via someone else".  I like this: shows the normal
   maintainer is aware of the change.

2) Acked-by: <random>. ie. "I like the concept of the patch though I
   haven't actually read it or tested it".  Completely useless.

OTOH, Tested-by: means it actually fixed someone's problem.

Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/