我正在为硬件电话模块定制dahdi驱动程序。此模块通过usb（用户空间libusb d2x ftdi驱动程序）连接到pc。所以驱动程序分为两部分：内核模式dahdi驱动程序和用户空间服务。
用户空间守护进程检测usb卡，并要求内核dahdi驱动程序使用netlink添加/删除dahdi跨度。添加新的span it通信设备后，发送/接收音频和命令。
我通过一个电话卡（热插拔设备、拨号、通话、热删除，没有任何错误）成功地测试了它，启动了多个卡测试，并在netlink_broadcast（）调用中获得了“BUG:scheduling while atomic”：
[ 5322.363190] [<ffffffffae709113>] __schedule_bug+0x64/0x72
[ 5322.363196] [<ffffffffae713fdb>] __schedule+0x9fb/0xa20
[ 5322.363202] [<ffffffffae0cc1d6>] __cond_resched+0x26/0x30
[ 5322.363205] [<ffffffffae7142ca>] _cond_resched+0x3a/0x50
[ 5322.363209] [<ffffffffae1f7a35>] kmem_cache_alloc+0x35/0x1f0
[ 5322.363216] [<ffffffffae5d7ad9>] ? skb_clone+0x49/0xb0
[ 5322.363218] [<ffffffffae5d7ad9>] skb_clone+0x49/0xb0
[ 5322.363225] [<ffffffffae623ca1>] netlink_broadcast_filtered+0x331/0x3e0
[ 5322.363227] [<ffffffffae623d6d>] netlink_broadcast+0x1d/0x20
[ 5322.363231] [<ffffffffc0c113ca>] nl_send_cmd+0x15a/0x260 [mydev]
[ 5322.363234] [<ffffffffc0c11531>] mydev_hooksig+0x61/0x80 [mydev]
[ 5322.363240] [<ffffffffc082ecdb>] dahdi_rbs_sethook+0x9b/0x220 [dahdi]
[ 5322.363244] [<ffffffffc0833566>] _dahdi_transmit+0x4c6/0x5b0 [dahdi]
[ 5322.363248] [<ffffffffc08368f5>] ? _dahdi_receive+0x235/0x3a0 [dahdi]
[ 5322.363250] [<ffffffffc0c10436>] ? queue_write+0x66/0xd0 [mydev]
[ 5322.363252] [<ffffffffc0c10963>] mydev_tick+0x1e3/0x2b0 [mydev]
[ 5322.363256] [<ffffffffc08365fe>] _process_masterspan+0x5be/0x680 [dahdi]
[ 5322.363259] [<ffffffffc0836a1c>] _dahdi_receive+0x35c/0x3a0 [dahdi]
[ 5322.363263] [<ffffffffc07b28b7>] g4_interrupt+0x3b7/0xc7b [opvxg4xx]
[ 5322.363266] [<ffffffffc08332da>] ? _dahdi_transmit+0x23a/0x5b0 [dahdi]
[ 5322.363270] [<ffffffffc08368f5>] ? _dahdi_receive+0x235/0x3a0 [dahdi]
[ 5322.363274] [<ffffffffae141284>] __handle_irq_event_percpu+0x44/0x1c0
[ 5322.363276] [<ffffffffae141432>] handle_irq_event_percpu+0x32/0x80
[ 5322.363277] [<ffffffffae1414bc>] handle_irq_event+0x3c/0x60
[ 5322.363281] [<ffffffffae144ab9>] handle_fasteoi_irq+0x59/0x110
[ 5322.363285] [<ffffffffae02d504>] handle_irq+0xe4/0x1a0
[ 5322.363290] [<ffffffffae1029fc>] ? tick_check_idle+0x8c/0xd0
内核驱动程序结构非常简单。它用calbacks列表注册dahdi设备：
static const struct dahdi_span_ops mydev_span_ops = {
.owner = THIS_MODULE,
.hooksig = mydev_hooksig,
.spanconfig = mydev_spanconfig,
.chanconfig = mydev_chanconfig,
.startup = mydev_startup,
.shutdown = mydev_shutdown,
.open = mydev_open,
.close = mydev_close,
.ioctl = mydev_ioctl,
.sync_tick = mydev_tick,
};
hooksig操作是在handoff/hangon上从dahdi模块调用的，它只向用户空间守护进程发送netlink消息：
static int mydev_hooksig(struct dahdi_chan *chan, enum dahdi_txsig txsig)
{
struct mydevp *wc = NULL;
int reg=0;
if (chan == NULL) return 0;
wc = chan->pvt;
switch(txsig) {
case DAHDI_TXSIG_START:
case DAHDI_TXSIG_OFFHOOK:
nl_send_cmd(chan->chanpos, wc->serial, "off", OP_OFFHOOK);
break;
case DAHDI_TXSIG_ONHOOK:
nl_send_cmd(chan->chanpos, wc->serial, "on", OP_ONHOOK);
break;
default:
printk(KERN_NOTICE "dahdi_mydev: Can't set tx state to unknown %d\n", txsig);
}
printk(KERN_DEBUG "dahdi_mydev: Setting hook state to %d (%02x)\n", txsig, reg);
return 0;
}
dahdi_rbs_sethook（）->mydev_hooksig（）函数在dahdi模块中的多个位置调用，并且总是用spin_lock_irqsave（）/spin_unlock_irqrestore（）包装，但我不明白为什么只有一张卡连接时问题就消失了。
所以我就是不知道如何从这个回调正确地发送netlink消息。netlink_广播是否有非睡眠变化？
add1:尝试旋转解锁发送旋转锁定-没有帮助。
add2:这是我的nl_send_cmd（）函数的代码
int nl_send_cmd(int chan, char *serial, char *dial, int op) {
int rc = 0;
struct sk_buff *skb;
void *msg_head;
pr_debug("dahdi_mydev: trying to sent dial string to userspace\n");
skb = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
if (!skb) {
pr_err("dahdi_mydev: genlmsg_new() failed.\n");
return -ENOMEM;
}
msg_head = genlmsg_put(skb, 0, 0, &span_gnl_family, 0, SPAN_DIAL_CMD);
if (!msg_head) {
pr_err("dahdi_mydev: genlmsg_put() failed.\n");
kfree_skb(skb);
return -ENOMEM;
}
rc = nla_put_string(skb, ATTR1_STRING, serial);
if (rc) {
pr_err("dahdi_mydev: nla_put_string() failed for serial: %d\n", rc);
kfree_skb(skb);
return -ENOMEM;
}
rc = nla_put_string(skb, ATTR4_STRING, dial);
if (rc) {
pr_err("dahdi_mydev: nla_put_string() failed for dial: %d\n", rc);
kfree_skb(skb);
return -ENOMEM;
}
rc = nla_put_u32(skb, ATTR2_SINT32, chan);
if (rc) {
pr_err("dahdi_mydev: nla_put_sint32() failed for dial: %d\n", rc);
kfree_skb(skb);
return -ENOMEM;
}
rc = nla_put_u32(skb, ATTR5_SINT32, op);
if (rc) {
pr_err("dahdi_mydev: nla_put_sint32() failed for dial: %d\n", rc);
kfree_skb(skb);
return -ENOMEM;
}
genlmsg_end(skb, msg_head);
rc = genlmsg_multicast(&span_gnl_family, skb, 0, 0, GFP_KERNEL);
if (rc) {
pr_info("dahdi_mydev: Dial message didn't sent - no listeners ?\n");
return -ENOTCONN;
}
pr_debug("dahdi_mydev: NL msg for %s sent with '%s' op %d\n", serial, dial, op);
return 0;
}
最佳答案
好 啊。我花了一些时间找到了答案。解决方案是用genlmsg_new（）和genlmsg_multicast（）调用中的GFP_ATOMIC替换GFP_KERNEL，因为生成的netlink_broadcast（）函数具有以下特性：
if (info.delivered) {
if (info.congested && gfpflags_allow_blocking(allocation))
yield();
return 0;
}
我认为在单usb卡模式下，拥塞标志是错误的，根本没有睡眠。在连接另一个卡之后，出现了大量的netlink消息->拥塞标志上升+分配标志=GFP_KERNEL->sleep inside locked section。
关于linux - 调用netlink_broadcast()会导致原子级的BUG调度，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/57139103/