From owner-freebsd-net@freebsd.org Wed Oct 16 17:33:38 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1512D14C0D6 for ; Wed, 16 Oct 2019 17:33:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tfXd288Cz44LW for ; Wed, 16 Oct 2019 17:33:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82d.google.com with SMTP id c21so37248779qtj.12 for ; Wed, 16 Oct 2019 10:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=IgYmMWEOUeo1bGIvAujMHqsbVOhWtEeehdL9uNTKPlo=; b=XwX9SfKy0V3qxm7YRboQu/T8vcde7c0yy2Sn9hI7BLKnExAB3TuJWoimoK9YxADLMX omHHaHtLciDyymkS4HuHeIHJkCXEnYFwxIm3gYuLdpxhrKQ5usCq2WqAwqVI8NPdr1WT duasoG4DIC/OKIgT/zRXnPdwOeKk1xvCt+qrX9oCr++5nRHUjFVhweyXL1+PyPz4u7r6 5mt0hkJYVQ/6xS30A36djHWiyh+yXuAy890EcEtkunNy/RYEd10jjnADNTEicQbQ9s15 H/zMqwdXprokMizijKHL98ixF3eOzL9cke1VK5BqevHDapnf7Ez//6cwi8suUkiedy8h rqxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=IgYmMWEOUeo1bGIvAujMHqsbVOhWtEeehdL9uNTKPlo=; b=g+N40YtPaahx4jYXHr2pRlT4cm10H3Wp9jAYHOsXe2on+gXIDvtp5ll0gdjJ6jUhff FNSPKCCD6O9z8R4e7GSiFFIdRj3Rn6As765KVgZFhtpYW1wMkGiRk2FwtJw2FfF2aQRi FWzgFEyeA6cOXF9cwV/Eukay7otEXwOvsNx6vQegt8gccrgSem3Rwp1g7iG7vTN26J0N bp5n9Wzzh25nF5fvxkaMpGO2rvT0g4ROKM0XD1m6TD9l/D7/10QrQ7kjn/9Smv9P7pPR XLhdBKBUyTJNJgHTq+WjlxWvhxRuyt/US6jiRZf/vRrntjbhf6m5qEfZ5PYnBUkcrK/X xK3w== X-Gm-Message-State: APjAAAWFrK4b63ICNpTFgJECh0e39LWy+M0dyXtnbzv/Gwfye3/TmwGc Z/YSWJgD9uR279mbPM5XOqg= X-Google-Smtp-Source: APXvYqxiQ2EB8Yxo3MT4pd+45UoeX9GRUlZYHXPNWCVZIWvQM/kfC7aEGAk+07FXLkIfJ4aapX9V8Q== X-Received: by 2002:ad4:5044:: with SMTP id m4mr44391481qvq.85.1571247215959; Wed, 16 Oct 2019 10:33:35 -0700 (PDT) Received: from raichu (toroon0560w-lp130-05-69-158-183-252.dsl.bell.ca. [69.158.183.252]) by smtp.gmail.com with ESMTPSA id n42sm16373079qta.31.2019.10.16.10.33.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2019 10:33:34 -0700 (PDT) Sender: Mark Johnston Date: Wed, 16 Oct 2019 13:33:32 -0400 From: Mark Johnston To: Dheeraj Kandula Cc: freebsd-net@freebsd.org Subject: Re: Socket Sleep and Wakeup clarification Message-ID: <20191016173332.GF82455@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46tfXd288Cz44LW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XwX9SfKy; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-4.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[d.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.80)[ip: (-9.37), ipnet: 2607:f8b0::/32(-2.47), asn: 15169(-2.10), country: US(-0.05)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 17:33:38 -0000 On Wed, Jul 31, 2019 at 04:36:08PM -0400, Dheeraj Kandula wrote: > Hi All, > I am reading through the socket code in uipc_socket.c file of FreeBSD > 12. > > The code invokes wakeup with the channel as so->so_timeo in the following > functions: > soisconnected > soisdisconnected > soisdisconnecting and > soshutdown > > The callers of soconnect invoke sleep so that the thread that invokes > soconnect wakes up when the TCP 3 way handshake is done. The soconnect in > kernel returns immediately unlike user space connect which sleeps. > > I also see tsleep in soclose when the socket's state is SS_ISCONNECTED. > > My questions: > 1. Is it possible to close a socket when the application is sleeping > after the application invokes soconnect. Basically I am trying to figure > out how multiple threads can access the same socket for soconnect and > soclose to happen at the same time. I don't see any particular synchronization between soclose() and the sleep you are referring to, so there might be a bug here. In particular, I would expect soclose() on a connecting socket to wake up sleepers, but I cannot see how that happens. > 2. soshutdown also invokes wakeup. This wakeup again corresponds to > the sleep by soconnect. Isn't it? How can we have two threads accessing the > same socket with one thread sleeping on a socket for the soconnect, while > another shuts down the same socket in either the RD or WR or RW direction. Yes, wakeup(&so->so_timeo) should be called whenever the connection state of a socket changes.