Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi all,
Further analysis show the following:
crash> dis -lr vfs_ioctl+0x32
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/fs/ioctl.c: 39
0xffffffff8111a719 <vfs_ioctl>: push %rbp
0xffffffff8111a71a <vfs_ioctl+1>: mov %rsp,%rbp
0xffffffff8111a71d <vfs_ioctl+4>: push %r13
0xffffffff8111a71f <vfs_ioctl+6>: push %r12
0xffffffff8111a721 <vfs_ioctl+8>: push %rbx
0xffffffff8111a722 <vfs_ioctl+9>: sub $0x8,%rsp
0xffffffff8111a726 <vfs_ioctl+13>: nopl 0x0(%rax,%rax,1)
0xffffffff8111a72b <vfs_ioctl+18>: mov %rdx,%r13
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/fs/ioctl.c: 42
0xffffffff8111a72e <vfs_ioctl+21>: mov 0x20(%rdi),%rdx
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/fs/ioctl.c: 39
0xffffffff8111a732 <vfs_ioctl+25>: mov %rdi,%rbx
0xffffffff8111a735 <vfs_ioctl+28>: mov %esi,%r12d
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/fs/ioctl.c: 42
0xffffffff8111a738 <vfs_ioctl+31>: test %rdx,%rdx
0xffffffff8111a73b <vfs_ioctl+34>: je 0xffffffff8111a7af
<vfs_ioctl+150>
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/fs/ioctl.c: 45
0xffffffff8111a73d <vfs_ioctl+36>: mov 0x48(%rdx),%rax
0xffffffff8111a741 <vfs_ioctl+40>: test %rax,%rax
0xffffffff8111a744 <vfs_ioctl+43>: je 0xffffffff8111a75c
<vfs_ioctl+67>
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/fs/ioctl.c: 46
0xffffffff8111a746 <vfs_ioctl+45>: mov %r13,%rdx
0xffffffff8111a749 <vfs_ioctl+48>: callq *%rax
0xffffffff8111a74b <vfs_ioctl+50>: mov %eax,%ebx
crash> dis -lr ffffffff8139460e
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/net/socket.c: 927
0xffffffff813945ea <sock_ioctl>: push %rbp
0xffffffff813945eb <sock_ioctl+1>: mov %rsp,%rbp
0xffffffff813945ee <sock_ioctl+4>: push %r14
0xffffffff813945f0 <sock_ioctl+6>: push %r13
0xffffffff813945f2 <sock_ioctl+8>: push %r12
0xffffffff813945f4 <sock_ioctl+10>: push %rbx
0xffffffff813945f5 <sock_ioctl+11>: sub $0x10,%rsp
0xffffffff813945f9 <sock_ioctl+15>: nopl 0x0(%rax,%rax,1)
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/net/socket.c: 934
0xffffffff813945fe <sock_ioctl+20>: mov 0xa0(%rdi),%r14
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/net/socket.c: 927
0xffffffff81394605 <sock_ioctl+27>: mov %esi,%ebx
0xffffffff81394607 <sock_ioctl+29>: mov %rdx,%r13
/usr/src/debug/kernel-2.6.34.fc13/linux-2.6.34.x86_64/include/net/sock.h: 1601
0xffffffff8139460a <sock_ioctl+32>: mov 0x38(%r14),%rax
0xffffffff8139460e <sock_ioctl+36>: mov 0x40(%rax),%r12
This corresponds to
fs/ioctl.c
static long vfs_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
...
if (filp->f_op->unlocked_ioctl) {
error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
...
socket.c:
static long sock_ioctl(struct file *file, unsigned cmd, unsigned long arg)
...
net = sock_net(sk);
...
include/net/sock.h:
static inline
struct net *sock_net(const struct sock *sk)
{
...
return sk->sk_net;
...
}
>From what I understand, that means that drbdadm issues some ioctl at the
vfs level, which somehow leads to sock_ioctl() call which in turn fails
because it isn't supposed to be called for vfs. This could mean that
filp->f_op->unlocked_ioctl() is set incorrectly to sock_ioctl. And this
means that actual problem is somewhere in kernel, but is rises only
after some magic ioctl call from drbdadm.
Can anybody from DRBD devs look at this issue?
Best,
Vladislav