Re: [tipc-discussion] [PATCH v5 net-next 4/5] tipc: use char buffer instead of print_buf

[Erik H. <eri...@er...>]

>>
>> Adding a check:
>> if (*(rep_tlv_buf->data + ULTRA_STRING_MAX_LEN) != '\0')
>> before adding the truncated message should solve this.
>
> And then there is another boundary case, when the remaining
> part of the string would have fit into the tailroom reserved
> for the "<truncated>"  string.
> I just realized this is getting a little messy...
>
> A cleaner solution would be to just allocate the
> ordered ULTRA_MAX_STRING_LEN bytes without any tailroom
> like we do now.
Yup, current code does this, i never changed it.

> Then, in the new test (assuming use of tipc_printf syntax),
> if (rep_tlv_buf->len == ULTRA_MAX_STRING_LEN) AND
> (rep_tlv_buf->data[ULTRA_MAX_STRING_LEN] != 0) THEN
> we have overflow, so we just  go back in the buffer and
> overwrite the last 12 bytes with "<truncated>".
> If (rep_tlv_buf->len>  ULTRA_MAX_STRING_LEN) then something
> is wrong and we should print out an error.
> No potential false positives any more and simpler code.
The length check have been updated as you suggested.
If it for some reason should be longer than ULTRA_MAX_STRING_LEN,
the entire reply is free'd, and an error message is returned instead.

>>
>> True, it won't actually write data outside the allocated space if the
>> second parameter is<0, but it will print out kernel WARN when it happens.
>
> Ok, I admit defeat for now. Let's see if Paul or people
> on netdev may have any better suggestions.
> At least we should rename tipc_printf to tipc_snprintf
> to emphasize what we want to do with this function.
>
>
> So let's see if the next version will be the final one ;-)
This was more complicated than i thought at first.... :/


//E