From nobody Fri May 24 15:43:47 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vm8Th0H5Wz5LHqv; Fri, 24 May 2024 15:43:52 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vm8Tg6mFNz3yHS; Fri, 24 May 2024 15:43:51 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1716565431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/pbbCIZ0wS57HGXKb0z2dc02ep+kZYmVz7tMIl8yoNo=; b=ikKq2upobeHACI3BFbJmYDtvSlCkd5noMDTE0LVLqThy/VLe1b7u0LFQ5PVu6q16KiuMn8 fcQnqIVbF3sJIRoOzgcHy3cgN7iGOQhrpRq9op9+ML1moiABFSzsSnyMg95GhybKIbrJRR bX9nboJKA2On9n++7H7hZ2+0Evo8HIyiaAaUrQ/fs2c4tlgKk5eezKoTxlfQfsMqA2veYa HHYMqvBOn+dZPS3EpIqRzDDY1jEqVMgTFdyPNhmYO++IkoCfwTrCG28nbpaa3AinDO/DLA IPidR5xoC088AZbXSh4OHDFCeodMIsCbnn6R0EcZMkixT7otozrvy2FMSNz+ZA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1716565431; a=rsa-sha256; cv=none; b=DwRty+054ZNmqyGOzB+9s8ZHdIx9dO4c5idMkCM3xETPFw8FCQnDcfmgMenxpinkRACM+X HPXnjHDz4VvUTkgcZk/g5TDyJG9aYraWsmyM4XBxmmF4HPo0LmGdR10NdQo5+U0u3/6uFf Fgxj9i/UZcjWiSzo1bQtzFF1g5+5bkcEGHQy5csSPc1MCE5crJVw6zFos5CA6EYkcxqUiM IM4zEafucVLgb0EEhYU4rrFMW4roDRWMx8Qo0PgGQI1Hfp8fLgzg1e4fyOx+fWr8ZsqXVl Sa20Gple17zhamiArPVYz7j906gK6ksEFkA9uE3dic1wXiYKz7owQGhLoeq8rQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1716565431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/pbbCIZ0wS57HGXKb0z2dc02ep+kZYmVz7tMIl8yoNo=; b=ZqIVnyFG/fVnHkXjqOxurNGqkiKX6nNgURYyJtw0K9Edywl9jQDbGNpgzTtjVMTlWy3QfS /aXwSoXhKCSz2VqRwpQOY8K9JRtUj5ydNLkHFqDD+xE3hjkbny0YcCbZAUlJCEZrYK5Tkn I68s/P/oyCVtXdkRWM5QjRDBSGT/s08FgBJdfSJ8k1RjuYo2/6xV2phvEjwmi4YN+FamRZ Uo5VT5ATbZasZpvZ4JQPDIfNAJ7ooih1BQi5QZ7AXP2CnNBVlSrxGo2sTrY8y/D6kAb+VT eeDdqDyq9MqMaMgRrPZEsbCaCZdeLxi3dX+J7rKGaqWjVUyqqEoZXmvvfAT+Rw== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Vm8Tg1t37z10rF; Fri, 24 May 2024 15:43:51 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 24 May 2024 08:43:47 -0700 From: Gleb Smirnoff To: Ravi Pokala Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: 0d3789584915 - main - ctl: use socket buffer mutexes in struct socket directly Message-ID: References: <202405231912.44NJCLja032047@gitrepo.freebsd.org> <1B513920-69CF-434E-B5A1-45960CB99246@panasas.com> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B513920-69CF-434E-B5A1-45960CB99246@panasas.com> On Thu, May 23, 2024 at 12:21:23PM -0700, Ravi Pokala wrote: R> Hi Gleb, R> R> Isn't this the exact opposite of the summary? This change *doesn't* use the mutexes directly, it uses the wrappers to *avoid* using the mutexes directly. SOCKBUF_LOCK(&so->so_rcv) locks via pointer in the buffer to the socket. SOCK_RECVBUF_LOCK(so) locks directly in the socket. -- Gleb Smirnoff