Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1018520ybl; Thu, 12 Dec 2019 08:26:06 -0800 (PST) X-Google-Smtp-Source: APXvYqwTUdXjZYer387R5sbbZSVrI/rReV5cE7xkPXaRo4NXWOg5w0kYx0a9hPl3bxzF0eEv9+5Y X-Received: by 2002:a05:6830:87:: with SMTP id a7mr8722803oto.314.1576167966777; Thu, 12 Dec 2019 08:26:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576167966; cv=none; d=google.com; s=arc-20160816; b=yiBlFolRxcWlCxx4LorrAK9KVSlnJiDntdDNMlV3sAEDzutIgC4C2jwjK2yv8HQkNJ PBf8nPrN0Pe8KQVSle8c4s1DWO1Trva1Q6kk+7ljDXk/QZcPqBc0S0Ywnrd0JbnisZDu G7lEt9hD5GGGFcBh/IdTJDZENTR3pFKtFy12x2X5jYLydSLgYkjM4BH903tYKwXMjirx Jl/GW/sUhSdsg3gyCDohhwPhUrjLnCxNJx54vOw38J8Qt+JsmTCUEGHu83cuqkzHwhiv jBlWP4nAA3tSJ083hvWP2jCp8/p66az/p1ZbK2e3EXmy+LhNjXzRwNqDKfC4fFkfQwiW 4DeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xJs2LmLedSt4Mbj9k+8tvJ8qBB1oTvLSFC+oBVcc5nQ=; b=iO6cKLD7i2mlPpQuKAH5zkZpx1TMplsn1fuqAZKDzWgUq/RZGpic4KuGisuzcTR0St uIHDWx718oTes2CcCOsUY77NhVSGMrMEYJZ9NT3vldtr1TwRuzgmyg06+CW3/m7ZSXsm UIzGmT+NfH0P2pdTGABiSUgtlHKU3NelQPCeY1w9dYOjGnli4aWbFNuI/avrb/pEi4tE lJ8c9BC+d511k//9Fv1ipKeZPQ9uG/FQHZQGawfLi5bywlkM22LnPU81n8ackAog4tWI gn8/Ynln4lBrZlxvYsh7xqaSyDV+nX4aPMHXiGLyVdWKDHE1MsIdpgLuwFgac5ZiwxAc IMvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h6si3371097oie.215.2019.12.12.08.25.51; Thu, 12 Dec 2019 08:26:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729905AbfLLQZR (ORCPT + 99 others); Thu, 12 Dec 2019 11:25:17 -0500 Received: from www62.your-server.de ([213.133.104.62]:58954 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729762AbfLLQZQ (ORCPT ); Thu, 12 Dec 2019 11:25:16 -0500 Received: from [194.230.159.122] (helo=localhost) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ifRH7-0007Wx-UN; Thu, 12 Dec 2019 17:25:14 +0100 Date: Thu, 12 Dec 2019 17:25:13 +0100 From: Daniel Borkmann To: Jakub Kicinski Cc: Sasha Levin , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Andrii Nakryiko , Song Liu , netdev@vger.kernel.org, bpf@vger.kernel.org, oss-drivers@netronome.com Subject: Re: [oss-drivers] [PATCH AUTOSEL 5.4 326/350] bpf: Switch bpf_map ref counter to atomic64_t so bpf_map_inc() never fails Message-ID: <20191212162513.GB1264@localhost.localdomain> References: <20191210210735.9077-1-sashal@kernel.org> <20191210210735.9077-287-sashal@kernel.org> <20191210132834.157d5fc5@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191210132834.157d5fc5@cakuba.netronome.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.101.4/25661/Thu Dec 12 10:47:42 2019) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 10, 2019 at 01:28:34PM -0800, Jakub Kicinski wrote: > On Tue, 10 Dec 2019 16:07:11 -0500, Sasha Levin wrote: > > From: Andrii Nakryiko > > > > [ Upstream commit 1e0bd5a091e5d9e0f1d5b0e6329b87bb1792f784 ] > > > > 92117d8443bc ("bpf: fix refcnt overflow") turned refcounting of bpf_map into > > potentially failing operation, when refcount reaches BPF_MAX_REFCNT limit > > (32k). Due to using 32-bit counter, it's possible in practice to overflow > > refcounter and make it wrap around to 0, causing erroneous map free, while > > there are still references to it, causing use-after-free problems. > > I don't think this is a bug fix, the second sentence here is written > in a quite confusing way, but there is no bug. > > Could you drop? I don't think it's worth the backporting pain since it > changes bpf_map_inc(). Agree, this is not a bug fix and should not go to stable. (Also agree that the changelog is super confusing here and should have been done differently to avoid exactly where we are here. I think I pointed that out in the original patch, but seems this slipped through the cracks :/) Thanks, Daniel