lkml.org 
[lkml]   [2022]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next v4 2/4] net: tap: track dropped skb via kfree_skb_reason()
On Wed, 2 Mar 2022 09:43:29 -0800 Dongli Zhang wrote:
> On 3/1/22 6:42 PM, Jakub Kicinski wrote:
> > On Sat, 26 Feb 2022 00:49:27 -0800 Dongli Zhang wrote:
> >> + SKB_DROP_REASON_SKB_CSUM, /* sk_buff checksum error */
> >
> > Can we spell it out a little more? It sounds like the checksum was
> > incorrect. Will it be clear that computing the checksum failed, rather
> > than checksum validation failed?
>
> I am just trying to make the reasons as generic as possible so that:
>
> 1. We may minimize the number of reasons.
>
> 2. People may re-use the same reason for all CSUM related issue.

The generic nature is fine, my concern is to clearly differentiate
errors in _validating_ the checksum from errors in _generating_ them.
"sk_buff checksum error" does not explain which one had taken place.

> >> + SKB_DROP_REASON_SKB_COPY_DATA, /* failed to copy data from or to
> >> + * sk_buff
> >> + */
> >
> > Here should we specify that it's copying from user space?
>
> Same as above. I am minimizing the number of reasons so that any memory copy for
> sk_buff may re-use this reason.

IIUC this failure is equivalent to user passing an invalid buffer.
I mean something like:

send(fd, (void *)random(), 1000, 0);

I'd be tempted to call the reason something link SKB_UCOPY_FAULT.
To indicate it's a problem copying from user space. EFAULT is the
typical errno for that. WDYT?

\
 
 \ /
  Last update: 2022-03-02 20:03    [W:0.044 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site