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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.