Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 21 Jul 2020 13:58:47 -0700 | Subject | Re: [PATCH 04/18] csum_and_copy_..._user(): pass 0xffffffff instead of 0 as initial sum |
| |
On Tue, Jul 21, 2020 at 1:55 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > This seems dangerous to me. > > Maybe some implementation depends on the fact that they actually do > the csum 16 bits at a time, and never see an overflow in "int", > because they keep folding things. > > You now break that assumption, and give it an initial value that the > csum code itself would never generate, and wouldn't handle right. > > But I didn't check. Maybe we don't have anything that stupid in the kernel.
I take it back. The very first place I looked seemed to do exactly that.
See "do_csum()" in the kernel. It doesn't handle carry for any of the usual cases, exactly because it knows it doesn't need to.
Ok, so do_csum() doesn't take that initial value, but it's very much an example of the kind of algorithm I was thinking of: it does do things 32 bits at a time and handles the carry bit in that inner loop, but internally it knows that the val;ues are limited in other places, and doesn't need to handle carry everywhere.
Linus
| |