From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 15:20:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E817B7E; Fri, 21 Nov 2014 15:20:50 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F6CDE27; Fri, 21 Nov 2014 15:20:49 +0000 (UTC) Received: from x23 (31.147.127.91) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 16:20:40 +0100 Date: Fri, 21 Nov 2014 16:20:42 +0100 From: Marko Zec To: "Robert N. M. Watson" Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121162042.449b22dc@x23> In-Reply-To: References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [31.147.127.91] Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:20:50 -0000 On Fri, 21 Nov 2014 15:01:13 +0000 "Robert N. M. Watson" wrote: > > On 21 Nov 2014, at 11:02, Marko Zec wrote: > > >> I had convinced myself for UDP many years ago that it was ok to > >> remove it. People have touched the code however so it’s > >> definitively worth re-checking again. > >> > >> For TCP we clearly cannot do it (yet, and couldn’t back then). > >> But TCP was the only of the few cases I had left unfixed back then. > >> Can’t remember what the others were (was like 3 or 4 of them; > >> could also be some of the fixes were indeed committed back then. > > > > Now that we've found ourselves in this discussion, I'm really > > becoming curious why exactly do we need UMA_ZONE_NOFREE for network > > stack zones at all? Admittedly, I always thought that the primary > > purpose of UMA_ZONE_NOFREE was to prevent uma_reclaim() from paging > > out _used_ zone pages, but reviewing the uma code reveals that this > > might not be the case, i.e. that NOFREE only prevents _unused_ > > pages to be freed by uma_reclaim(). > > > > Moreover, all uma_zalloc() calls as far as I can see are flagged as > > M_NOWAIT and are followed by checks for allocation failures, so that > > part seems to be covered. > > > > So, what's really the problem which UMA_ZONE_NOFREE flagging is > > supposed to solve these days? (you claim that we clearly need it > > for TCP - why)? > > Bjoern and I chatted for the last twenty or so minutes about the > code, and believe that as things stand, it is *not* safe to turn off > UMA_ZONE_NOFREE for TCP due to a teardown race in TCP that has been > known about and discussed for several years, but is some work to > resolve and that we've not yet found time to do so. The XXXRW's in > tcp_timer.c are related to this. We're pondering ways to fix it but > think this is not something that can be rushed. OK fair enough - thanks a lot for looking into this! Skimming through a bunch of hosts with moderately loaded hosts with reasonably high uptime I couldn't find one where net.inet.tcp.timer_race was not zero. A ny suggestions how to best reproduce the race(s) in tcp_timer.c? Marko