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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 9 Jun 2020 16:58:21 -0700
From:   Arjun Roy <arjunroy@...gle.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michel Lespinasse <walken@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Soheil Hassas Yeganeh <soheil@...gle.com>
Subject: Re: linux-next: manual merge of the net tree with Linus' tree

Ack, and thank you very much for the fix.

-Arjun


On Tue, Jun 9, 2020 at 4:30 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in:
>
>   net/ipv4/tcp.c
>
> between commit:
>
>   d8ed45c5dcd4 ("mmap locking API: use coccinelle to convert mmap_sem rwsem call sites")
>
> from Linus' tree and commit:
>
>   3763a24c727e ("net-zerocopy: use vm_insert_pages() for tcp rcv zerocopy")
>
> from the net tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc net/ipv4/tcp.c
> index 27716e4932bc,ecbba0abd3e5..000000000000
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@@ -1762,7 -1796,9 +1796,9 @@@ static int tcp_zerocopy_receive(struct
>
>         sock_rps_record_flow(sk);
>
> +       tp = tcp_sk(sk);
> +
>  -      down_read(&current->mm->mmap_sem);
>  +      mmap_read_lock(current->mm);
>
>         vma = find_vma(current->mm, address);
>         if (!vma || vma->vm_start > address || vma->vm_ops != &tcp_vm_ops) {
> @@@ -1817,17 -1863,27 +1863,27 @@@
>                         zc->recv_skip_hint -= remaining;
>                         break;
>                 }
> -               ret = vm_insert_page(vma, address + length,
> -                                    skb_frag_page(frags));
> -               if (ret)
> -                       break;
> +               pages[pg_idx] = skb_frag_page(frags);
> +               pg_idx++;
>                 length += PAGE_SIZE;
> -               seq += PAGE_SIZE;
>                 zc->recv_skip_hint -= PAGE_SIZE;
>                 frags++;
> +               if (pg_idx == PAGE_BATCH_SIZE) {
> +                       ret = tcp_zerocopy_vm_insert_batch(vma, pages, pg_idx,
> +                                                          &curr_addr, &length,
> +                                                          &seq, zc);
> +                       if (ret)
> +                               goto out;
> +                       pg_idx = 0;
> +               }
> +       }
> +       if (pg_idx) {
> +               ret = tcp_zerocopy_vm_insert_batch(vma, pages, pg_idx,
> +                                                  &curr_addr, &length, &seq,
> +                                                  zc);
>         }
>   out:
>  -      up_read(&current->mm->mmap_sem);
>  +      mmap_read_unlock(current->mm);
>         if (length) {
>                 WRITE_ONCE(tp->copied_seq, seq);
>                 tcp_rcv_space_adjust(sk);

Powered by blists - more mailing lists