linux-kernel - Re: [PATCH v3 4/5] slub: Only IPI CPUs that have per cpu obj to flush

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 13 Nov 2011 20:20:12 +0800
From:	Hillf Danton <dhillf@...il.com>
To:	Gilad Ben-Yossef <gilad@...yossef.com>
Cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Russell King <linux@....linux.org.uk>, linux-mm@...ck.org,
	Christoph Lameter <cl@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>
Subject: Re: [PATCH v3 4/5] slub: Only IPI CPUs that have per cpu obj to flush

On Sun, Nov 13, 2011 at 6:17 PM, Gilad Ben-Yossef <gilad@...yossef.com> wrote:
> flush_all() is called for each kmem_cahce_destroy(). So every cache
> being destroyed dynamically ended up sending an IPI to each CPU in the
> system, regardless if the cache has ever been used there.
>
> For example, if you close the Infinband ipath driver char device file,
> the close file ops calls kmem_cache_destroy(). So running some
> infiniband config tool on one a single CPU dedicated to system tasks
> might interrupt the rest of the 127 CPUs I dedicated to some CPU
> intensive task.
>
> I suspect there is a good chance that every line in the output of "git
> grep kmem_cache_destroy linux/ | grep '\->'" has a similar scenario.
>
> This patch attempts to rectify this issue by sending an IPI to flush
> the per cpu objects back to the free lists only to CPUs that seems to
> have such objects.
>
> The check which CPU to IPI is racy but we don't care since asking a
> CPU without per cpu objects to flush does no damage and as far as I
> can tell the flush_all by itself is racy against allocs on remote
> CPUs anyway, so if you meant the flush_all to be determinstic, you
> had to arrange for locking regardless.
>
> Without this patch the following artificial test case:
>
> $ cd /sys/kernel/slab
> $ for DIR in *; do cat $DIR/alloc_calls > /dev/null; done
>
> produces 166 IPIs on an cpuset isolated CPU. With it it produces none.
>
> The code path of memory allocation failure for CPUMASK_OFFSTACK=y
> config was tested using fault injection framework.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@...yossef.com>
> Acked-by: Chris Metcalf <cmetcalf@...era.com>
> CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> CC: Frederic Weisbecker <fweisbec@...il.com>
> CC: Russell King <linux@....linux.org.uk>
> CC: linux-mm@...ck.org
> CC: Christoph Lameter <cl@...ux-foundation.org>
> CC: Pekka Enberg <penberg@...nel.org>
> CC: Matt Mackall <mpm@...enic.com>
> CC: Sasha Levin <levinsasha928@...il.com>
> CC: Rik van Riel <riel@...hat.com>
> CC: Andi Kleen <andi@...stfloor.org>
> ---
>  mm/slub.c |   15 ++++++++++++++-
>  1 files changed, 14 insertions(+), 1 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 7d2a996..caf4b3a 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2006,7 +2006,20 @@ static void flush_cpu_slab(void *d)
>
>  static void flush_all(struct kmem_cache *s)
>  {
> -       on_each_cpu(flush_cpu_slab, s, 1);
> +       cpumask_var_t cpus;
> +       struct kmem_cache_cpu *c;
> +       int cpu;
> +
> +       if (likely(zalloc_cpumask_var(&cpus, GFP_ATOMIC))) {

Perhaps, the technique of local_cpu_mask defined in kernel/sched_rt.c
could be used to replace the above atomic allocation.

Best regards

Hillf

> +               for_each_online_cpu(cpu) {
> +                       c = per_cpu_ptr(s->cpu_slab, cpu);
> +                       if (c && c->page)
> +                               cpumask_set_cpu(cpu, cpus);
> +               }
> +               on_each_cpu_mask(cpus, flush_cpu_slab, s, 1);
> +               free_cpumask_var(cpus);
> +       } else
> +               on_each_cpu(flush_cpu_slab, s, 1);
>  }
>
>  /*
> --
> 1.7.0.4
>
> --
> 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/
>
>
>
--
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/