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
| ||
|
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(¤t->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(¤t->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