Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754934AbYAEAcT (ORCPT ); Fri, 4 Jan 2008 19:32:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754081AbYAEAcG (ORCPT ); Fri, 4 Jan 2008 19:32:06 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:43955 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754079AbYAEAcE (ORCPT ); Fri, 4 Jan 2008 19:32:04 -0500 Date: Fri, 4 Jan 2008 16:27:05 -0800 From: Arjan van de Ven To: Ingo Molnar Cc: Theodore Tso , Andi Kleen , Christoph Lameter , Willy Tarreau , Steven Rostedt , Linus Torvalds , Peter Zijlstra , LKML , Andrew Morton , Christoph Hellwig , "Rafael J. Wysocki" Subject: Re: [patch] slub: provide /proc/slabinfo Message-ID: <20080104162705.44b61e9a@laptopd505.fenrus.org> In-Reply-To: <20080101162328.GC20426@elte.hu> References: <20071222221050.GA20753@1wt.eu> <20071223051241.GA4449@1wt.eu> <20071223141500.GB6430@one.firstfloor.org> <20071224034530.GB16658@thunk.org> <20071224233701.GB9784@kernel.org> <20071225033418.GA29199@one.firstfloor.org> <20080101124741.GH11776@mit.edu> <20080101162328.GC20426@elte.hu> Organization: Intel X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1128 Lines: 36 On Tue, 1 Jan 2008 17:23:28 +0100 Ingo Molnar wrote: > > * Theodore Tso 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/