From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754281AbYE1KET (ORCPT ); Wed, 28 May 2008 06:04:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751929AbYE1KEL (ORCPT ); Wed, 28 May 2008 06:04:11 -0400 Received: from mail.gmx.net ([213.165.64.20]:51580 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751722AbYE1KEJ (ORCPT ); Wed, 28 May 2008 06:04:09 -0400 X-Authenticated: #704063 X-Provags-ID: V01U2FsdGVkX1/bZLIRbeXbKByyWz+g+NyDoLzCuZIdgYhOCDtMpF IAWXsP00/js/Vb Date: Wed, 28 May 2008 12:03:57 +0200 From: Eric Sesterhenn To: Chris Wright Cc: Pekka Enberg , linux-kernel@vger.kernel.org, James Morris , William Lee Irwin III , Andrew Morton , Vegard Nossum Subject: Re: Redzone overwritten with CONFIG_SECURITY Message-ID: <20080528100357.GA2510@alice> References: <20080526143422.GA3203@alice> <84144f020805270800l5911ed02ia7a92d96a8aa32a7@mail.gmail.com> <20080527174738.GZ30402@sequoia.sous-sol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080527174738.GZ30402@sequoia.sous-sol.org> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snake-basket.de X-Operating-System: Linux/2.6.26-rc4 (x86_64) X-Uptime: 11:59:11 up 3:08, 1 user, load average: 0.21, 0.12, 0.12 User-Agent: Mutt/1.5.16 (2007-06-09) X-Y-GMX-Trusted: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Chris Wright (chrisw@sous-sol.org) wrote: > * Pekka Enberg (penberg@cs.helsinki.fi) wrote: > > On Mon, May 26, 2008 at 5:34 PM, Eric Sesterhenn wrote: > > > i enabled CONFIG_SECURITY on current git and get tons of > > > Redzone overwritten errors during early boot, even > > > with CONFIG_SECURITY_CAPABILITIES and CONFIG_SECURITY_NETWORK > > > disabled. After a while it ends with a kernel panic > > > saying: not syncing: Out of memory and no killable process... > > > Root partition is ext3 format. > > > > So what kernel version is this and what's the last known version that > > worked? As it's early boot crash, maybe you can try to do git bisect > > on it? > > > > > > > > At the moment i dont have a camera at hand, so i'll try > > > to write down everything which looks interesting, please tell > > > me if i missed something. > > > > > > The first 24 Bytes of the overwritten section contain > > > zeros. Then we have a constant 0x18, and three changing > > > values. the next three bites contain exactly the same > > > values, first the 0x18, then the two changing ones. > > > > > > The only value i found so far matching the 0x18 and > > > which might be related to CONFIG_SECURITY is CAP_SYS_RESOURCE > > > defined in /include/linux/capability.h > > > > > > BUG hugetlbfs_inode_cache: Redzone overwritten > > > > > > INFO: 0xccd8e250-0xccd8e253. First byte 0x0 instead of 0xbb > > > Info: Slab 0xc119d1c0 objects=12 used=0 fs=0xccd8e000 flags=0x400020c3 > > > Info: Object 0xccd8e00 offset=0 fp=0xccd8e280 > > > > > > Object 0xccd8e00: 00 00 00 ... > > > Object 0xccd8e10: 00 00 00 00 00 00 00 00 00 18 e0 d8 cc 18 e0 d8 cc > > > Object 0xccd8e20 00 00 00 ... > > That looks like an addr within the object, like an INIT_LIST_HEAD. > > > > Pid: 1, comm:swapper Not tainted 2.6.26-rc3-00436-gb373303 #42 > > > print_trailer > > > check_bytes_and_report > > > check_object > > > __slab_alloc > > > kmem_cache_alloc > > > ? hugetlbfs_alloc_inode > > > ? hugetlbfs_alloc_inode > > > hugetlbfs_alloc_inode > > > alloc_inote > > > new_inode > > > hugetlbs_get_inote > > > hugetlbfs_fill_super > > > ? sget > > > ? set_anon_super > > > get_sb_node > > > hugetlbfs_get_sb > > > ? hugetlbfs_fill_super > > > vfs_kern_mount > > > kern_mount_data > > > init_hugetlbfs_fs > > > ? init_once > > > ? kernel_init > > > kernel_init > > ok, do_init_calls time frame with that config...CONFIG_SECURITY isn't > really doing any allocations, nor much in the way of memory writes. > It would get called into via the: > > hugetlbs_get_inode > new_inode > alloc_inode > security_inode_alloc <-- and that'd be basically a no-op > > > > Config follows: > > I couldn't recreate with that config. I did a fresh git-clone and tried again without being able to reproduce this. I diffed all .h and .c files and except for the autogenerated ones they are exactly the same... Is it possible that this was caused because a file didnt get rebuild correctly? I can still reproduce it with the old checkout. Sorry if this causes unessecary noise :( Greetings, Eric