From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 6788E9000BD for ; Mon, 19 Sep 2011 16:59:31 -0400 (EDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p8JKxS5a005105 for ; Mon, 19 Sep 2011 13:59:28 -0700 Received: from yie12 (yie12.prod.google.com [10.243.66.12]) by hpaq7.eem.corp.google.com with ESMTP id p8JKxNRm026248 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Sep 2011 13:59:26 -0700 Received: by yie12 with SMTP id 12so4420380yie.3 for ; Mon, 19 Sep 2011 13:59:23 -0700 (PDT) Date: Mon, 19 Sep 2011 13:59:19 -0700 (PDT) From: David Rientjes Subject: Re: [kernel-hardening] Re: [RFC PATCH 2/2] mm: restrict access to /proc/slabinfo In-Reply-To: Message-ID: References: <20110918170512.GA2351@albatros> <20110919144657.GA5928@albatros> <20110919155718.GB16272@albatros> <20110919161837.GA2232@albatros> <20110919173539.GA3751@albatros> <20110919175856.GA4282@albatros> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: Linus Torvalds , Vasiliy Kulikov , Andrew Morton , kernel-hardening@lists.openwall.com, Kees Cook , Cyrill Gorcunov , Al Viro , Christoph Lameter , Matt Mackall , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Dan Rosenberg , Theodore Tso , Alan Cox , Jesper Juhl On Mon, 19 Sep 2011, Pekka Enberg wrote: > Well, sure. I was actually planning to rip out SLUB merging completely > because it makes /proc/slabinfo so useless but never got around doing > that. Ripping out cache merging entirely for the benefit of an interface seems like overkill, it actually allows the allocator to return cache-hot objects that has a small but measurable impact on performance for some networking loads. It would probably be better to increase awareness of slabinfo -a and the use of slub_nomerge on the command line when debugging issues. The most complete solution would be to move everything out of struct kmem_cache except what is necessary for slabinfo and then point to the actual cache data structure that could be shared by merged caches. That's not hard to do, but would add an increment to both the alloc and free fastpaths and require some surgery throughout all of the slub code to understand the new data structures and that would be a pretty big patch. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org