Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3315483yba; Tue, 16 Apr 2019 08:54:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqwgDJlJUpz1v3pADrMm1PfZ0SD0g5qBzovrq+Nt6UO3B1YcDf8VtByLVsd1zk3qi5bZZsuX X-Received: by 2002:aa7:8609:: with SMTP id p9mr83055328pfn.166.1555430071379; Tue, 16 Apr 2019 08:54:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555430071; cv=none; d=google.com; s=arc-20160816; b=aZuM+LhCk6GcSunUsSXmpX7jIUGjUj7yjapIS1284mrtjxvUvxX4+DJ20U9EtSMb0J eobfLKNvCEz0rdaT4Kut4oSn40AuX5SuHgzbrl1zdcATf88OUBjDGNtGOEDYkSl3Sai2 IKHeIc4bc8IoLD/fA/i9YND9SUivyJw09AxAduCevjH9JcnkYAaUXVZIRo0Zu77jHFtV YYjJTtgOldtg18ftdsny4wiDa6zs5PMFekCmcreQjCX6KRcl1NYd/C4BXmZSuozhhO4I bzkkT/46T3FQcI8RUOIyQ7To8ur8uppADGo4ZRBiuQPwkBG8vBZwTQSzO2aEkS6I8wpl ir1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=TaCROpRxi2QTlwePGIDiyl1HJI4bB3qPFw8ezdfYZEk=; b=FPpP/ztX9E9IsN+k9kTWkhHVa2fsbP1dFOj46Dxjf5kgFc1/qEEnFhWAeKXM1CCBmM OkI5qjN4gLhIC8g1atMH9mMeUJrvyTK5utJznyB1kDj93xsY6ORlzqAl/SSFRIfxKP0X zToypELnptrF2vKFHrLN2es66kwlqhCA/C/jf52LTOhpMPi+dpS1erosN8N459uUVwVF lGGdqGQyNzz/njxpfjWS3fD+lEcm0jiXMeR+65ttoQYa2oTG2CyFpNIgxMb9siHczE8M A23vdgJjnwoY5isET4SBBk47o+vSrnc6UUdcYYzKDVpjh4nX00SigIMXOlVLIYV4Lfju KwHA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j7si49181135pfb.75.2019.04.16.08.54.14; Tue, 16 Apr 2019 08:54:31 -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; 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=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729553AbfDPPxl (ORCPT + 99 others); Tue, 16 Apr 2019 11:53:41 -0400 Received: from relay.sw.ru ([185.231.240.75]:57634 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726796AbfDPPxk (ORCPT ); Tue, 16 Apr 2019 11:53:40 -0400 Received: from [10.94.4.83] (helo=finist-ce7.sw.ru) by relay.sw.ru with esmtp (Exim 4.91) (envelope-from ) id 1hGQOu-0001Ss-2p; Tue, 16 Apr 2019 18:53:36 +0300 From: Konstantin Khorenko To: Tejun Heo , Greg Kroah-Hartman Cc: Konstantin Khorenko , linux-kernel@vger.kernel.org Subject: [PATCH RFC 1/1] kernfs: keep kernfs node alive for __kernfs_remove() Date: Tue, 16 Apr 2019 18:53:35 +0300 Message-Id: <20190416155335.14627-2-khorenko@virtuozzo.com> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20190416155335.14627-1-khorenko@virtuozzo.com> References: <20190416155335.14627-1-khorenko@virtuozzo.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org __kernfs_remove() which is called under kernfs_mutex, assumes nobody kills kernfs node whie it's working on it and "get"s current kernfs node for that. But we hit a warning in kernfs_get(): kn->counter == 0 already: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 63923 at fs/kernfs/dir.c:377 kernfs_get+0x2f/0x40 ... Call Trace: [] dump_stack+0x19/0x1b [] __warn+0xd8/0x100 [] warn_slowpath_null+0x1d/0x20 [] kernfs_get+0x2f/0x40 [] __kernfs_remove+0x113/0x260 [] kernfs_remove+0x21/0x30 [] sysfs_remove_dir+0x50/0x80 [] kobject_del+0x18/0x50 [] sysfs_slab_remove+0x3d/0x50 [] do_kmem_cache_release+0x3b/0x70 [] memcg_destroy_kmem_caches+0xb1/0xf0 [] mem_cgroup_css_free+0x4c/0x280 [] cgroup_free_fn+0x4c/0x120 [] process_one_work+0x182/0x440 [] worker_thread+0x126/0x3c0 [] kthread+0xd1/0xe0 This could be for example because of kernfs_notify_workfn() which does kernfs_put(kn) out of kernfs_mutex held section, so move kernfs_put(kn) under the mutex. Signed-off-by: Konstantin Khorenko --- fs/kernfs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c index ae948aaa4c53..ab9c7e2064cc 100644 --- a/fs/kernfs/file.c +++ b/fs/kernfs/file.c @@ -915,8 +915,8 @@ static void kernfs_notify_workfn(struct work_struct *work) iput(inode); } - mutex_unlock(&kernfs_mutex); kernfs_put(kn); + mutex_unlock(&kernfs_mutex); goto repeat; } -- 2.15.1