David Howells wrote: > David Howells <dhowells@xxxxxxxxxx> wrote: > > > I think the attached is probably an equivalent cleaned up reproducer. Note > > that if the length given to sendfile() is less than 65536, it fails with > > EINVAL before it gets into __ip6_append_data(). > > Actually, it only fails with EINVAL if the size is not a multiple of the block > size of the source file because it's open O_DIRECT so, say, 65536-512 is fine > (and works). > > But thinking more on this further, is this even a bug in my code, I wonder? > The length passed is 65536 - but a UDP packet can't carry that, so it > shouldn't it have errored out before getting that far? (which is what it > seems to do when I try it). > > I don't see how we get past the length check in ip6_append_data() with the > reproducer we're given unless the MTU is somewhat bigger than 65536 (is that > even possible?) An ipv6 packet can carry 64KB of payload, so maxnonfragsize of 65535 + 40 sounds correct. But payload length passed of 65536 is not (ignoring ipv6 jumbograms). So that should probably trigger an EINVAL -- if that is indeed what the repro does.
