All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Kanner <andrew.kanner@gmail.com>
To: Jason Wang <jasowang@redhat.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>
Cc: syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com,
	netdev@vger.kernel.org, john.fastabend@gmail.com,
	linux-kernel@vger.kernel.org, jbrouer@redhat.com,
	edumazet@google.com, dsahern@gmail.com, kuba@kernel.org,
	pabeni@redhat.com,
	linux-kernel-mentees@lists.linuxfoundation.org,
	davem@davemloft.net
Subject: Re: [PATCH v4 1/2] drivers: net: prevent tun_build_skb() to exceed the packet size limit
Date: Thu, 3 Aug 2023 20:53:16 +0300	[thread overview]
Message-ID: <64cbe991.190a0220.b646b.04c1@mx.google.com> (raw)
In-Reply-To: <CACGkMEvukuV5UZqb=MOaPqWfuJKOokZW1986GE4cRwt=Vx9Unw@mail.gmail.com>

On Thu, Aug 03, 2023 at 11:19:47AM +0800, Jason Wang wrote:
> > > @@ -1594,7 +1597,13 @@ static bool tun_can_build_skb(struct tun_struct *tun, struct tun_file *tfile,
> > >       if (zerocopy)
> > >               return false;
> > >
> > > -     if (SKB_DATA_ALIGN(len + TUN_RX_PAD) +
> > > +     rcu_read_lock();
> > > +     xdp_prog = rcu_dereference(tun->xdp_prog);
> > > +     if (xdp_prog)
> > > +             pad += XDP_PACKET_HEADROOM;
> > > +     rcu_read_unlock();
> > > +
> >
> > Isolated seen, I guess, this is a correct fix to 7df13219d757.
> 
> I think so.
> 
> Actually, I think we can probably always count XDP_PACKET_HEADROOM
> here. Since there's a window that XDP program might be attached in the
> middle of tun_can_build_skb() and tun_build_skb().


Thanks, that makes sense.
I will do it in v5.


> > Question to Jason Wang:
> > Why fall back (to e.g. tun_alloc_skb()) when size is above PAGE_SIZE?
> >
> > AFAIK tun_build_skb() *can* create get larger packets than PAGE_SIZE
> > from it's page_frag.  Is there a reason for this limitation?
> 
> I couldn't recall but I think we can relax.

Jesper already sent enough info for this idea in v2, I will use it for
the next patch/series.

Jesper, I will add this tag for this next patch/series if you don't
mind:
Suggested-by: Jesper Dangaard Brouer <hawk@kernel.org>

-- 
Andrew Kanner
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Kanner <andrew.kanner@gmail.com>
To: Jason Wang <jasowang@redhat.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org, dsahern@gmail.com,
	jbrouer@redhat.com, john.fastabend@gmail.com,
	linux-kernel@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com
Subject: Re: [PATCH v4 1/2] drivers: net: prevent tun_build_skb() to exceed the packet size limit
Date: Thu, 3 Aug 2023 20:53:16 +0300	[thread overview]
Message-ID: <64cbe991.190a0220.b646b.04c1@mx.google.com> (raw)
In-Reply-To: <CACGkMEvukuV5UZqb=MOaPqWfuJKOokZW1986GE4cRwt=Vx9Unw@mail.gmail.com>

On Thu, Aug 03, 2023 at 11:19:47AM +0800, Jason Wang wrote:
> > > @@ -1594,7 +1597,13 @@ static bool tun_can_build_skb(struct tun_struct *tun, struct tun_file *tfile,
> > >       if (zerocopy)
> > >               return false;
> > >
> > > -     if (SKB_DATA_ALIGN(len + TUN_RX_PAD) +
> > > +     rcu_read_lock();
> > > +     xdp_prog = rcu_dereference(tun->xdp_prog);
> > > +     if (xdp_prog)
> > > +             pad += XDP_PACKET_HEADROOM;
> > > +     rcu_read_unlock();
> > > +
> >
> > Isolated seen, I guess, this is a correct fix to 7df13219d757.
> 
> I think so.
> 
> Actually, I think we can probably always count XDP_PACKET_HEADROOM
> here. Since there's a window that XDP program might be attached in the
> middle of tun_can_build_skb() and tun_build_skb().


Thanks, that makes sense.
I will do it in v5.


> > Question to Jason Wang:
> > Why fall back (to e.g. tun_alloc_skb()) when size is above PAGE_SIZE?
> >
> > AFAIK tun_build_skb() *can* create get larger packets than PAGE_SIZE
> > from it's page_frag.  Is there a reason for this limitation?
> 
> I couldn't recall but I think we can relax.

Jesper already sent enough info for this idea in v2, I will use it for
the next patch/series.

Jesper, I will add this tag for this next patch/series if you don't
mind:
Suggested-by: Jesper Dangaard Brouer <hawk@kernel.org>

-- 
Andrew Kanner

  reply	other threads:[~2023-08-03 17:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-01 22:07 [PATCH v4 1/2] drivers: net: prevent tun_build_skb() to exceed the packet size limit Andrew Kanner
2023-08-01 22:07 ` Andrew Kanner
2023-08-01 22:07 ` [PATCH v4 2/2] net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail() Andrew Kanner
2023-08-01 22:07   ` Andrew Kanner
2023-08-02 13:56   ` Jesper Dangaard Brouer
2023-08-02 13:56     ` Jesper Dangaard Brouer
2023-08-03  3:20   ` Jason Wang
2023-08-03  3:20     ` Jason Wang
2023-08-03 18:06     ` Andrew Kanner
2023-08-03 18:06       ` Andrew Kanner
2023-08-02  1:07 ` [PATCH v4 1/2] drivers: net: prevent tun_build_skb() to exceed the packet size limit David Ahern
2023-08-02  1:07   ` David Ahern
2023-08-02 12:16   ` Andrew Kanner
2023-08-02 12:16     ` Andrew Kanner
2023-08-02 14:13 ` Jesper Dangaard Brouer
2023-08-02 14:13   ` Jesper Dangaard Brouer
2023-08-03  3:19   ` Jason Wang
2023-08-03  3:19     ` Jason Wang
2023-08-03 17:53     ` Andrew Kanner [this message]
2023-08-03 17:53       ` Andrew Kanner
2023-08-04  9:30       ` Jesper Dangaard Brouer
2023-08-04  9:30         ` Jesper Dangaard Brouer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64cbe991.190a0220.b646b.04c1@mx.google.com \
    --to=andrew.kanner@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=jasowang@redhat.com \
    --cc=jbrouer@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.