On Fri, 5 Oct 2012 10:04:42 -0700 Peter Moody <[email protected]> wrote:
> On Fri, Oct 5, 2012 at 9:15 AM, Jeff Layton <[email protected]> wrote: > > >> > >> ------------[ cut here ]------------ > >> kernel BUG at fs/buffer.c:1220! > >> invalid opcode: 0000 [#1] SMP > >> CPU 0 > >> Pid: 3683, comm: a.out Not tainted 3.5.0 #3 > >> RIP: e030:[<ffffffff816a99f4>] [<ffffffff816a99f4>] > >> check_irqs_on.part.8+0x4/0x6 > >> RSP: e02b:ffff8807b156dc28 EFLAGS: 00010046 > >> RAX: ffff8807d0dd0000 RBX: ffff8807a7d6df28 RCX: 0000000005883396 > >> RDX: 0000000000001000 RSI: 0000000005883396 RDI: ffff8807cfc0c000 > >> RBP: ffff8807b156dc28 R08: 0000000000000001 R09: ffff8807a7d6de50 > >> R10: f83a2b0a359bf007 R11: 0000000000000000 R12: ffff8807a7d6de54 > >> R13: ffff8807a7d6de80 R14: ffff8807cfc1f120 R15: 0000000005883396 > >> FS: 00007f97164ec700(0000) GS:ffff8807ffc00000(0063) > >> knlGS:0000000000000000 > >> CS: e033 DS: 002b ES: 002b CR0: 000000008005003b > >> CR2: 00000000f76ca3b0 CR3: 00000007bbb53000 CR4: 0000000000002660 > >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > >> Process a.out (pid: 3683, threadinfo ffff8807b156c000, task > >> ffff8807bbae8000) > >> Stack: > >> ffff8807b156dc98 ffffffff8116a099 ffff8807b59f3000 ffff8807b156dd30 > >> ffff8807b156dd60 ffff8807b156de78 ffff8807b156dc78 ffffffff816af231 > >> ffff8807b156dcd8 ffff8807a7d6e538 ffff8807a7d6df28 ffff8807a7d6de54 > >> Call Trace: > >> [<ffffffff8116a099>] __find_get_block+0x1f9/0x200 > >> [<ffffffff816af231>] ? down_read+0x11/0x30 > >> [<ffffffff811d1405>] ext3_clear_blocks+0x75/0x140 > >> [<ffffffff811d15dc>] ext3_free_data+0x10c/0x150 > >> [<ffffffff811e2061>] ? ext3_journal_start_sb+0x31/0x60 > >> [<ffffffff811d1cb5>] ext3_truncate+0x4a5/0x600 > >> [<ffffffff8123d5b8>] ? journal_start+0xb8/0x100 > >> [<ffffffff8106f406>] ? bit_waitqueue+0x16/0xc0 > >> [<ffffffff811d4598>] ext3_evict_inode+0x248/0x2c0 > >> [<ffffffff81153b9a>] evict+0xaa/0x1b0 > >> [<ffffffff81154843>] iput+0x103/0x210 > >> [<ffffffff8114fc88>] dentry_iput+0x88/0xd0 > >> [<ffffffff811505ec>] dput+0x12c/0x250 > >> [<ffffffff81146275>] path_put+0x15/0x30 > >> [<ffffffff810b2f35>] __audit_syscall_exit+0x2e5/0x460 > >> [<ffffffff816b30be>] sysexit_audit+0x29/0x5b > >> Code: 04 00 00 4c 8d 88 c0 02 00 00 31 c0 e8 5f da ff ff 48 85 db 74 > >> 0c 80 43 5c 01 48 89 df e8 d5 > >> 6a aa ff 5b 41 5c 5d c3 55 48 89 e5 <0f> 0b 55 48 89 e5 0f 0b 55 48 89 > >> e5 0f 0b 55 48 89 e5 41 54 53 > >> RIP [<ffffffff816a99f4>] check_irqs_on.part.8+0x4/0x6 > >> RSP <ffff8807b156dc28> > >> ---[ end trace 8d09f8cfbb601c14 ]--- > >> > >> > > > > I don't see a function called sysexit_audit in 3.5. I assume that's > > created via some sort of macro goop? > > It looks like it's defined in arch/x86/kernel/entry_32.S > > my asm is non-existent, but it looks like it's calling > __audit_syscall_exit and the disabling interrupts. > BTW, this is not really my area of expertise either, but I think that's the asm goop for "native" 32-bit x86. The asm for 32-bit binaries running on a 64-bit kernel are in arch/x86/ia32/ia32entry.S. >From what I can tell though, it looks like it should be calling __audit_syscall_exit with interrupts enabled: --------------[snip]----------------- .macro auditsys_exit exit testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) jnz ia32_ret_from_sys_call TRACE_IRQS_ON sti movl %eax,%esi /* second arg, syscall return value */ cmpl $-MAX_ERRNO,%eax /* is it an error ? */ jbe 1f movslq %eax, %rsi /* if error sign extend to 64 bits */ 1: setbe %al /* 1 if error, 0 if not */ movzbl %al,%edi /* zero-extend that into %edi */ call __audit_syscall_exit movq RAX-ARGOFFSET(%rsp),%rax /* reload syscall return value */ movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi cli TRACE_IRQS_OFF testl %edi,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) jz \exit CLEAR_RREGS -ARGOFFSET jmp int_with_check .endm --------------[snip]----------------- AIUI, "sti" is what enables interrupts, and I don't see a call to "cli" (which disables interrupts) until after __audit_syscall_exit. Either something is reordering those instructions (which seems very unlikely), or we're not looking at the right syscall code? -- Jeff Layton <[email protected]> -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
