* [PATCH net] net: tun: limit first seg size to avoid oversized linearization
@ 2022-09-07 1:56 Ziyang Xuan
2022-09-09 14:18 ` Petar Penkov
2022-09-09 16:36 ` Eric Dumazet
0 siblings, 2 replies; 6+ messages in thread
From: Ziyang Xuan @ 2022-09-07 1:56 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, netdev
Cc: linux-kernel, ast, daniel, hawk, john.fastabend, peterpenkov96,
maheshb
Recently, we found a syzkaller problem as following:
========================================================
WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
...
Call trace:
__alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
__alloc_pages_node include/linux/gfp.h:550 [inline]
alloc_pages_node include/linux/gfp.h:564 [inline]
kmalloc_large_node+0x94/0x350 mm/slub.c:4038
__kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
__kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
__skb_grow include/linux/skbuff.h:2779 [inline]
tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
It is because the first seg size of the iov_iter from user space is
very big, it is 2147479538 which is bigger than the threshold value
for bail out early in __alloc_pages(). And skb->pfmemalloc is true,
__kmalloc_reserve() would use pfmemalloc reserves without __GFP_NOWARN
flag. Thus we got a warning.
I noticed that non-first segs size are required less than PAGE_SIZE in
tun_napi_alloc_frags(). The first seg should not be a special case, and
oversized linearization is also unreasonable. Limit the first seg size to
PAGE_SIZE to avoid oversized linearization.
Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
---
drivers/net/tun.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 259b2b84b2b3..7db515f94667 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1454,12 +1454,12 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
size_t len,
const struct iov_iter *it)
{
+ size_t linear = iov_iter_single_seg_count(it);
struct sk_buff *skb;
- size_t linear;
int err;
int i;
- if (it->nr_segs > MAX_SKB_FRAGS + 1)
+ if (it->nr_segs > MAX_SKB_FRAGS + 1 || linear > PAGE_SIZE)
return ERR_PTR(-EMSGSIZE);
local_bh_disable();
@@ -1468,7 +1468,6 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
if (!skb)
return ERR_PTR(-ENOMEM);
- linear = iov_iter_single_seg_count(it);
err = __skb_grow(skb, linear);
if (err)
goto free;
--
2.25.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH net] net: tun: limit first seg size to avoid oversized linearization
2022-09-07 1:56 [PATCH net] net: tun: limit first seg size to avoid oversized linearization Ziyang Xuan
@ 2022-09-09 14:18 ` Petar Penkov
2022-09-09 16:36 ` Eric Dumazet
1 sibling, 0 replies; 6+ messages in thread
From: Petar Penkov @ 2022-09-09 14:18 UTC (permalink / raw)
To: Ziyang Xuan
Cc: davem, edumazet, kuba, pabeni, netdev, linux-kernel, ast, daniel,
hawk, john.fastabend, maheshb
Thanks, this looks good to me!
On Tue, Sep 6, 2022 at 6:56 PM Ziyang Xuan
<william.xuanziyang@huawei.com> wrote:
>
> Recently, we found a syzkaller problem as following:
>
> ========================================================
> WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> ...
> Call trace:
> __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> __alloc_pages_node include/linux/gfp.h:550 [inline]
> alloc_pages_node include/linux/gfp.h:564 [inline]
> kmalloc_large_node+0x94/0x350 mm/slub.c:4038
> __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
> __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
> pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
> __skb_grow include/linux/skbuff.h:2779 [inline]
> tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
> tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
> tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
>
> It is because the first seg size of the iov_iter from user space is
> very big, it is 2147479538 which is bigger than the threshold value
> for bail out early in __alloc_pages(). And skb->pfmemalloc is true,
> __kmalloc_reserve() would use pfmemalloc reserves without __GFP_NOWARN
> flag. Thus we got a warning.
>
> I noticed that non-first segs size are required less than PAGE_SIZE in
> tun_napi_alloc_frags(). The first seg should not be a special case, and
> oversized linearization is also unreasonable. Limit the first seg size to
> PAGE_SIZE to avoid oversized linearization.
>
> Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
> ---
Acked-by: Petar Penkov <ppenkov@aviatrix.com>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net] net: tun: limit first seg size to avoid oversized linearization
2022-09-07 1:56 [PATCH net] net: tun: limit first seg size to avoid oversized linearization Ziyang Xuan
2022-09-09 14:18 ` Petar Penkov
@ 2022-09-09 16:36 ` Eric Dumazet
2022-09-13 12:07 ` Ziyang Xuan (William)
1 sibling, 1 reply; 6+ messages in thread
From: Eric Dumazet @ 2022-09-09 16:36 UTC (permalink / raw)
To: Ziyang Xuan
Cc: David Miller, Jakub Kicinski, Paolo Abeni, netdev, LKML,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Petar Penkov, Mahesh Bandewar
On Tue, Sep 6, 2022 at 6:56 PM Ziyang Xuan
<william.xuanziyang@huawei.com> wrote:
>
> Recently, we found a syzkaller problem as following:
>
> ========================================================
> WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> ...
> Call trace:
> __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> __alloc_pages_node include/linux/gfp.h:550 [inline]
> alloc_pages_node include/linux/gfp.h:564 [inline]
> kmalloc_large_node+0x94/0x350 mm/slub.c:4038
> __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
> __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
> pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
> __skb_grow include/linux/skbuff.h:2779 [inline]
> tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
> tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
> tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
>
> It is because the first seg size of the iov_iter from user space is
> very big, it is 2147479538 which is bigger than the threshold value
> for bail out early in __alloc_pages(). And skb->pfmemalloc is true,
> __kmalloc_reserve() would use pfmemalloc reserves without __GFP_NOWARN
> flag. Thus we got a warning.
>
> I noticed that non-first segs size are required less than PAGE_SIZE in
> tun_napi_alloc_frags(). The first seg should not be a special case, and
> oversized linearization is also unreasonable. Limit the first seg size to
> PAGE_SIZE to avoid oversized linearization.
>
> Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
> ---
> drivers/net/tun.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 259b2b84b2b3..7db515f94667 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1454,12 +1454,12 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
> size_t len,
> const struct iov_iter *it)
> {
> + size_t linear = iov_iter_single_seg_count(it);
> struct sk_buff *skb;
> - size_t linear;
> int err;
> int i;
>
> - if (it->nr_segs > MAX_SKB_FRAGS + 1)
> + if (it->nr_segs > MAX_SKB_FRAGS + 1 || linear > PAGE_SIZE)
> return ERR_PTR(-EMSGSIZE);
>
This does not look good to me.
Some drivers allocate 9KB+ for 9000 MTU, in a single allocation,
because the hardware is not SG capable in RX.
> local_bh_disable();
> @@ -1468,7 +1468,6 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
> if (!skb)
> return ERR_PTR(-ENOMEM);
>
> - linear = iov_iter_single_seg_count(it);
> err = __skb_grow(skb, linear);
> if (err)
> goto free;
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net] net: tun: limit first seg size to avoid oversized linearization
2022-09-09 16:36 ` Eric Dumazet
@ 2022-09-13 12:07 ` Ziyang Xuan (William)
2022-09-15 10:31 ` Paolo Abeni
0 siblings, 1 reply; 6+ messages in thread
From: Ziyang Xuan (William) @ 2022-09-13 12:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Jakub Kicinski, Paolo Abeni, netdev, LKML,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Petar Penkov, Mahesh Bandewar
> On Tue, Sep 6, 2022 at 6:56 PM Ziyang Xuan
> <william.xuanziyang@huawei.com> wrote:
>>
>> Recently, we found a syzkaller problem as following:
>>
>> ========================================================
>> WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
>> ...
>> Call trace:
>> __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
>> __alloc_pages_node include/linux/gfp.h:550 [inline]
>> alloc_pages_node include/linux/gfp.h:564 [inline]
>> kmalloc_large_node+0x94/0x350 mm/slub.c:4038
>> __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
>> __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
>> pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
>> __skb_grow include/linux/skbuff.h:2779 [inline]
>> tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
>> tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
>> tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
>>
>> It is because the first seg size of the iov_iter from user space is
>> very big, it is 2147479538 which is bigger than the threshold value
>> for bail out early in __alloc_pages(). And skb->pfmemalloc is true,
>> __kmalloc_reserve() would use pfmemalloc reserves without __GFP_NOWARN
>> flag. Thus we got a warning.
>>
>> I noticed that non-first segs size are required less than PAGE_SIZE in
>> tun_napi_alloc_frags(). The first seg should not be a special case, and
>> oversized linearization is also unreasonable. Limit the first seg size to
>> PAGE_SIZE to avoid oversized linearization.
>>
>> Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
>> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
>> ---
>> drivers/net/tun.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 259b2b84b2b3..7db515f94667 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1454,12 +1454,12 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
>> size_t len,
>> const struct iov_iter *it)
>> {
>> + size_t linear = iov_iter_single_seg_count(it);
>> struct sk_buff *skb;
>> - size_t linear;
>> int err;
>> int i;
>>
>> - if (it->nr_segs > MAX_SKB_FRAGS + 1)
>> + if (it->nr_segs > MAX_SKB_FRAGS + 1 || linear > PAGE_SIZE)
>> return ERR_PTR(-EMSGSIZE);
>>
>
> This does not look good to me.
>
> Some drivers allocate 9KB+ for 9000 MTU, in a single allocation,
> because the hardware is not SG capable in RX.
So, do you mean that it does not matter and keep current status, or give a bigger size but PAGE_SIZE (usually 4KB size)?
Would like to hear your advice.
Thank you.
>
>> local_bh_disable();
>> @@ -1468,7 +1468,6 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
>> if (!skb)
>> return ERR_PTR(-ENOMEM);
>>
>> - linear = iov_iter_single_seg_count(it);
>> err = __skb_grow(skb, linear);
>> if (err)
>> goto free;
>> --
>> 2.25.1
>>
> .
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net] net: tun: limit first seg size to avoid oversized linearization
2022-09-13 12:07 ` Ziyang Xuan (William)
@ 2022-09-15 10:31 ` Paolo Abeni
2022-10-27 14:11 ` Eric Dumazet
0 siblings, 1 reply; 6+ messages in thread
From: Paolo Abeni @ 2022-09-15 10:31 UTC (permalink / raw)
To: Ziyang Xuan (William), Eric Dumazet
Cc: David Miller, Jakub Kicinski, netdev, LKML, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Petar Penkov, Mahesh Bandewar
On Tue, 2022-09-13 at 20:07 +0800, Ziyang Xuan (William) wrote:
> > On Tue, Sep 6, 2022 at 6:56 PM Ziyang Xuan
> > <william.xuanziyang@huawei.com> wrote:
> > >
> > > Recently, we found a syzkaller problem as following:
> > >
> > > ========================================================
> > > WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295
> > > __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> > > ...
> > > Call trace:
> > > __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> > > __alloc_pages_node include/linux/gfp.h:550 [inline]
> > > alloc_pages_node include/linux/gfp.h:564 [inline]
> > > kmalloc_large_node+0x94/0x350 mm/slub.c:4038
> > > __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
> > > __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
> > > pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
> > > __skb_grow include/linux/skbuff.h:2779 [inline]
> > > tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
> > > tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
> > > tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
> > >
> > > It is because the first seg size of the iov_iter from user space
> > > is
> > > very big, it is 2147479538 which is bigger than the threshold
> > > value
> > > for bail out early in __alloc_pages(). And skb->pfmemalloc is
> > > true,
> > > __kmalloc_reserve() would use pfmemalloc reserves without
> > > __GFP_NOWARN
> > > flag. Thus we got a warning.
> > >
> > > I noticed that non-first segs size are required less than
> > > PAGE_SIZE in
> > > tun_napi_alloc_frags(). The first seg should not be a special
> > > case, and
> > > oversized linearization is also unreasonable. Limit the first seg
> > > size to
> > > PAGE_SIZE to avoid oversized linearization.
> > >
> > > Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP
> > > driver")
> > > Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
> > > ---
> > > drivers/net/tun.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > index 259b2b84b2b3..7db515f94667 100644
> > > --- a/drivers/net/tun.c
> > > +++ b/drivers/net/tun.c
> > > @@ -1454,12 +1454,12 @@ static struct sk_buff
> > > *tun_napi_alloc_frags(struct tun_file *tfile,
> > > size_t len,
> > > const struct iov_iter
> > > *it)
> > > {
> > > + size_t linear = iov_iter_single_seg_count(it);
> > > struct sk_buff *skb;
> > > - size_t linear;
> > > int err;
> > > int i;
> > >
> > > - if (it->nr_segs > MAX_SKB_FRAGS + 1)
> > > + if (it->nr_segs > MAX_SKB_FRAGS + 1 || linear >
> > > PAGE_SIZE)
> > > return ERR_PTR(-EMSGSIZE);
> > >
> >
> > This does not look good to me.
> >
> > Some drivers allocate 9KB+ for 9000 MTU, in a single allocation,
> > because the hardware is not SG capable in RX.
>
> So, do you mean that it does not matter and keep current status, or
> give a bigger size but PAGE_SIZE (usually 4KB size)?
>
> Would like to hear your advice.
I'm guessing that what Eric is suggesting here is to use a bigger limit
for 'linear'. Possibly ETH_MAX_MTU could fit. @Eric, fell free to
correct me :)
Thanks!
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net] net: tun: limit first seg size to avoid oversized linearization
2022-09-15 10:31 ` Paolo Abeni
@ 2022-10-27 14:11 ` Eric Dumazet
0 siblings, 0 replies; 6+ messages in thread
From: Eric Dumazet @ 2022-10-27 14:11 UTC (permalink / raw)
To: Paolo Abeni
Cc: Ziyang Xuan (William), David Miller, Jakub Kicinski, netdev, LKML,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Petar Penkov, Mahesh Bandewar
On Thu, Sep 15, 2022 at 3:31 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Tue, 2022-09-13 at 20:07 +0800, Ziyang Xuan (William) wrote:
> > > On Tue, Sep 6, 2022 at 6:56 PM Ziyang Xuan
> > > <william.xuanziyang@huawei.com> wrote:
> > > >
> > > > Recently, we found a syzkaller problem as following:
> > > >
> > > > ========================================================
> > > > WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295
> > > > __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> > > > ...
> > > > Call trace:
> > > > __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
> > > > __alloc_pages_node include/linux/gfp.h:550 [inline]
> > > > alloc_pages_node include/linux/gfp.h:564 [inline]
> > > > kmalloc_large_node+0x94/0x350 mm/slub.c:4038
> > > > __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
> > > > __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
> > > > pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
> > > > __skb_grow include/linux/skbuff.h:2779 [inline]
> > > > tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
> > > > tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
> > > > tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
> > > >
> > > > It is because the first seg size of the iov_iter from user space
> > > > is
> > > > very big, it is 2147479538 which is bigger than the threshold
> > > > value
> > > > for bail out early in __alloc_pages(). And skb->pfmemalloc is
> > > > true,
> > > > __kmalloc_reserve() would use pfmemalloc reserves without
> > > > __GFP_NOWARN
> > > > flag. Thus we got a warning.
> > > >
> > > > I noticed that non-first segs size are required less than
> > > > PAGE_SIZE in
> > > > tun_napi_alloc_frags(). The first seg should not be a special
> > > > case, and
> > > > oversized linearization is also unreasonable. Limit the first seg
> > > > size to
> > > > PAGE_SIZE to avoid oversized linearization.
> > > >
> > > > Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP
> > > > driver")
> > > > Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
> > > > ---
> > > > drivers/net/tun.c | 5 ++---
> > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > > index 259b2b84b2b3..7db515f94667 100644
> > > > --- a/drivers/net/tun.c
> > > > +++ b/drivers/net/tun.c
> > > > @@ -1454,12 +1454,12 @@ static struct sk_buff
> > > > *tun_napi_alloc_frags(struct tun_file *tfile,
> > > > size_t len,
> > > > const struct iov_iter
> > > > *it)
> > > > {
> > > > + size_t linear = iov_iter_single_seg_count(it);
> > > > struct sk_buff *skb;
> > > > - size_t linear;
> > > > int err;
> > > > int i;
> > > >
> > > > - if (it->nr_segs > MAX_SKB_FRAGS + 1)
> > > > + if (it->nr_segs > MAX_SKB_FRAGS + 1 || linear >
> > > > PAGE_SIZE)
> > > > return ERR_PTR(-EMSGSIZE);
> > > >
> > >
> > > This does not look good to me.
> > >
> > > Some drivers allocate 9KB+ for 9000 MTU, in a single allocation,
> > > because the hardware is not SG capable in RX.
> >
> > So, do you mean that it does not matter and keep current status, or
> > give a bigger size but PAGE_SIZE (usually 4KB size)?
> >
> > Would like to hear your advice.
>
> I'm guessing that what Eric is suggesting here is to use a bigger limit
> for 'linear'. Possibly ETH_MAX_MTU could fit. @Eric, fell free to
> correct me :)
>
Something like that, yes. We need to be careful when approaching 64K limit,
because of possible u16 fields overflows.
We just got another patch in GRO layer, just because tun has not been fixed yet.
> Thanks!
>
> Paolo
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-10-27 14:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-09-07 1:56 [PATCH net] net: tun: limit first seg size to avoid oversized linearization Ziyang Xuan
2022-09-09 14:18 ` Petar Penkov
2022-09-09 16:36 ` Eric Dumazet
2022-09-13 12:07 ` Ziyang Xuan (William)
2022-09-15 10:31 ` Paolo Abeni
2022-10-27 14:11 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).