[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080104162705.44b61e9a@laptopd505.fenrus.org>
Date: Fri, 4 Jan 2008 16:27:05 -0800
From: Arjan van de Ven <arjan@...radead.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Theodore Tso <tytso@....edu>, Andi Kleen <andi@...stfloor.org>,
Christoph Lameter <clameter@....com>, Willy Tarreau <w@....eu>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [patch] slub: provide /proc/slabinfo
On Tue, 1 Jan 2008 17:23:28 +0100
Ingo Molnar <mingo@...e.hu> wrote:
>
> * Theodore Tso <tytso@....EDU> wrote:
>
> > [...] doesn't a patch to provide /proc/slabinfo for SLUB already
> > exist?
>
> yes, the complete (and tested) patch is below. It has been through a
> few thousand random-bootup tests on x86 32-bit and 64-bit so it's
> v2.6.24 material i think.
> +static void *s_start(struct seq_file *m, loff_t *pos)
> +{
> + loff_t n = *pos;
> +
> + down_read(&slub_lock);
> + if (!n)
> + print_slabinfo_header(m);
> +
> + return seq_list_start(&slab_caches, *pos);
> +}
> +
this is the part I'm not very thrilled about... at least on first sight
it looks like a user can now hold the read sem over system calls, and for as long as it wants.
Either that's no problem (but then we wouldn't need the lock in the first place) or it
is a problem that then wants to be fixed
--
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/
Powered by blists - more mailing lists