[QUESTION] BPF_SK_SKB_STREAM_PARSER cannot observe strparser orig_offset?

[QUESTION] BPF_SK_SKB_STREAM_PARSER cannot observe strparser orig_offset?

[Cristian Morales Vega (cmorve)]

I am trying to use BPF_SK_SKB_STREAM_VERDICT in an old kernel (I don't have control over the version), so I need to also use BPF_SK_SKB_STREAM_PARSER. I though to just do "return skb->len;" in it, as a no-op, since I don't really have an use for the parser.

So far so good. But I can see that, from time to time, __strp_recv() receives a non-zero orig_offset as "first skb" (i.e. strp->skb_head is null). In such a case, I should not be returning skb->len but "skb->len - orig_offset" (i.e. orig_len), right? Otherwise I would enter

		extra = (ssize_t)(stm->accum_len + cand_len) -
			stm->strp.full_len;

		if (extra < 0) {
			/* Message not complete yet. */

But AFAICT BPF_SK_SKB_STREAM_PARSER doesn't have access to that offset. It seems it had it until e0dc3b93bd7bcff8c3813d1df43e0908499c7cf0 (which was backported), but not any more?

Is my understanding correct? If not, what am I missing? And, if yes, there is any solution?

Re: [QUESTION] BPF_SK_SKB_STREAM_PARSER cannot observe strparser orig_offset?

[Jiayuan Chen]

On 5/11/26 10:49 PM, Cristian Morales Vega (cmorve) wrote:
> I am trying to use BPF_SK_SKB_STREAM_VERDICT in an old kernel (I don't have control over the version), so I need to also use BPF_SK_SKB_STREAM_PARSER. I though to just do "return skb->len;" in it, as a no-op, since I don't really have an use for the parser.

Since v5.18 BPF_SK_SKB_STREAM_VERDICT can be used without 
BPF_SK_SKB_STREAM_PARSER.

Which kernel version you use now?

>
> So far so good. But I can see that, from time to time, __strp_recv() receives a non-zero orig_offset as "first skb" (i.e. strp->skb_head is null). In such a case, I should not be returning skb->len but "skb->len - orig_offset" (i.e. orig_len), right? Otherwise I would enter
>
> 		extra = (ssize_t)(stm->accum_len + cand_len) -
> 			stm->strp.full_len;
>
> 		if (extra < 0) {
> 			/* Message not complete yet. */
>
> But AFAICT BPF_SK_SKB_STREAM_PARSER doesn't have access to that offset. It seems it had it until e0dc3b93bd7bcff8c3813d1df43e0908499c7cf0 (which was backported), but not any more?
>
> Is my understanding correct? If not, what am I missing? And, if yes, there is any solution?


If you just return skb->len only in your parser , the 'issue' should not 
happen.

Re: [QUESTION] BPF_SK_SKB_STREAM_PARSER cannot observe strparser orig_offset?

[Cristian Morales Vega (cmorve)]

> > On 5/11/26 10:49 PM, Cristian Morales Vega (cmorve) wrote:
> > I am trying to use BPF_SK_SKB_STREAM_VERDICT in an old kernel (I don't have control over the version), so I need to also use BPF_SK_SKB_STREAM_PARSER. I though to just do "return skb->len;" in it, as a no-op, since I don't really have an use for the parser.
> 
> Since v5.18 BPF_SK_SKB_STREAM_VERDICT can be used without
> BPF_SK_SKB_STREAM_PARSER.
> 
> Which kernel version you use now?

I think it's since 5.10? But I have to make it run on a big range of kernel versions, right now I'm looking at a 5.4.213 system.


> >
> > So far so good. But I can see that, from time to time, __strp_recv() receives a non-zero orig_offset as "first skb" (i.e. strp->skb_head is null). In such a case, I should not be returning skb->len but "skb->len - orig_offset" (i.e. orig_len), right? Otherwise I would enter
> >
> >                extra = (ssize_t)(stm->accum_len + cand_len) -
> >                        stm->strp.full_len;
> >
> >                if (extra < 0) {
> >                        /* Message not complete yet. */
> >
> > But AFAICT BPF_SK_SKB_STREAM_PARSER doesn't have access to that offset. It seems it had it until e0dc3b93bd7bcff8c3813d1df43e0908499c7cf0 (which was backported), but not any more?
> >
> Is my understanding correct? If not, what am I missing? And, if yes, there is any solution?
> 
> 
> If you just return skb->len only in your parser , the 'issue' should not
> happen.

But if the parser returns skb->len, even in a modern system (in theory, I'm struggling to reproduce getting orig_offset != 0 in any system I can properly debug). Let's say orig_skb->len is 1500, orig_offset 1000 and orig_len 500.
- cand_len will be set to 500 here ->https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L186
- len will be set to 1500 here -> https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L221
- stm->strp.full_len will be set to 1500 here -> https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L258
- extra will be set to 0 + 500 - 1500 = -1000 here -> https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L261

So it will enter "/* Message not complete yet. */" inside "if (extra < 0)", no?

Re: [QUESTION] BPF_SK_SKB_STREAM_PARSER cannot observe strparser orig_offset?

[Jiayuan Chen]

On 5/12/26 12:18 AM, Cristian Morales Vega (cmorve) wrote:
>>> On 5/11/26 10:49 PM, Cristian Morales Vega (cmorve) wrote:
>>> I am trying to use BPF_SK_SKB_STREAM_VERDICT in an old kernel (I don't have control over the version), so I need to also use BPF_SK_SKB_STREAM_PARSER. I though to just do "return skb->len;" in it, as a no-op, since I don't really have an use for the parser.
>> Since v5.18 BPF_SK_SKB_STREAM_VERDICT can be used without
>> BPF_SK_SKB_STREAM_PARSER.
>>
>> Which kernel version you use now?
> I think it's since 5.10? But I have to make it run on a big range of kernel versions, right now I'm looking at a 5.4.213 system.
>
>
>>> So far so good. But I can see that, from time to time, __strp_recv() receives a non-zero orig_offset as "first skb" (i.e. strp->skb_head is null). In such a case, I should not be returning skb->len but "skb->len - orig_offset" (i.e. orig_len), right? Otherwise I would enter
>>>
>>>                  extra = (ssize_t)(stm->accum_len + cand_len) -
>>>                          stm->strp.full_len;
>>>
>>>                  if (extra < 0) {
>>>                          /* Message not complete yet. */
>>>
>>> But AFAICT BPF_SK_SKB_STREAM_PARSER doesn't have access to that offset. It seems it had it until e0dc3b93bd7bcff8c3813d1df43e0908499c7cf0 (which was backported), but not any more?
>>>
>> Is my understanding correct? If not, what am I missing? And, if yes, there is any solution?
>>
>>
>> If you just return skb->len only in your parser , the 'issue' should not
>> happen.
> But if the parser returns skb->len, even in a modern system (in theory, I'm struggling to reproduce getting orig_offset != 0 in any system I can properly debug). Let's say orig_skb->len is 1500, orig_offset 1000 and orig_len 500.


   I think non-zero orig_offset only happens when __tcp_read_sock
   is mid-skb and recv_actor returns an error after consuming part
   of the data -- next call comes back with orig_offset != 0.


> - cand_len will be set to 500 here ->https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L186
> - len will be set to 1500 here -> https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L221
> - stm->strp.full_len will be set to 1500 here -> https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L258
> - extra will be set to 0 + 500 - 1500 = -1000 here -> https://github.com/torvalds/linux/blob/master/net/strparser/strparser.c#L261
>
> So it will enter "/* Message not complete yet. */" inside "if (extra < 0)", no?
To your earlier point: yes, what you really want is the skb
offset, especially for protocol framing. That scenario is real
and can be worked around using a map to carry state across

parser invocations.


But none of this fires as long as your parser keeps returning
skb->len.