lkml.org 
[lkml]   [2012]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 3.5-rc6 dentry related GPF
On Wed, Jul 11, 2012 at 11:32 AM, Dave Jones <davej@redhat.com> wrote:
>
> What's puzzling me though is how we got from do_dentry_open to try_module_get ?

It's the

f->f_op = fops_get(inode->i_fop);

that does it.

I have no idea what the actual bug is, though, but the code decodes to

0: 89 75 f0 mov %esi,-0x10(%rbp)
3: 4c 89 7d f8 mov %r15,-0x8(%rbp)
7: 66 66 66 66 90 data32 data32 data32 xchg %ax,%ax
c: b8 01 00 00 00 mov $0x1,%eax
11: 48 85 ff test %rdi,%rdi
14: 48 89 fb mov %rdi,%rbx
17: 74 42 je 0x5b
19: 65 48 8b 04 25 b0 c8 mov %gs:0xc8b0,%rax
20: 00 00
22: 83 80 44 e0 ff ff 01 addl $0x1,-0x1fbc(%rax)
29:* 83 3f 02 cmpl $0x2,(%rdi) <-- trapping instruction
2c: 0f 84 54 01 00 00 je 0x186
32: 48 8b 87 50 02 00 00 mov 0x250(%rdi),%rax
39: 65 48 ff 00 incq %gs:(%rax)

where that "cmpl $2" is the "module_is_live(module)" test, as far as I
can tell. And %rdi should be the module pointer, but it is obviously
garbage:

rdi = 54415541e5894855

which looks like some odd corrupted ASCII to me ("UH\211\345AUAT") but
that makes no sense either.

Linus


\
 
 \ /
  Last update: 2012-07-11 22:01    [W:0.063 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site