Bug #216: splice_dentry error - Linux kernel client - Ceph

Actions

Copy link

Bug #216

closed

splice_dentry error

Added by Sage Weil almost 14 years ago. Updated over 13 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Sage Weil

Category:

Target version:

v2.6.36

% Done:

50%

Source:

Tags:

Backport:

Regression:

Severity:

Reviewed:

Affected Versions:

ceph-qa-suite:

Crash signature (v1):

Crash signature (v2):

Description

since 2 days 1 of my tests fail and crash my machine.

the script crashing the machine is:
http://github.com/vinzent/ceph-testsuite/blob/master/tests/snaptest-2
( take lines 13 to 67 for standalone usage)

i can see these messages before my machine stops responding:

[11188.432605] ceph: tid 67394 timed out on osd0, will reset osd
[11530.455936] ceph: splice_dentry error ffff8800a4891d80 inode
ffff880100349d30 ino 10000001a4d.6
[11530.455961] BUG: unable to handle kernel NULL pointer dereference at
0000000000000078
[11530.455964] IP: [<ffffffffa0734049>] update_dentry_lease+0x20/0x10a
[ceph]

(full output: http://pastebin.com/WFUztaEP)

kclient: ceph-client-standalone/unstable-backport
ceph: ceph/unstable

last known working ceph/unstable git ref
c626ac384678661b765c1ae1dee8db48b2c70993

Actions

Copy link

Updated by Sage Weil almost 14 years ago

we shouldn't crash when splice_dentry fails. fixed by commit:61671a81b82e414b0b4e81ce1282a9b92e4834b6

as for why splice_dentry is returning an error in the first place, that needs a closer look. it's tied with up vfs internals, but i'm not sure why it would happen under normal operation. were there any bind mounts, or submounts (mount -t ceph server:/some/sub/dir /mnt/foo)?

Actions

Copy link

Updated by Sage Weil almost 14 years ago

Status changed from New to In Progress
Assignee set to Sage Weil

Actions

Copy link

Updated by Sage Weil almost 14 years ago

Sage Weil wrote:

we shouldn't crash when splice_dentry fails. fixed by commit:61671a81b82e414b0b4e81ce1282a9b92e4834b6

as for why splice_dentry is returning an error in the first place, that needs a closer look. it's tied with up vfs internals, but i'm not sure why it would happen under normal operation. were there any bind mounts, or submounts (mount -t ceph server:/some/sub/dir /mnt/foo)?

make that commit:d69ed05a80f23b25f06e73af9b7e701ce4900edc

Actions

Copy link