On Wed, Sep 21, 2022 at 1:48 AM shaozhengchao <shaozhengchao@xxxxxxxxxx> wrote: > > > > On 2022/9/20 22:42, Lorenz Bauer wrote: > > On Mon, 19 Sep 2022, at 11:55, shaozhengchao wrote: > >> Sorry for the delay. I'm busy testing the TC module recently. I'm very > >> sorry for the user-space breakage. > >> > >> The root cause of this problem is that eth_type_trans() is called when > >> the protocol type of the SKB is parsed. The len value of the SKB is > >> reduced to 0. If the user mode requires that the forwarding succeed, or > >> if the MAC header is added again after the MAC header is subtracted, > >> is this appropriate? > > > > We don't require forwarding to succeed with a 14 byte input buffer. We also don't look at the MAC header. > > > > I think refusing to forward 0 length packets would be OK. Not 100% certain I understood you correctly, let me know if this helps. > > > > Best > > Lorenz > Hi Lorenz > Sorry. But how does the rejection of the 0 length affect the > test case? Is the return value abnormal, send packet failure or some > others? Sorry for the late reply, I'm still traveling. What we want to avoid is creating invalid skbs via prog_test_run. We can reject <14 byte packets with ENIVAL, but that might break some of the existing apps (as Lorenz reported). So it seems like a safer alternative would be to accept those packets, but just append missing bytes in the kernel to create the valid packets? Padding with zeros seems fine? > Zhengchao Shao
