[Linux-cachefs] Kernel traceback on 3.10.10

[David Howells]

Mark Moseley <moseleymark at gmail.com> 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