> I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> BUG:
> [ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> [ 43.232000] in_atomic():1, irqs_disabled():0
> [ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> [ 43.232000] [<c010415e>] show_trace+0x27/0x29
> [ 43.232000] [<c010426e>] dump_stack+0x26/0x28
> [ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
> [ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
> [ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
> [ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
> [ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
> [ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
> [ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
> [ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
> [ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
> [ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
> [ 43.240000] [<b7f38410>] 0xb7f38410
>
>
> This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for
> the following functions:
> - bnep_sock_create
> - cmtp_sock_create
> - hci_sock_create
> - hidp_sock_create
> - l2cap_sock_create
> - rfcomm_sock_create
> - sco_sock_create
There is very similar code in i net/socket.c(I guess some part of
bluetooth/af_bluetooth.c is derived from net/socket.c):
static int __sock_create(int family, int type, int protocol, struct socket **res, int kern)
{
...
net_family_read_lock();
...
if ((err = net_families[family]->create(sock, protocol)) < 0) {
sock->ops = NULL;
goto out_module_put;
}
...
net_family_read_unlock();
return err;
}
I can find GFP_KERNEL is used to allocate object in
net_families[family]->create(sock, protocol). e.g.:
net/ipv4/af_inet.c:
static int inet_create(struct socket *sock, int protocol)
{
...
sk = sk_alloc(PF_INET, GFP_KERNEL, answer_prot, 1);
...
}
Tricks are in net_family_read_lock and net_family_read_unlock:
net/socket.c:
static __inline__ void net_family_read_lock(void)
{
atomic_inc(&net_family_lockct);
spin_unlock_wait(&net_family_lock);
}
static __inline__ void net_family_read_unlock(void)
{
atomic_dec(&net_family_lockct);
}
So there are two ways to avoid the bug:
1. As proposed by Frederik, use sk_alloc with GFP_ATOMIC or
2. use net_family_{read|writ}_{lock|unlock} in af_bluetooth.c.
I wonder which is better.
Masatake YAMATO
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]