From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [PATCH] audit: grab a reference to context->pwd when it's cached Date: Fri, 5 Oct 2012 10:26:04 -0400 Message-ID: <20121005102604.6eccd676@corrin.poochiereds.net> References: <1345079613-27388-1-git-send-email-pmoody@google.com> <20120816012642.GA10020@shell.devel.redhat.com> <20120926135020.GB31705@shell.devel.redhat.com> <20121005085558.76d36641@corrin.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Peter Moody Cc: lczerner@redhat.com, linux-audit@redhat.com, sandeen@redhat.com List-Id: linux-audit@redhat.com On Fri, 5 Oct 2012 06:57:59 -0700 Peter Moody wrote: > On Fri, Oct 5, 2012 at 5:55 AM, Jeff Layton wrote: > > On Thu, 4 Oct 2012 11:48:23 -0700 > > Peter Moody wrote: > > > >> On Wed, Sep 26, 2012 at 6:50 AM, Alexander Viro wrote: > >> > On Tue, Sep 25, 2012 at 10:03:23AM -0700, Peter Moody wrote: > >> >> Hey folks, > >> >> > >> >> following up on old patches, are there any comments on this? Did you > >> >> get around to finding a better way to fix this bug, Al? > >> > > >> > Alas, I've found none ;-/ Looks like we'll have to go with this one, > >> > at least until somebody comes up with better solution. > >> > >> Not surprisingly, this patch doesn't actually fix the issue (or at > >> least doesn't do it correctly). > >> > >> I hadn't noticed that get_fs_pwd() actually calls path_get() on > >> &context->pwd so the additional path_get() is useless and the > >> reference doesn't ever actually get freed if audit_putname is called > >> while we're in a syscall. > >> > >> Al, Eric, Jeff; do any of you guys have an understanding of what the > >> initial bug actually is since this clearly doesn't fix it? > >> > >> Cheers, > >> peter > >> > > > > BTW, I ran this test on one of my KVM guests and it ran just fine. That > > one is an x86_64 guest running a 3.6.0+ kernel. The root fs on there is > > ext4 though, not ext3. So perhaps that's a factor? > > > > The oops message you posted at least looks like something down in the > > bowels of ext3 or fs/buffer.c. > > Yeah, the only place this actually happens for me on these giant xen > instances we have (6 cores, 32G ram) and it happens on both ext3 and > ext4 filesystems and it happens with 100% reliability. > > The actual oops is from: > > static inline void check_irqs_on(void) > { > #ifdef irqs_disabled > BUG_ON(irqs_disabled()); > #endif > } > > with the code path looking like: > > __find_get_block() -> lookup_bh_lru() -> check_irqs_on() -> BUG() > Do you have a backtrace from a more recent kernel? I wonder if something in the syscall exit codepath is disabling IRQs here? -- Jeff Layton