• 状态 TI Thinks Resolved
  • 已锁定 已锁定
  • 个回复 3 个回复
  • 答案 1 答案
  • 名订阅用户 14 名订阅用户
  • 次查看 653 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: the function K3 rproc use mailbox to send data seems has a bug

Jukuo zhang
Part Number: TDA4VM

HI, 

I found a bug in the linux kernel code with rproc driver in ti_k3_dsp_remoteproc.c/ti_k3_r5_remoteproc.c when these drivers use mailbox to send messages.

I doubte why you didn't  have this problem.

static void k3_dsp_rproc_kick(struct rproc *rproc, int vqid)
{
    struct k3_dsp_rproc *kproc = rproc->priv;
    struct device *dev = rproc->dev.parent;
    mbox_msg_t msg = (mbox_msg_t)vqid;
    int ret;

    /* send the index of the triggered virtqueue in the mailbox payload */
    ret = mbox_send_message(kproc->mbox, (void *)msg);
    if (ret < 0)
        dev_err(dev, "failed to send mailbox message, status = %d\n",
            ret);
}
About the code with red color,  the "msg" val is a pointer with the mailbox msg buffer.
When we send the msg , we put the pointer into the mailbox client's send buffer queue.
At this time, if we  config the mailbox send with NON-BLOCK mode, just like your code:
client->rx_callback = k3_dsp_rproc_mbox_callback;
    client->tx_block = false;
then something happen, after the mbox_send_message function call return, buf the buf still in the mailbox clent's send buf and
not send out, then becasue the "msg" val is a local val, it will be free after the kick function finish. But the buf is still in the 
mailbox clent's sendbuf, but this buf is freed and not right. so trample happen.
AS the log show, we want to use mailbox to send VQID, first data send is OK, the vqid is 1, then error get ,the vqid is a big data. 0x95178c10.
i used the arm pl320 mailbox , my code in rproc driver to use the mailbox is :
static void xx_rpu_rproc_kick(struct rproc *rproc, int vqid)
{
    struct xx_rpu_rproc *kproc = rproc->priv;
    struct device *dev = rproc->dev.parent;
    uint32_t msg[7] = {0};
    int ret;

    msg[0] = vqid;

    /* send the index of the triggered virtqueue in the mailbox payload */
    ret = mbox_send_message(kproc->mbox[vqid],
                                 (void *)msg);
    if (ret < 0)
        dev_err(dev, "failed to send mailbox message, status = %d\n", ret);
}
  • 0

    第一次在TI的社区上发贴子，不知道有没人回复，我用中文也描述一遍。

    不知道有没有人用过TI 的TDA4的板子，这个板子会用rpmsg + rproc做核间通信，会用mailbox发消息。

    在TI 的K3_XX_remoteproc.c系列的驱动中使用mailbox 貌似有一个bug，就像正文中描述的那样，rproc的kick函数要将mailbox消息发往对端，发送侧申请一个msg buffer作为发送缓冲，可是这个buffer是个临时变量，如果我们在申请mailbox client时设置的发送属性为non-block，则存在问题：mbox_send_message调用后将消息缓冲放在mailbox client的自己的发送缓冲（看代码，是一个深度为20的缓冲哦）后立马返回，因为是局部变量，此时的“msg"这个kick函数中申请的变量将会释放，又因为是异步的，这时候kick提交到mailbox client中待发送的任务可能还没发送，这时候如果重新发送，则用的就是一个已经释放的局部变量，这不就踩踏了吗？

    大家看看有没有遇到我类似的问题。

    不过有一个差异，我的mailbox是ARM的，mailbox的消息的data长度是7字节，所以我用的是msg[7]的数组. TI原生代码用的一个32位，用的是一个

    typedef unsigned long uintptr_t，不知是否是这里的差异，所以TI一直没问题。
  • 0 回复 Jukuo zhang
    TI__Guru**** 357097 points

    抱歉回复晚了，请看下面我们e2e工程师的回复。

    There are no issues with the TI K3 R5F/DSP remoteproc drivers and their usage of Mailboxes with the OMAP Mailbox driver. The Mailbox subsystem API semantics use a pointer, and this gets translated/deferenced properly by the corresponding platform mailbox driver. So, the behavior is dependent on the Mailbox platform driver and it's clients.

    The OMAP Mailbox driver is optimized to directly use the pointer value as the payload. This eliminates all the life-cycle management of having to use pointers, and their transfer of ownership between the Mailbox client and the Mailbox driver.