Sean Anderson wrote:
On 9/10/24 13:42, Willem de Bruijn wrote:
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.
Which is the subject of my second bullet.
If not adding a new test, detect in csum and fail anytime padding is detected (i.e., not only non-zero)?
As noted below, this is only a problem if we leak kernel memory in the padding. Otherwise, any kind of padding at all is completely standard conformant.
Ack. I actually was not clear on that.