Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [V2][PATCH] cgroup: fix memory leak caused by missing
 cgroup_bpf_offline
To:     =?UTF-8?Q?Michal_Koutn=c3=bd?= <mkoutny@suse.com>
Cc:     Ming Lei <ming.lei@redhat.com>, Tejun Heo <tj@kernel.org>,
        Zefan Li <lizefan.x@bytedance.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Jens Axboe <axboe@kernel.dk>, Roman Gushchin <guro@fb.com>,
        cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, bpf@vger.kernel.org
References: <20211018075623.26884-1-quanyang.wang@windriver.com>
 <YW04Gqqm3lDisRTc@T590> <8fdcaded-474e-139b-a9bc-5ab6f91fbd4f@windriver.com>
 <YW1vuXh4C4tX9ZHP@T590> <a84aedfe-6ecf-7f48-505e-a11acfd6204c@windriver.com>
 <YW78AohHqgqM9Cuw@blackbook>
From:   Quanyang Wang <quanyang.wang@windriver.com>
Message-ID: <4644b5eb-8acf-45ef-e33e-84eee6394a57@windriver.com>
Date:   Wed, 20 Oct 2021 13:16:01 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
In-Reply-To: <YW78AohHqgqM9Cuw@blackbook>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NTBwc3d2d0grbDZFYjczdndydjRtdDVLMytxczZrQ2JQY2EzbXFCMzRndTB5?=
 =?utf-8?B?ejFPOTJxSm1HZ1gxcjVHdURWRlc3ei80Qk1CeDNlbXFHaklWdDV2aHlIU0VS?=
 =?utf-8?B?TmVuSnJkZE5reldLVFErMDBhWXJtZC95NUxkUTdQaFJqdWxUYVZLNldaNytQ?=
 =?utf-8?B?NWhvMGdPSE1DaFQ0ZDM1SFBaTFpRR3Vja0d0ZVRBa2ZDNStpNjFsSXQxazAv?=
 =?utf-8?B?aGZZMEZ3QlNFWUFTbUMzdUtLbTVxdEMxejRoRFY2b2FDUWVHWVRYZGl5TzZQ?=
 =?utf-8?B?dDkxQnYxVUovclA2TTMyWDlsOUQ1SlRHdkJnNEozbVB6bkJkNkZkRlNCZ2Nt?=
 =?utf-8?B?TzdYaEpocCs4Z211K1Z4Q0hqVU9jZWUwK2ZraWFhcXVPNE55ekM3VmxZQzBk?=
 =?utf-8?B?RTgvaVA1dEtjblRnNTdZeGFGVDd4TnB2RjAwU2tCOE55a0htUHc5TUNvWlZR?=
 =?utf-8?B?YXROMW5RNFRBM0MxU1dFdXN1M0NndFBVSDB6WkkzWklBcmZOalFPV1FVN0Z3?=
 =?utf-8?B?M1lxS3p4WUxMZXo0OTgwWHZZZUYxWGh0SGZBNmlLMU1PK25iZHJOVDV1M2dh?=
 =?utf-8?B?a2l0UnNXcDJvc0JsUUJvTS9EQ2tHNXltZnRGYkJBQ2xhSDNSb2F6b2JJVUxw?=
 =?utf-8?B?a01HYWd5dHlUVXVjSk5IbHkyMTVvMFB2Y1ZVUGpaZGxYTkRFVENSbm9WMnAy?=
 =?utf-8?B?VFpkVFVnU2JBVmJSeDJZV2N4Y05mMER1aHl2ZFBwWDV2alhXdHRtVjA0aFR0?=
 =?utf-8?B?K2ZtbXBMS2wvRGttbkZFd1U3dU9xSDFvRUNrRzQwUTQ5cnRKZzlycGlldWpF?=
 =?utf-8?B?NS96MUR3aFhsTTByQlpzMktZcmZtRXMvem55UWFJalljRTZHdGdXUkZHWEdJ?=
 =?utf-8?B?UHlLamFISjgrMkNMNklXZ3BhL21LMGRLY3VCdEs5N1I2YXIyOE4wZTlHdEor?=
 =?utf-8?B?cnZnMFRKbWplSWpJODd3QWJabWhRQnd1VVlWNjJ2M2F2enJrc2JXdkZJbGow?=
 =?utf-8?B?U2FEbE4vQzk5aEdId2R1VEwrYVRqZmxUaFYwSjNVQ3JJeVhQdGFzQ2ltS0tl?=
 =?utf-8?B?ZWNqRzlLUVJTT21TUHdLL3BMUmxCT1VKaUlxMHd1bWJFWEtZSmFLWW1qcHFl?=
 =?utf-8?B?YkZHNk5xRGs0cnEvQkEyVlhLNXNyYXp1VCtrL2Q5ZWRRalBTaWM1ZzRHMnQy?=
 =?utf-8?B?eHFRNkR6NTJmZkhsRytaRGNNdkdnTHkzMThhN0VmdEtxZDZsSk9zR2tQdFh2?=
 =?utf-8?B?L0tabE83a29WWEdLYU50NlI0cWNyWWcyaXpJQ094UllsUXhpV3JwQTdEMEFt?=
 =?utf-8?B?REFoUE1HOXdwc2Nrb0tXUHh4QlNGYmNJNTRmcVB2T085NWFzT3JORWZLamFr?=
 =?utf-8?B?RWZKdm5zVmdvTklsclpBOVpkR0pMWWc4RzFqc3R0cnA5U21XK3dISFNySURS?=
 =?utf-8?B?ZFNTcUs5L0g3VXhCN0l6blVTQXpIclNUVkp0T05ka09BeW5HL1hWQWxjL01Z?=
 =?utf-8?B?RjhHdjlvRnBpN0NWWWdWdk5HQjREWWMybWtWM3BBaGtwZnpaR0JMYlo3dXc5?=
 =?utf-8?B?RTRLbnphUGU4TXV0Y1g3VThxdytGZTJpYnRRb3NPbThZS2NPcThrS2o1Wmxt?=
 =?utf-8?B?eXV6RE1Ia0dvOEZ6c0ttVWR3aGtadnVmWXRsWlJZT1VjUzh0dWhVUnRHMWRX?=
 =?utf-8?B?SS94a200UVViYndhVDhDTnhhOG05S0MrL2Q4VFlIMDVKTTRwSnF1OXE4OTU3?=
 =?utf-8?Q?ANLy2cr47QMB8uG/f3VNStRt2q/vVcml6gag/SB?=
