From owner-freebsd-net@freebsd.org Fri Oct 25 16:15:42 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 E7D81174CA3 for ; Fri, 25 Oct 2019 16:15:42 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 4708NY5836z3Dm4 for ; Fri, 25 Oct 2019 16:15:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x836.google.com with SMTP id o25so4053335qtr.5 for ; Fri, 25 Oct 2019 09:15:41 -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=dzl2wqsJ//Pfn1URHIv05h7E7Oux5W5LYlirZe+a224=; b=mu7YpCJll5CejHVkzY3rwJ9MWIswOHLCS2l3ImZ5XaNJGsmQkBQxUWyh6mIS5n8Gba 6Dn6Uk1uhaSgsq8Ort+NNLTHRojEGpRZfx9tgliB0AJ9GA4JBeH+KP/oWV0eCevgckmz fAJJ3Nvfw0efLbw/x4M2V4yQ3B2bMbVn88d2c7BH20sMX9hsGiPJU6eqw7RM3ExnUG0r EzXiJSl/njr/8tQyPDaKTOM779meuoUFvvz0osgkZC/N5kjrUdDZH6fY75VoD/lg3y83 f1gOaUVdSPl0aMuDFd960eVmrr0LdyRqlDEJ1jdSqIBQPKBx+AWDtfjE3gm4Nfhrfq/N tYdw== 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=dzl2wqsJ//Pfn1URHIv05h7E7Oux5W5LYlirZe+a224=; b=guQdes8GGFNeeK+FZKuWlluvlGJ+ICrITLsIwimHDYg/vZ+0ud4O7cuosBEUEwRET4 DLZZ4mbWiqZx6Uos4riTu+7dTWwzkbDF/TNRWyAmkyqNIbXykcrRLEYXXsogAKtEWf8o 17nCq1V2NJsaEQ9fUPhfqngafg8TfOEMeIRvOWZsnd4+XTcLiy5bTXXg3QUDNYsxjkbb +Cu+giqXHe+m8rfXQGlUC83LqNdtqsNmhCKoTlAymA56MJ6uved/pN+kWSFVvxUGWNnH 0i+NjKC/1uNy6dUPJ5+eqLWxChVi6r6Td8qaLqeG1PePgeb3L0CgEXnniqn60XlG4nIJ o+vA== X-Gm-Message-State: APjAAAWfTxLzy2/kyvcJGxjkbXHp9rp1o9lHY1u+ik9c/xCBMKcanhB2 vPiGgnUWalTL+NEpWXzJEig= X-Google-Smtp-Source: APXvYqwPmP6hpVQ7IZ34CN3+UK7mtpHPa5GBxnNJqmqZFVWy24VgSgry2egsrncEJmr7xbcR4O+LuA== X-Received: by 2002:aed:37c9:: with SMTP id j67mr3798019qtb.291.1572020140353; Fri, 25 Oct 2019 09:15:40 -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 a6sm1263821qth.74.2019.10.25.09.15.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Oct 2019 09:15:39 -0700 (PDT) Sender: Mark Johnston Date: Fri, 25 Oct 2019 12:15:37 -0400 From: Mark Johnston To: Dheeraj Kandula Cc: freebsd-net@freebsd.org Subject: Re: soisconnected. Message-ID: <20191025161537.GB67949@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: 4708NY5836z3Dm4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mu7YpCJl; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::836 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-4.45 / 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]; 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)[6.3.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.75)[ip: (-9.24), ipnet: 2607:f8b0::/32(-2.41), asn: 15169(-2.05), 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: Fri, 25 Oct 2019 16:15:43 -0000 On Fri, Oct 25, 2019 at 11:36:53AM -0400, Dheeraj Kandula wrote: > Hi Mark, > I am trying to understand the purpose of certain code in > soisconnected. +freebsd-net > 1. When an upcall returns SO_ISCONNECTED, the sockbuf's lock is unlocked > and then soisconnected is invoked. This is done in order to avoid a lock > order reversal as SOCK_LOCK is grabbed at the beginning of soisconnected. > Isn't it? Note, it is SU_ISCONNECTED, not SO_ISCONNECTED. Yes, I believe that is true. The socket lock comes first in the lock order. > 2. When an upcall returns SO_ISCONNECTED, the receive socket buffer's > upcall on the "so" socket is cleared. The upcall that is cleared is the > accept filter upcall that is set in soisconnected in the "else" part on > line 3849 of release head in file uipc_socket.c. I am not sure why we do > this. Even if it is set, the solisten_wakeup is called on the head socket > which is a listen socket and not the "so" socket in soisconnected. Is this > a remnant from old code? Once the accept filter has accepted the connection by returning SU_ISCONNECTED, it has no more work to do, so we should clear the upcall. Otherwise it would be invoked each time the socket buffer receives new data, but the accept filter's purpose is only to identify valid requests. The listening socket upcall is not used by accept filters. It is used by callers of solisten_upcall_set(), of which there are several in the tree. > 3. When an upcall returns SU_OK in the same "else" code block, the receive > socket buffer's upcall is not cleared. Is it fine to have this set when the > function soisconnected returns. I think the answer to question 2 above will > answer this too. Yes. Note that if the accept filter returns SU_ISCONNECTED, we goto again, which moves the receive socket from the listening socket's incomplete list to the complete list, which allows the new socket to be returned to userspace. Otherwise, if the filter returns SU_OK, it means that the filter needs to see more data before determining whether to accept the connection. When more data arrives in the receive buffer, sowakeup() will be called, and the accept filter upcall will be called again. If it returns SU_ISCONNECTED, we then call soisconnected() again, which will migrate the receive socket to so_comp. Actually, it is kind of strange that the second call to soisconnected() will call the accept filter again. I guess there is no other convenient place to clear SO_ACCEPTFILTER.