From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 60476A04BB; Tue, 6 Oct 2020 10:59:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 477D811A4; Tue, 6 Oct 2020 10:59:23 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 714DFB62 for ; Tue, 6 Oct 2020 10:59:21 +0200 (CEST) IronPort-SDR: 2wqBobbN2qjbNEdgKofeMRz3AaN7nncebyatqTjXPXOzzeoTjvKQzYK/l85TP5jVFEuF2ogqHC AKStKLRdJX1g== X-IronPort-AV: E=McAfee;i="6000,8403,9765"; a="228552472" X-IronPort-AV: E=Sophos;i="5.77,342,1596524400"; d="scan'208";a="228552472" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2020 01:59:19 -0700 IronPort-SDR: WyBb4yKvrrWs85/Ij7daSFwSd12C79rPiSO/qO35UwQJXt9WW+++yqsfT0h8GKStY8Hnh9GwTz IdPeVjxu+ADA== X-IronPort-AV: E=Sophos;i="5.77,342,1596524400"; d="scan'208";a="342150868" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.241.102]) ([10.213.241.102]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2020 01:59:17 -0700 To: Stephen Hemminger Cc: Jakub Grajciar , dev@dpdk.org References: <20201005123900.32723-1-jgrajcia@cisco.com> <5b874482-baaa-1a65-b101-983aa3bff5ee@intel.com> <20201005111711.1e78ee0d@hermes.local> From: Ferruh Yigit Message-ID: <31904846-f2ad-0ee6-26e1-d01e8dd2b362@intel.com> Date: Tue, 6 Oct 2020 09:59:14 +0100 MIME-Version: 1.0 In-Reply-To: <20201005111711.1e78ee0d@hermes.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net/memif: use abstract socket address X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/5/2020 7:17 PM, Stephen Hemminger wrote: > On Mon, 5 Oct 2020 14:09:20 +0100 > Ferruh Yigit wrote: > >> On 10/5/2020 1:39 PM, Jakub Grajciar wrote: >>> Abstract socket address has no connection with >>> filesystem pathnames and the socket dissapears >>> once all open references are closed. >>> >>> Memif pmd will use abstract socket address by default. >>> For backwards compatibility use new argument >>> 'socket-abstract=no' >>> >> >> Why this backward compatibility is required? How the end user affected from >> swithching to abstract sockets? > > It would only matter if mixing applications with different versions. > >> Since when linux supports abstract sockets, does this switch will cause problem >> with old kernel versions? > > This is not new, it dates back to Linux 2.4 or earlier. > >> >> Is there any benefit of the abstract sockets other than socket cleaned >> automatically (I assume for unix sockets it is done when file filesystem >> reference removed)? > > The big one is that applications don't have to blindly unlink the old filesystem > remnant. This means that if application can't bind it means another application > is still running with that name. So abstract sockets are safer. > > > Abstract sockets are not pathnames so they get handled differently by security > systems (like SELinux and AppArmor). This can be helpful in containers. > Hi Stephen, thank you for clarification.