From owner-freebsd-net@FreeBSD.ORG Fri May 25 05:01:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 586CF106566B for ; Fri, 25 May 2012 05:01:47 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 30D318FC14 for ; Fri, 25 May 2012 05:01:47 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so1338910pbb.13 for ; Thu, 24 May 2012 22:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=99He22bnXlBoq/YPVbPJ5uD+ytWx6Bl0LMKAyBwrNuQ=; b=OatL6R5/FJcc4NEC8eNQq84i92PQHBKL18PwXV6OumEJ5bfQAWb9XzxC17loD3UIa3 JJ0ioReNjYv6mq8XAKQAdPt8kCkO2bPN2dR34L6RB8dC84WNV9dbtBnTS/zmPwEQNRho UmjyfsD56CoY/dgamgH34bdNs1yEcsbtk0oeZt1qJQ1+8197y68wRr75bfixEj4QHuhf zxUYH0pzZKWkylDyCiB38ReWf/WjWXwFAtS4ghbyRmuFPUYCe4qbvB6eG0kfP2RIgFzH lGvRSLN8Hao/YZDGRPvvMgqdfwpq30KE4TxP3HMKh4cOs6E377n47Dzj6I08JZ/hLbux MMtg== MIME-Version: 1.0 Received: by 10.68.230.195 with SMTP id ta3mr10778965pbc.56.1337922106727; Thu, 24 May 2012 22:01:46 -0700 (PDT) Received: by 10.142.54.2 with HTTP; Thu, 24 May 2012 22:01:46 -0700 (PDT) Date: Thu, 24 May 2012 22:01:46 -0700 Message-ID: From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Use of V_tcbinfo lock in tcp_do_segment() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 May 2012 05:01:47 -0000 Folks, I am trying to understand the need to hold the V_tcbinfo lock in part of this function [code included below for reference]. At present this causes the socket upcall to be called with the V_tcbinfo lock held, which I'd like to avoid. We release this lock right after this section. Looking at the code, it seems the lock is needed if we were in FIN_WAIT_2 and tcp_close() the connection. The lock also seems to be protecting V_twq_2msl. Would it be an acceptable solution if we deferred calling socantrecvmore() till after the lock can be dropped (after the swtich statement). tcp_twstart() can be changed to return tp if the connections survives, or NULL if it doesn't, much like what tcp_close() does. Also a new lock could be added to protect the V_rwq_2msl queue. If this sounds acceptable, I can generate a patch against -CURRENT. I would appreciate feedback. -vijay relevant code from tcp_do_segment(): if (thflags & TH_FIN) { if (TCPS_HAVERCVDFIN(tp->t_state) == 0) { socantrcvmore(so); /* * If connection is half-synchronized * (ie NEEDSYN flag on) then delay ACK, * so it may be piggybacked when SYN is sent. * Otherwise, since we received a FIN then no * more input can be expected, send ACK now. */ if (tp->t_flags & TF_NEEDSYN) tp->t_flags |= TF_DELACK; else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt++; } switch (tp->t_state) { /* * In SYN_RECEIVED and ESTABLISHED STATES * enter the CLOSE_WAIT state. */ case TCPS_SYN_RECEIVED: tp->t_starttime = ticks; /* FALLTHROUGH */ case TCPS_ESTABLISHED: tp->t_state = TCPS_CLOSE_WAIT; break; /* * If still in FIN_WAIT_1 STATE FIN has not been acked so * enter the CLOSING state. */ case TCPS_FIN_WAIT_1: tp->t_state = TCPS_CLOSING; break; /* * In FIN_WAIT_2 state enter the TIME_WAIT state, * starting the time-wait timer, turning off the other * standard timers. */ case TCPS_FIN_WAIT_2: INP_INFO_WLOCK_ASSERT(&V_tcbinfo); KASSERT(ti_locked == TI_WLOCKED, ("%s: dodata " "TCP_FIN_WAIT_2 ti_locked: %d", __func__, ti_locked)); tcp_twstart(tp); INP_INFO_WUNLOCK(&V_tcbinfo); return; }