Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4483933yba; Wed, 17 Apr 2019 12:28:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqyb3kIOz8vS90VcPXoZpe04e0ItMxThhB8Of2d4+1D273Xl0oSoHS1GjDDzfG412Tqqc1It X-Received: by 2002:a63:1a1b:: with SMTP id a27mr83375641pga.59.1555529314368; Wed, 17 Apr 2019 12:28:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555529314; cv=none; d=google.com; s=arc-20160816; b=UXGd5e3qTRZreB1pjrL16X13YQIAOrgw4vqyjswamHOtbXPuiNh0HQog8yNV7scw+d JonzFiP6cXGHu3HXTOCQpAz7mBa7TfJFVvKlKWNvjStCPPBGVBOSsp+jv3/jVJCuRxjw 48d1lpanJKpD1LS3DbAuT5y9D82mcZh4MvfSKumQnE5HoSYNKR+GpoPjD06HMqY+U/Ji TU43IkmNJmH8HmYzclPH6vYApLtIsbEOH8VP6vmk6o6J1pbPVNlcpSgXkPp1HZOBZU8g tbFNCH7kqVkqLbviKJE6N1XASXnZMJGwuy6rEaoeY/PNG316dtagiRnltmG+SvajUWoX WxqQ== 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:dkim-signature; bh=V++xunfQyx5HqwjAXgd31K7Me21LJ+w2CP6EKEHvb5g=; b=JZWam1wE1qSgaf8zZLD/FWKU1v5qwzP6m7O3hyrYfOmoJWvrXdf4td3kaDWStEzsWj cSpiycVe+5z6c9o0fezpFI7NiFyydymaXFdNW5iQUmfUDn/bZUR7RNStiqXttPAs4pTx Z39nNmtOu2ZTuk1FYXyTdCtUXu3XfwUwetSRzFmsUX0LhndjHs6VoDyXiOHlV+jbXoXH 6ed3KVTYaA9myZBHovuk7t0XVI7dYzyF0bfZ3qznFocvSh8UYFWSENmBb8KMkCKSJSL/ bcik9AJhtRyw+kGRsqgdKvboBDUfz1E/tfB1vaMQEctS25IbjhWKKU79J4IzkNGZqCAR KeVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=sEYWM3GF; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w10si48487678plz.37.2019.04.17.12.28.19; Wed, 17 Apr 2019 12:28:34 -0700 (PDT) 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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=sEYWM3GF; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387419AbfDQT1D (ORCPT + 99 others); Wed, 17 Apr 2019 15:27:03 -0400 Received: from mail-yw1-f67.google.com ([209.85.161.67]:35801 "EHLO mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732543AbfDQT1B (ORCPT ); Wed, 17 Apr 2019 15:27:01 -0400 Received: by mail-yw1-f67.google.com with SMTP id d132so9011670ywa.2 for ; Wed, 17 Apr 2019 12:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=V++xunfQyx5HqwjAXgd31K7Me21LJ+w2CP6EKEHvb5g=; b=sEYWM3GFOjveqnLmmV/m8t7Zmz1eLXxJNrRyM/47EIkG7U48BTtdYGfv5mNPVIhZj5 ydlXv7ZU+bOkuYELPU8V87hJLbQ6RM+9bNRXL0HEFaX/sy1RJSXLVOK9NOg/+suTYLcr pPCkzIuyXdqzA3r879dYbIXADhS+k4AJVsVJfSkJzL6xXep07lhb2aZYsEVFp2HY7ue0 k6MEApqF/6t/uzQI4EkEkz4WO8oSArLVCNZq5O9J5keNpf85ip3JnCeW7HpB1s91fJX0 ezs3/Q9rrt6/0YjKzBfJw6K8KJQ/V1U0/UaWgNyWTZKniGFoXII8J13Zh5oDRF7Ffn4M 5x6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=V++xunfQyx5HqwjAXgd31K7Me21LJ+w2CP6EKEHvb5g=; b=BC1VxoP9DCdFq36LZzsK54q/f3m/naWT3bMShLgN32xuyiBhj66yx8pEs7r2zymJUb MQE1ZSi/b4hkvbNWwcbxjuVy+9Eva0ScfyCFBsTgDyI6ybYyHivXqjkxDlDlA5iHLMdn D8diZRZuBFI6hspM5LxTaB0X9LZ4Po3stfOxl4+tcDpdj1pkuHN8OthT/M3jlMD4BkHg GaIkUgzHfXDCY2RW49SXpX8bs/rCtuVMv/5QpFTv0jfNASK90UHjbmccfiMicpRS0OZ/ /p9DxCXV9m8ccHRPJXnW1cGupi8NRLjfjIau3yba5JlMf7vBeEDoYeWp5Ln7VikU5OTi giEw== X-Gm-Message-State: APjAAAWHru0zbbi5lpEtAdtgSo1Fx7NMvWVGMwVwTEnWd3XCyLu648j0 eY12r8jz7XQ4qzwBCW5OnJI= X-Received: by 2002:a81:4d55:: with SMTP id a82mr72632019ywb.271.1555529220329; Wed, 17 Apr 2019 12:27:00 -0700 (PDT) Received: from localhost ([2620:10d:c091:200::3:556d]) by smtp.gmail.com with ESMTPSA id h131sm18444890ywa.80.2019.04.17.12.26.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 12:26:59 -0700 (PDT) Date: Wed, 17 Apr 2019 12:26:56 -0700 From: Tejun Heo To: Konstantin Khorenko Cc: Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RFC 1/1] kernfs: keep kernfs node alive for __kernfs_remove() Message-ID: <20190417192656.GE374014@devbig004.ftw2.facebook.com> References: <20190416155335.14627-1-khorenko@virtuozzo.com> <20190416155335.14627-2-khorenko@virtuozzo.com> <20190416191727.GD374014@devbig004.ftw2.facebook.com> <0469256f-7af9-c9cb-1c64-5d4bebfad095@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0469256f-7af9-c9cb-1c64-5d4bebfad095@virtuozzo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Apr 17, 2019 at 04:12:29PM +0000, Konstantin Khorenko wrote: > i don't know the full scenario unfortunately, but the idea is the following: > > __kernfs_remove() is called under kernfs_mutex and if > !(!kn || (kn->parent && RB_EMPTY_NODE(&kn->rb))) > > it assumes that nothing can change while we hold the mutex and > for each kernfs descendant should have kn->count > 0. > > ===== > /* deactivate and unlink the subtree node-by-node */ > do { > pos = kernfs_leftmost_descendant(kn); > > /* > * kernfs_drain() drops kernfs_mutex temporarily and @pos's > * base ref could have been put by someone else by the time > * the function returns. Make sure it doesn't go away > * underneath us. > */ > kernfs_get(pos); > ===== > > At the same time kernfs_notify_workfn() can do a kernfs_put() out of kernfs_mutex > which probably can be the last put and dec kn->count to 0 any moment. Yeah, but the caller of __kernfs_remove() should be holding the ref, so I don't see how it'd reach zero. Also, just putting that one kernfs_put() inside mutex can't possibly be the right solution given that the function is allowed to be called from any context. I think we need to understand what's going on better before making changes. Thanks. -- tejun