From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive Date: Tue, 24 Apr 2018 23:28:59 -0700 Message-ID: <20180425062859.GA23914@infradead.org> References: <20180425052722.73022-1-edumazet@google.com> <20180425052722.73022-2-edumazet@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "David S . Miller" , netdev , Andy Lutomirski , linux-kernel , linux-mm , Soheil Hassas Yeganeh , Eric Dumazet To: Eric Dumazet Return-path: Content-Disposition: inline In-Reply-To: <20180425052722.73022-2-edumazet@google.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, Apr 24, 2018 at 10:27:21PM -0700, Eric Dumazet wrote: > When adding tcp mmap() implementation, I forgot that socket lock > had to be taken before current->mm->mmap_sem. syzbot eventually caught > the bug. > > Since we can not lock the socket in tcp mmap() handler we have to > split the operation in two phases. > > 1) mmap() on a tcp socket simply reserves VMA space, and nothing else. > This operation does not involve any TCP locking. > > 2) setsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) implements > the transfert of pages from skbs to one VMA. > This operation only uses down_read(¤t->mm->mmap_sem) after > holding TCP lock, thus solving the lockdep issue. > > This new implementation was suggested by Andy Lutomirski with great details. Thanks, this looks much more sensible to me.