Mark Moseley <moseleymark@xxxxxxxxx> wrote: > (gdb) disas __fscache_uncache_page > Dump of assembler code for function __fscache_uncache_page: > 0xffffffff812a18e0 <+0>: callq 0xffffffff81d6ff00 > 0xffffffff812a18e5 <+5>: push %rbp > 0xffffffff812a18e6 <+6>: mov %rsp,%rbp > 0xffffffff812a18e9 <+9>: sub $0x20,%rsp > 0xffffffff812a18ed <+13>: mov %rbx,-0x18(%rbp) > 0xffffffff812a18f1 <+17>: mov %rdi,%rbx > 0xffffffff812a18f4 <+20>: mov %r12,-0x10(%rbp) > 0xffffffff812a18f8 <+24>: mov %r13,-0x8(%rbp) > 0xffffffff812a18fc <+28>: mov %rsi,%r12 The next three instructions are: ASSERTCMP(cookie->def->type, !=, FSCACHE_COOKIE_TYPE_INDEX); > 0xffffffff812a18ff <+31>: mov 0x48(%rbx),%rax > 0xffffffff812a1903 <+35>: cmpb $0x0,0x10(%rax) > 0xffffffff812a1907 <+39>: je 0xffffffff812a19cd <__fscache_uncache_page+237> That cmpb is the faulting instruction (%rax is 0). So cookie->def is NULL - which presumably means that the cookie has already been at least partway through __fscache_relinquish_cookie(). Hmmm... :-/ I can see a couple of ways this could happen: open(O_TRUNC|O_RDONLY) racing with open(O_WRONLY) or: a race between open(O_TRUNC|O_WRONLY), open(O_RDONLY) and open(O_WRONLY) In the second way, the first open ditches the cookie, the second gets it again and the third ditches it again. However, the first call does the open then the truncation as separate steps with no lock held over them. I need to prevent acquisition of a cookie when an inode is already open for writing. Consulting i_writecount might do the trick. David -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
