Sean Anderson wrote: > On 9/9/24 21:01, Willem de Bruijn wrote: > > Jakub Kicinski wrote: > >> On Mon, 09 Sep 2024 13:26:42 -0400 Willem de Bruijn wrote: > >> > > This seems to be a bug in the driver. > >> > > > >> > > A call to skb_put_padto(skb, ETH_ZLEN) should be added. > >> > > >> > In which case this test detecting it may be nice to have, for lack of > >> > a more targeted test. > >> > >> IIUC we're basically saying that we don't need to trim because pad > >> should be 0? In that case maybe let's keep the patch but add a check > >> on top which scans the pad for non-zero bytes, and print an informative > >> warning? > > > > Data arriving with padding probably deserves a separate test. > > > > We can use this csum test as stand-in, I suppose. > > > > Is it safe to assume that all padding is wrong on ingress, not just > > non-zero padding. The ip stack itself treats it as benign and trims > > the trailing bytes silently. > > > > I do know of legitimate cases of trailer data lifting along. > > Ideally we would test that > > - Ingress padding is ignored. I think the goal of a hardware padding test is to detect when padding leaks onto the wire. If not adding a new test, detect in csum and fail anytime padding is detected (i.e., not only non-zero)? > - Egress padding does not leak past the buffer. The easiest way to > handle this would be to check that it is constant (e.g. all the > padding uses the same value), but this could have false-positives for > e.g. timestamps. > > --Sean
