netdev - Re: [PATCH net-next RFC 6/8] net: make gro configurable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 Sep 2018 19:09:57 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Network Development <netdev@...r.kernel.org>,
        Paolo Abeni <pabeni@...hat.com>, steffen.klassert@...unet.com,
        David Miller <davem@...emloft.net>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next RFC 6/8] net: make gro configurable

On Fri, Sep 14, 2018 at 6:50 PM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> On Fri, Sep 14, 2018 at 2:39 PM Stephen Hemminger
> <stephen@...workplumber.org> wrote:
> >
> > On Fri, 14 Sep 2018 13:59:39 -0400
> > Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
> >
> > > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> > > index e5d236595206..8cb8e02c8ab6 100644
> > > --- a/drivers/net/vxlan.c
> > > +++ b/drivers/net/vxlan.c
> > > @@ -572,6 +572,7 @@ static struct sk_buff *vxlan_gro_receive(struct sock *sk,
> > >                                        struct list_head *head,
> > >                                        struct sk_buff *skb)
> > >  {
> > > +     const struct net_offload *ops;
> > >       struct sk_buff *pp = NULL;
> > >       struct sk_buff *p;
> > >       struct vxlanhdr *vh, *vh2;
> > > @@ -606,6 +607,12 @@ static struct sk_buff *vxlan_gro_receive(struct sock *sk,
> > >                       goto out;
> > >       }
> > >
> > > +     rcu_read_lock();
> > > +     ops = net_gro_receive(dev_offloads, ETH_P_TEB);
> > > +     rcu_read_unlock();
> > > +     if (!ops)
> > > +             goto out;
> >
> > Isn't rcu_read_lock already held here?
> > RCU read lock is always held in the receive handler path
>
> There is a critical section on receive, taken in
> netif_receive_skb_core, but gro code runs before that. All the
> existing gro handlers call rcu_read_lock.

Though if dev_gro_receive is the entry point for all of gro, then
all other handlers are ensured to be executed within its rcu
readside section.