X-OriginatorOrg: windriver.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ed7f08c2-66b6-4203-8d75-08d99388beb9
X-MS-Exchange-CrossTenant-AuthSource: PH7PR11MB5819.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2021 05:16:17.5865
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: quanyang.wang@windriver.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5062
X-Proofpoint-ORIG-GUID: 3n8kghCID_sEZgJzgZDBtRIYXfLOryNn
X-Proofpoint-GUID: 3n8kghCID_sEZgJzgZDBtRIYXfLOryNn
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475
 definitions=2021-10-20_01,2021-10-19_01,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=720
 impostorscore=0 suspectscore=0 clxscore=1015 priorityscore=1501
 adultscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 malwarescore=0
 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2109230001 definitions=main-2110200027
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Michal,

On 10/20/21 1:10 AM, Michal Koutný wrote:
> Hi.
> 
> On Tue, Oct 19, 2021 at 06:41:14PM +0800, Quanyang Wang <quanyang.wang@windriver.com> wrote:
>> So I add 2 "Fixes tags" here to indicate that 2 commits introduce two
>> different issues.
> 
> AFAIU, both the changes are needed to cause the leak, a single patch
> alone won't cause the issue. Is that correct? (Perhaps not as I realize,
> see below.)
Yes, I back to the earlier commit 4bfc0bb2c60e and no memory leak is 
observed.
> 
> But on second thought, the problem is the missing percpu_ref_exit() in
> the (root) cgroup release path and percpu counter would allocate the
> percpu_count_ptr anyway, so 4bfc0bb2c60e is only making the leak more
> visible. Is this correct?
No, the earlier commit 4bfc0bb2c60e introduces a imbalance and the later
commit 2b0d3d3e4fcf introduces a visible leak.

Thanks,
Quanyang
> 
> I agree the commit 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of
> percpu_ref in fast path") alone did nothing wrong.
> 
> [On a related (but independent) note, there seems to be an optimization
> opportunity in not dealing with cgroup_bpf at all on the non-default
> hierarchies.]
> 
> Regards,
> Michal
>