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 1FAB9C433EF for ; Thu, 2 Jun 2022 00:26:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232718AbiFBA0k (ORCPT ); Wed, 1 Jun 2022 20:26:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232709AbiFBA0h (ORCPT ); Wed, 1 Jun 2022 20:26:37 -0400 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B34F23511B for ; Wed, 1 Jun 2022 17:26:36 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id e11so3362425pfj.5 for ; Wed, 01 Jun 2022 17:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to:content-transfer-encoding; bh=y/gUgyMqWVcRsb+qEaGqa2cDEAVvpf+gfqD2gAKhZeo=; b=ItJwGzxeN7XJZuLKJ256vI76Qq2frqb9PjiPVfBOpWWW17LMKIqeeRXz/25pC8lXlQ GitrNQa5fCz82T6DMO0vkedLn7U6JEuYtbxflHVlzTWKVG+6DfJoQxGqYsnZ/+xP9M0k Y7vZ5P/Z+2irYU+pexBhC5bauIguFdJ0qJBwDxzCT1wlq/P3ppsnYXpBuS95KARPlcjP FlI6j+lIHVhfn+dpit9oxJno2DbgUK5gInvdPa2lFd/bs0Tl81/oY4zMhiGoGmRhLkd7 mYXwcPEN+ZjzzMbHQxFOX8qgBNv3rbCp12Yn+M6Pc2+80NKRZ26j2Va+6/pXWTomYiPn DoSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=y/gUgyMqWVcRsb+qEaGqa2cDEAVvpf+gfqD2gAKhZeo=; b=Y4livYD7qAk8dO3zDGZvgL0V9s8Tt5y1kZeNM6ZIgqjyFXsPkFbuSSfqEM3U8pycYq ukOhUPbPkwCxXf9RvzGLiMb4EBYMxzxh+jgIjLmZpo1d4dbfCpzKTxKWUplAeDZR2qnd 73/UY6/8rxQbOM09iIfNfQUTLY4BsDCGF4M796ulvUuFvyt2eqsE2YXy+AEY1CqDBril gUp+jvgw6g4m/WYlw+XvGU03R9pX2XpSQmajiLRY5rQ1tE8nhBzNsABes8xuLIZ5oJID NZA1aBYNhLqw/uG0csHvdMpoTVRnj3bLDoX2ZqiUr9BWRvfOC9XBjzbWOFuljBpT0Wyf RG9w== X-Gm-Message-State: AOAM5311L1H7bhJi/9g6vS0/7BoZnW0bsvMvUeZdJheGSU95rH6Ifcum QzwhoT2ngPj90hKroYQRd+wT7w== X-Google-Smtp-Source: ABdhPJyTDDferfqWzYFmGWnh7TdKImUbTnUOH9ymZWwxuTNL5eA0Ob24tCeayY4jYGH43fuUCbkSVg== X-Received: by 2002:a05:6a00:8c5:b0:510:6eae:6fa1 with SMTP id s5-20020a056a0008c500b005106eae6fa1mr2145386pfu.12.1654129595907; Wed, 01 Jun 2022 17:26:35 -0700 (PDT) Received: from [192.168.254.36] ([50.39.160.154]) by smtp.gmail.com with ESMTPSA id y27-20020aa793db000000b0050dc762818asm2013338pff.100.2022.06.01.17.26.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jun 2022 17:26:35 -0700 (PDT) Message-ID: <416dc60a-f0e5-7d05-1613-3cd0ca415768@linaro.org> Date: Wed, 1 Jun 2022 17:26:34 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: Tejun Heo Cc: =?UTF-8?Q?Michal_Koutn=c3=bd?= , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Zefan Li , Johannes Weiner , Bui Quang Minh References: <20220525151517.8430-1-mkoutny@suse.com> <20220525151517.8430-3-mkoutny@suse.com> <20220525161455.GA16134@blackbody.suse.cz> <0babd7df-bdef-9edc-3682-1144bc0c2d2b@linaro.org> <1fb4d8d7-ccc0-b020-715e-38c2dfd94c23@linaro.org> From: Tadeusz Struk Subject: Re: [PATCH 2/2] cgroup: Use separate work structs on css release path In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/1/22 17:07, Tejun Heo wrote: > Hello, > > On Wed, Jun 01, 2022 at 05:00:44PM -0700, Tadeusz Struk wrote: >> What I'm trying to say is that it's not really a ref imbalance problem. >> I think once the kill_css() has been called on a css, and it is enqueued to be >> killed, we shouldn't call css_put(css) on it anymore outside of the "killed call >> flow path". It will all be handled by the css_killed_ref_fn() function. >> >> The fact the css_release() is called (via cgroup_kn_unlock()) just after >> kill_css() causes the css->destroy_work to be enqueued twice on the same WQ >> (cgroup_destroy_wq), just with different function. This results in the >> BUG: corrupted list in insert_work issue. > > I have a hard time following here. The kill / release paths relationship > isn't that complicated. The kill path is invoked when the percpu_ref's base > ref is killed and holds an extra ref so that it's guaranteed that release > can't happen before the kill path is done with the css. When the final put > happens - whether that's from the kill path or someone else, which often is > the case - the release path triggers. If we have release getting scheduled > while the kill path isn't finished, it is a reference counting problem, > right? > > Can you elaborate the exact scenario that you think is happening? Please > feel free to omit the function calls and all that. Just lay out who's doing > what. Ok the problem is that 1. kill_css() triggers css_killed_ref_fn(), which enqueues &css->destroy_work on cgroup_destroy_wq 2. Last put_css() calls css_release(), which enqueues &css->destroy_work on cgroup_destroy_wq We have two instances of the same work struct enqueued on the same WQ (cgroup_destroy_wq), which causes "BUG: corrupted list in insert_work" So I think the easiest way to solve this would be to have two separate work_structs, one for the killed_ref path and css_release path as in: https://lore.kernel.org/all/20220523212724.233314-1-tadeusz.struk@linaro.org/ -- Thanks, Tadeusz