From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FB8CCD8CAC for ; Tue, 10 Oct 2023 18:41:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232771AbjJJSl3 (ORCPT ); Tue, 10 Oct 2023 14:41:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234046AbjJJSl1 (ORCPT ); Tue, 10 Oct 2023 14:41:27 -0400 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26F90F2 for ; Tue, 10 Oct 2023 11:41:18 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1c9bf22fe05so5968565ad.2 for ; Tue, 10 Oct 2023 11:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696963277; x=1697568077; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=ijrsUTj+r62nW8Q1jCkejeshJ7JM+2vy3io9P9umRno=; b=YkQdlNQjQ5jm/mF/BTbVGjNbtTCblqI8c0yv69VLu+Vg5WnREhya70vsgqUiZjZwuv t+uEjQbq9c+Mz0oRmqaaR978vgpCwoclbBkX5A6rdzPjtix7ZM410sjAW/3R2m3yOceF +PRV5UBXwbf7YREwkhpLSxQkLcaGnp9IQXFaGUy1nWBXHbGhgdZg1U4O1z5fhcSa88/F wLE14+LQ0VTvZ71eYgGP/Y4Dq+lrSVVcJWW7hho3qcJS3thgys7D5k4WGLaf6oVVQBxP XXYohu9xwEuQAzGCdUdVZkNw/EctUptTjwCZ4REkzOx8PuaKDF7t5p1coaUgTI4kUhf7 +GTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696963277; x=1697568077; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ijrsUTj+r62nW8Q1jCkejeshJ7JM+2vy3io9P9umRno=; b=vjgQnMbXPciuFN6XuzNUi2bK4RSajNSSVoJwlKVfu3aXXpgFTcHhCpWDVDylRa6vJi IHOAHDYzevKXARlsKP3J3VGDeOwy31hZoriCQR15G9zIsqnmddiQdAMMJhe88MIWFO1C hB56HOD9XxByj2FumfDm0llAt9hVfs4c4xuBKzVpg3G6J6mdePowDkgZvHHhUm+9FeIe +eNWyxkIPbzzlfK6rlDKES89StJ2P+wM+qrsLbMPLcfX3jGq2OJR2N0Uk1rHIHUWmXlS p0T92BeYcv0rj0j03FVvwiPh1mj/Aoz2a91/n1ix/wJm1FCX9hSpmlOUQhqxAQVmWSKV k17A== X-Gm-Message-State: AOJu0Yx2dwiOisOm8DZ+IdJZlsiY8/83bN56i/9sPhUBB9gzsyHlxx/L G4Ewf6/bN+rdqII5HYLcG0Q= X-Google-Smtp-Source: AGHT+IEtcEMdF1XUIaVm1G3tS8QDoJNv42CVuhjxt5JGhWEZtmRtPTOhT1sCzp4AqAaVEJIkwaXPoQ== X-Received: by 2002:a17:902:f54e:b0:1b7:e49f:1d with SMTP id h14-20020a170902f54e00b001b7e49f001dmr21681539plf.62.1696963277362; Tue, 10 Oct 2023 11:41:17 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::4:cced]) by smtp.gmail.com with ESMTPSA id d3-20020a170902c18300b001a5fccab02dsm12178474pld.177.2023.10.10.11.41.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 11:41:16 -0700 (PDT) Sender: Tejun Heo Date: Tue, 10 Oct 2023 08:41:15 -1000 From: Tejun Heo To: "T.J. Mercier" Cc: Michal =?iso-8859-1?Q?Koutn=FD?= , cgroups@vger.kernel.org, Zefan Li , Johannes Weiner , Suren Baghdasaryan Subject: Re: [Bug Report] EBUSY for cgroup rmdir after cgroup.procs empty Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: cgroups@vger.kernel.org Hello, On Tue, Oct 10, 2023 at 10:14:26AM -0700, T.J. Mercier wrote: > > BTW is there any fundamental reason the apps cannot use the > > notifications via cgroup.events as recommended by Tejun? > > > This would require that we read both cgroup.procs and cgroup.events, > since we'd still want to know which processes to signal. I assumed > this would increase lock contention but there's no synchronization on > cgroup_is_populated so it looks like not. I had already identified > this as a workaround, but I'd prefer to depend on just one file to do > everything. I don't think we can guarantee that. There's a reason why we have [!]populated events. Maybe we can find this particular situation better but there isn't going to be a guarantee that a cgroup is removable if its cgroup.procs file is seen empty. Note that cgroup.events file is pollable. You can just poll the file and then respond to them. I don't understand the part of having to read cgroup.procs, which btw is an a lot more expensive operation. You said "which processes to signal". If this is to kill all processes in the cgroup, you can use cgroup.kill which sends signal atomically to all member tasks. It feels like the use case is just trying to do things in an unsupported way when there's no actual benefit to doing so. Is there something preventing you guys from doing how it's supposed to be used? Thanks. -- tejun