memcpy uses value of mls (mpls label stack) instead of address
Hi Team, I have tried to use mpls_label_stack to keep some meta data for each route. But the values of meta data were not copied correctly. I just found the below code in "rt_next_hop_update_rte" function in rt-table.c memcpy(*mls.**stack*, &a->nh.label[a->nh.labels - mls.len], mls.len * sizeof (u32)); Here the "mls.stack" is passed directly instead of its address in memcpy. Kindly let me know your thoughts on this. Thanks, Ramanathan
Hi Team, I am resending the line of code again since the last mail was not showing up correctly. memcpy(mls.stac*k*, &a->nh.label[a->nh.labels - mls.len], mls.len * sizeof(u32)); Thanks. On Fri, 12 Apr 2024 at 09:58, Ramanathan Selvamani <ramana.it05@gmail.com> wrote:
Hi Team,
I have tried to use mpls_label_stack to keep some meta data for each route. But the values of meta data were not copied correctly.
I just found the below code in "rt_next_hop_update_rte" function in rt-table.c
memcpy(*mls.**stack*, &a->nh.label[a->nh.labels - mls.len], mls.len * sizeof(u32));
Here the "mls.stack" is passed directly instead of its address in memcpy.
Kindly let me know your thoughts on this.
Thanks, Ramanathan
Hello Ramanathan, On Fri, Apr 12, 2024 at 10:09:34AM +0530, Ramanathan Selvamani wrote:
[...]
memcpy(mls.stack, &a->nh.label[a->nh.labels - mls.len], mls.len * sizeof(u32));
Here the "mls.stack" is passed directly instead of its address in memcpy.
- `a->nh.label` is of type `u32 []`, thus `&a->nh.label[foo]` is of type `u32 *`. - `mls.stack` is of type `u32 []`, and even though we definitely *could* write `&mls.stack[0]`, it's not worth the bytes, and it means the same The code is correct, works properly and is regularly tested.
I have tried to use mpls_label_stack to keep some meta data for each route. But the values of meta data were not copied correctly.
You should *not* do it in *any situation*, unless these are MPLS labels. And if MPLS labels are behaving weirdly, please report a bug (here), including how to reproduce it. For keeping some custom metadata about routes, use custom attributes instead. Also if you are modifying BIRD 2 source code, please be aware that there is BIRD 3 upcoming with substantial modifications of the core, allowing for multithreaded execution and better extendability. Notably, the placement of MPLS label stack has changed there. That development is mostly happening in the branch `thread-next`, and even though there has been a significant delay since BIRD 3.0alpha2, the development is pretty much active and we hope to release alpha3 soon. Last but not lest, regarding your modifications, feel free to send your changes upstream, we'll consider including them. How to do it? - you can just send patches to the list - you can publish your forked repo and send just its URL and the commit hash to the list Or, if you can't publish your changes, I very much recommend you to consider having a support contract to ensure that we either don't break or let you know advance about changes in our internal API. Ask me off-list for more information. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (2)
-
Maria Matejka -
Ramanathan Selvamani