Tool/software:
Hello,
I am using the ti-rpmsg-char v0.6.7 library in my application.
Normally it works as expected, but if the generated endpoint device name length reaches 31 characters, the application terminates with an error.
At that time, /dev/rpmsg* devices also keep increasing.
Here is an example from the statusd application (eptdev_name = "rpmsg-char-fpgaconfig-9-1364841", length 31):
statusd[1364841]: 32 bytes read from /sys/devices/platform/bus@f4000/bus@f4000:bus@4000000/5000000.m4fss/remoteproc/remoteproc0/rproc-virtio.0.auto/virtio0/virtio0.rpmsg_ctrl.0.0/rpmsg/rpmsg_ctrl0/rpmsg16/name are larger than size 32
Application code excerpt:
int rpmsg_open(void){
char eptdev_name[64] = { 0 };
int flags = 0;
sprintf(eptdev_name, "rpmsg-char-fpgaconfig-%d-%d", RPROC_ID, getpid());
rcdev = rpmsg_char_open(RPROC_ID, NULL, RPMSG_ADDR_ANY, FPGACONFIG_ENDPT,
eptdev_name, flags);
if (!rcdev) {
perror("Can't create FPGA config endpoint device");
return -EPERM;
}
printf("Created FPGA config endpt device %s, fd = %d port = %d\n",
eptdev_name, rcdev->fd, rcdev->endpt);
return 0;
}
From the library source it looks like:
-
"_rpmsg_char_create_eptdev"succeeds. -
"_rpmsg_char_open_eptdev"calls "_rpmsg_char_get_rpmsg_id". -
Inside "
_rpmsg_char_get_rpmsg_id", "file_read_string()"reads more than 32 bytes (including newline), which causes an error. -
"_rpmsg_char_destroy_eptdev"is never called, leaving/dev/rpmsg*devices behind.
Relevant checks:
if (!eptdev_name || strlen(eptdev_name) >= 32) {
fprintf(stderr, "%s: invalid eptdev_name\n", __func__);
goto unlock;
}
So when eptdev_name reaches exactly 31 characters, the function passes the length check but later fails because the string plus newline exceeds the buffer limit.
Questions:
-
Is this a known limitation in
ti-rpmsg-char? -
Should endpoint naming always be restricted to ≤30 characters to avoid this case?
-
Or should "
file_read_string()"and "_rpmsg_char_get_rpmsg_id()"handle trimming/longer names more gracefully?
Any guidance on the expected behavior and recommended fix would be appreciated.
Thanks,
Kazunori
