On 15.04.21 09:54, Philippe Gerum wrote: > > Jan Kiszka <jan.kis...@siemens.com> writes: > >> On 15.04.21 09:21, Philippe Gerum wrote: >>> >>> Jan Kiszka <jan.kis...@siemens.com> writes: >>> >>>> On 27.03.21 11:19, Philippe Gerum wrote: >>>>> From: Philippe Gerum <r...@xenomai.org> >>>>> >>>>> Since v5.9-rc1, csum_partial_copy_nocheck() forces a zero seed as its >>>>> last argument to csum_partial(). According to #cc44c17baf7f3, passing >>>>> a non-zero value would not even yield the proper result on some >>>>> architectures. >>>>> >>>>> Nevertheless, the current ICMP code does expect a non-zero csum seed >>>>> to be used in the next computation, so let's wrap net_csum_copy() to >>>>> csum_partial_copy_nocheck() for pre-5.9 kernels, and open code it for >>>>> later kernels so that we still feed csum_partial() with the user-given >>>>> csum. We still expect the x86, ARM and arm64 implementations of >>>>> csum_partial() to do the right thing. >>>>> >>>> >>>> If that issue only affects the ICMP code path, why not only changing >>>> that, leaving rtskb_copy_and_csum_bits with the benefit of doing copy >>>> and csum in one step? >>>> >>> >>> As a result of #cc44c17baf7f3, I see no common helper available from the >>> kernel folding the copy and checksum operations anymore, so I see no way >>> to keep rtskb_copy_and_csum_bits() as is. Did you find an all-in-one >>> replacement for csum_partial_copy_nocheck() which would allow a csum >>> value to be fed in? >>> >> >> rtskb_copy_and_csum_dev does not need that. >> > > You made rtskb_copy_and_csum_bits() part of the exported API. So how do > you want to deal with this? >
That is an internal API, so we don't care. But even if we converted rtskb_copy_and_csum_bits to work as it used to (with a csum != 0), there would be not reason to make rtskb_copy_and_csum_dev pay that price. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
