Re: [PATCH] release oob skb when received in-band and fix setsockopt ret
Philippe Gerum <[email protected]>
| Newsgroups | dev.linux.lists.xenomai |
|---|---|
| Message-ID | <[email protected]> |
Brandon Ho <[email protected]> writes: >> __consume_stateless_skb() should never be called from the oob stage, or >> receive any oob-managed skb, which makes the redirection via >> skb_release_oob() pointless. Did you identify any code path which would >> hand over oob skbs to skb_consume_udp() for release? > > The code path I found was udp_recvmsg->skb_consume_udp->__consume_stateless_skb — I would run into ENOMEM without the > skb_release_oob. > Ok, I better understand the issue now. You likely have an oob-enabled driver receiving packets, in which case some skbs left by the evl core to the regular netstack for handling may indeed be pulled from oob pools and never released back. So your patch does make sense. >> We don't need this, all following code paths either assign this variable >> prior to using it, or simply return an immediate value. The original >> code does not initialize this variable on entry, which confirms the >> latter. > > Oops sorry I meant to make the patch in sk_setsockopt — that one returns ret at the end. I was getting ENOIOCTLCMD when calling > setsockopt for SO_REUSEADDR. > Ok, got it. You must be working with the v6.1.y-cip kernel series, right? v6.12.y-cip, v6.18 and v7.0 don't have this issue (anymore). Word of caution: v6.1.y-cip+{dovetail/evl} is semi-EOL, some kind zombie state. v6.12.y-cip is the current SLTS for us, you may want to upgrade if possible. >> PS: on a general note, please split patches addressing unrelated topics. > > Sorry I'll make new patches > Np, you are welcome. PS: mentioning the target kernel release for those patches may help. -- Philippe.