[LEDE-DEV] [UBUS] [PATCH] Issue of msgbuf_data_len in ubus_context

[Alexandru Ardelean]

On Sun, Jun 19, 2016 at 7:21 AM, Wang Linetkux <chinawrj at gmail.com> wrote:
> Sorry, forgot to paste the patch in the email for easy reading.
>
> ---
>
>  libubus-io.c | 1 +
>
>  1 file changed, 1 insertion(+)
>
>
>
> diff --git a/libubus-io.c b/libubus-io.c
>
> index 9320bf3..0582ff7 100644
>
> --- a/libubus-io.c
>
> +++ b/libubus-io.c
>
> @@ -259,6 +259,7 @@ static bool alloc_msg_buf(struct ubus_context
> *ctx, int len)
>
>                 return false;
>
>
>
>         ctx->msgbuf.data = ptr;
>
> +       ctx->msgbuf_data_len = len;
>
>         return true;
>
>  }
>
>
>
>
>
>
>
> 2016-06-19 12:16 GMT+08:00 Wang Linetkux <chinawrj at gmail.com>:
>> Hi, Guys
>>   Since I cannot find other places to send this patch, so I send it
>> here, and hope it does not bother you.
>>   "alloc_msg_buf" function in "ubus/libubus-io.c" has the feature that
>> expand or shrink msg buffer when necessary. But I have noticed that
>> "msgbuf_data_len" has been properly set after msg buffer is expanded,
>> and it still stays with its origin value. I have generated one patch
>> for this bug. Feel free to talk with me, just in case I am wrong.
>>
>> ubus repo on lede:
>> https://git.lede-project.org/?p=project/ubus.git;a=summary
>>
>>
>> Rujun
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

@Felix or @John: can you please check this patch ?
Wang has a point here.
"ctx->msgbuf_data_len" is not adjusted after init, and should be, in
case of realloc.

I don't think this causes a leak.
It just makes the buffer size reduction logic useless.
So, if the max ubus msg is 1 MB, then the buffer size will remain 1 MB
until reboot/restart of the process.

@Wang: the way to send patches is via the git send-email command.
so in this case:
    git send-email --to=lede-dev at lists.infraread.org
0001-Fix-the-length-of-msg-buffer-after-realloc.patch

Thanks
Alex