+CC Olivier Matz <olivier.m...@6wind.com>, Network Headers maintainer
> From: Morten Brørup <m...@smartsharesystems.com> > Sent: den 15 juni 2022 16:41 > > > From: bugzi...@dpdk.org [mailto:bugzi...@dpdk.org] > > Sent: Wednesday, 15 June 2022 09.16 > > > > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- > 45444 > > 5555731-2e92ae6bf759c0c5&q=1&e=b3fc70af-5d37-4ffb-b34d- > 9a51927f5f6d&u= > > https%3A%2F%2Fbugs.dpdk.org%2Fshow_bug.cgi%3Fid%3D1035 > > > > Bug ID: 1035 > > Summary: __rte_raw_cksum() crash with misaligned pointer > > Product: DPDK > > Version: 21.11 > > Hardware: All > > OS: All > > Status: UNCONFIRMED > > Severity: normal > > Priority: Normal > > Component: ethdev > > Assignee: dev@dpdk.org > > Reporter: emil.b...@ericsson.com > > Target Milestone: --- > > > > See rte_raw_cksum() in rte_ip.h, which is part of the public API. See > > also the subfunction __rte_raw_cksum(). > > > > _rte_raw_cksum assumes that the buffer over which the checksum is > > calculated is an even address (divisible by two). See for example > this > > stack overflow > > post: > > https://stackoverflow.com/questions/46790550/c-undefined-behavior- > > strict-aliasing-rule-or-incorrect-alignment > > > > The post explains that there is undefined behavior in C11 when > > "conversion between two pointer types produces a result that is > > incorrectly aligned". When the buf argument starts on an odd address > > we thus have undefined behavior, since a pointer is cast from void* > to > > uint16_t*. > > > > In most cases (at least on x86) that isn't a problem, but with higher > > optimization levels it may break due to vector instructions. This new > > function seems to be easier to optimize by the compiler, resulting in > > a crash when the buf argument is odd. Please note that the undefined > > behavior is present in earlier versions of dpdk as well. > > > > Now you're probably thinking: "Just align your buffers". The problem > > is that we have a packet buffer which is aligned. The checksum is > > calculated on a subset of that aligned packet buffer, and that > > sometimes lies on odd addresses. > > > > The question remains if this is an issue with dpdk or not. > > I can imagine other systems doing what you describe too. So it needs to > be addressed. > > Off the top of my head, an easy fix would be updating __rte_raw_cksum() > like this: > > static inline uint32_t > __rte_raw_cksum(const void *buf, size_t len, uint32_t sum) { > if (likely((buf & 1) == 0)) { > /* The buffer is 16 bit aligned. */ > Keep the existing, optimized implementation here. > } else { > /* The buffer is not 16 bit aligned. */ > Add a new odd-buf tolerant implementation here. > } > } > > However, I'm not sure that it covers your scenario! > > The checksum is 16 bit wide, so if you calculate the checksum of e.g. 4 > bytes of memory starting at offset 1 in a 6 byte packet buffer, the > memory block can be treated as either 4 or 6 bytes relative to the data > covered by the checksum, i.e.: > > A: XX [01 02] [03 04] XX --> cksum = [04 06] > > B: [XX 01] [02 03] [04 XX] --> cksum = [06 04] > > Which one do you need? > > Perhaps an additional function is required to support your use case, > and the documentation for rte_raw_cksum() and __rte_raw_cksum() needs > to reflect that the buffer must be 16 bit aligned. > > Or the rte_raw_cksum() function can be modified to support an odd > buffer pointer as outlined above, with documentation added about > alignment of the running checksum. > -----Original Message----- > From: Emil Berg [mailto:emil.b...@ericsson.com] > Sent: Thursday, 16 June 2022 07.45 > > Hi! > > We want the B option, i.e. the 6 bytes option. Perhaps adding alignment > detection to __rte_raw_cksum() is a good idea. With option B, the invariant that the running checksum is being calculated on a 16 bit aligned packet buffer remains unchanged. So I think that support for option B is appropriate to add to __rte_raw_cksum(), rather than adding a separate function. > > A minor comment but I think buf & 1 won't work since buf isn't an > integral type, but something along that way. > > I'm starting to think about an efficient way to do this. > > Thank you! Sounds good. Please CC me on your patch, when ready for review. :-)
