Hi Menglong, On 3/1/22 8:16 PM, imagedong(董梦龙) wrote: > > > On 2022/3/2 AM 11:29，“David Ahern”<dsahern@xxxxxxxxx> write: > >> On 3/1/22 7:50 PM, Jakub Kicinski wrote: >>> On Sat, 26 Feb 2022 00:49:29 -0800 Dongli Zhang wrote: >>>> + SKB_DROP_REASON_SKB_PULL, /* failed to pull sk_buff data */ >>>> + SKB_DROP_REASON_SKB_TRIM, /* failed to trim sk_buff data */ >>> > [...] >>>> SKB_DROP_REASON_DEV_HDR, /* there is something wrong with >>>> * device driver specific header >>>> */ >>>> + SKB_DROP_REASON_DEV_READY, /* device is not ready */ >>> >>> What is ready? link is not up? peer not connected? can we expand? >> >> As I recall in this case it is the tfile for a tun device disappeared - >> ie., a race condition. > > This seems is that tun is not attached to a file (the tun device file > is not opened?) Maybe TAP_UNATTACHED is more suitable :) > > Thank you very much for the suggestions! TAP_UNATTACHED is more suitable. The tap/tun are only two of drivers in linux kernel. We have already introduced another two tap/tun specific reasons. My concern is we may finally have too many reasons. That's why I am always trying to define the reason as generic as possible so that they will be re-used by most networking drivers. We may expand the reason if it is fine to have too many reasons for skb_drop_reason. Dongli Zhang
