From owner-freebsd-net@freebsd.org Fri Oct 25 17:24:33 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 01510175EC3 for ; Fri, 25 Oct 2019 17:24:33 +0000 (UTC) (envelope-from dkandula@gmail.com) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 4709w066qXz3HwM; Fri, 25 Oct 2019 17:24:32 +0000 (UTC) (envelope-from dkandula@gmail.com) Received: by mail-io1-xd2f.google.com with SMTP id h9so3327399ioh.2; Fri, 25 Oct 2019 10:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YAIZVa/d2yJ4jnfW6fwwK98EGJlSGZH+Bf0vhfZ3/VY=; b=sxcQql9eZikFMB64TgI0/gmDx+aPoQv0hJg6ewdV2jKaMZG91sG7uA097oL9VOTkLD eYljqy3bZYN0HAP7r3ekQ9xKGeWC3icoEe8FKh5GLCHgjdAZacWu3hziezpCSQJDiRyk qseh9/oilTmPnEUn7W/LRwUpCaqdQxGzH1vdCeJNHQeyc7GlPAo0aNIigZft9kUcjlWF 7593KNVYZXGx/m/aDbr6bJvegZasHgr1z05x6fgS5RxX+BjnN8mDH7Vw4v7OFuCbRxXb ymIE0Cbl1SxQbN74VBDO5vC6i1KVL1YnnZsCJZMdrmBIUp7SzFEvKqDr9w+2ALW4erzw rggg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YAIZVa/d2yJ4jnfW6fwwK98EGJlSGZH+Bf0vhfZ3/VY=; b=C1b+k4O/9X4lLjwwn1c6Rk34TZUkzOSwYGcfgsrNX+sOFWILUq3e/k9D1OvChgRE65 jumFk1mW7wUl0qSD9/AVlilnVdzjzDMQko2HF5GDsYn/ZWtTRkH6fqQSL86O4/Jg4SPD a2HaXnL6QXe8C8EpLmM4kqjZW8Rv5zMvlGrCrPL5RJR5VQ1forN1JxbgPmOqs2QS56cb RY5LhAHkrHzbJ08KzI4A5kOxnGYMTrdzmq/yVT73d/4dXGWOPgPyJ0dBDPZnTvTY5WDQ lu1ebyMOKAa5wPm43YwUIskJBDSXyxx4YbA8Dd2MuqLBP3oRkmFbQxuNIYiu2U80qNGb WNKw== X-Gm-Message-State: APjAAAUmixhG7jYCbiCYPW3rq0UTP4FziVyTNxKzcw5BAe8CJ1MMo3Ip KYvRrIRC442Bv6Y6UJGIk/nIl+bcSiNH85bSqTvXHA== X-Google-Smtp-Source: APXvYqxIAeayH9ASoG3HJbyy/z56bMJwCG0jtCXap+iX0Gv8HiEBKP4A9byR44WVBSwoZZyT58kDxvSQyuBHdmidNhg= X-Received: by 2002:a6b:b886:: with SMTP id i128mr5004607iof.229.1572024271109; Fri, 25 Oct 2019 10:24:31 -0700 (PDT) MIME-Version: 1.0 References: <20191025161537.GB67949@raichu> In-Reply-To: <20191025161537.GB67949@raichu> From: Dheeraj Kandula Date: Fri, 25 Oct 2019 13:24:19 -0400 Message-ID: Subject: Re: soisconnected. To: Mark Johnston Cc: freebsd-net@freebsd.org X-Rspamd-Queue-Id: 4709w066qXz3HwM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 17:24:33 -0000 Thanks Mark for the clarification. Dheeraj On Fri, Oct 25, 2019 at 12:15 PM Mark Johnston wrote: > 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. >