Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3316588yba; Tue, 16 Apr 2019 08:56:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqyqLkrVJ+kgw/bSzIxoxskug/32CaFS5SWmNzd4o+VIfql0AsuvlUsAEEvgvxAm0Kau4DNx X-Received: by 2002:a63:e20b:: with SMTP id q11mr78846623pgh.263.1555430161716; Tue, 16 Apr 2019 08:56:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555430161; cv=none; d=google.com; s=arc-20160816; b=HvVekLI7Tz0HofwiZLt4E3QoWfsUf0L6zAUeTMW9iFLEz22pDBXVCritn7EX1xvI1b qgJC1p8V0J3MEPIqKjaidQm8DK3ckmTgDt+Igvm+ZnfGHaNH1RHlyEGJHEU1Qauh2ZHy zIwXjRZ0fKSZ/1OZL2h0fDzoHjAO9t/L4bxzDJq9q0O7wk4DM4v51/vZ60C1edaAJubN 4EAYch4agJ1ofw8KrKeAx6Ih3lfQbWFPZrHy233k5frW9UikO/TQcLffahEehtan1whS bu8Q/P2Jk/jMxoUhBqK9Ayn7VUiUR40V9ezjaJBX9ERZHx4y4XMVG4ucotCCXP37ia+/ jFGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=pZyTK2rb7mXwP7jHOObjGvABZOtSLzro/4l0Fe+p22I=; b=usPEh88xBwcpVDskMgxyqshRShf7AbMSoK3OuKG2oU8WeCnN/7mHVzj2zXjPTo4kCn 2HBrdVeuGkBGtfpM4dDN7fXz9U5d+lCZcocYSyMGBvC+qlXxCuQ6Bfa5EPHb8+kv7Hjl v6CGQpfM0iMOcrwJDdssoNo6iqwx42YzPKihDTBTRQ1ZXz/PEm5GF1m/c+B+VOR8yEfM ciwyzVj/xH0mv/kHq39VsG+gLAdqtlQLPJ+gJL9EyCkoiGn7b3fbw6VkDjUx0E1xPOSR ISP3i6IhLGwCPyPOQ2W51vFcIs0zQPchACXpD2vqFoeodcQ6escJrfwq4qIdHjGzjsM/ 6ByA== 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 g8si48237282pgn.92.2019.04.16.08.55.46; Tue, 16 Apr 2019 08:56:01 -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 S1729168AbfDPPxk (ORCPT + 99 others); Tue, 16 Apr 2019 11:53:40 -0400 Received: from relay.sw.ru ([185.231.240.75]:57632 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726645AbfDPPxk (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 1hGQOt-0001Ss-NH; Tue, 16 Apr 2019 18:53:35 +0300 From: Konstantin Khorenko To: Tejun Heo , Greg Kroah-Hartman Cc: Konstantin Khorenko , linux-kernel@vger.kernel.org Subject: [PATCH RFC 0/1] kernfs: hit a warning in kernfs_get() Date: Tue, 16 Apr 2019 18:53:34 +0300 Message-Id: <20190416155335.14627-1-khorenko@virtuozzo.com> X-Mailer: git-send-email 2.15.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We hit a warning on rather old kernel - RHEL7-based 3.10.0-xxx. Please don't think it's really near 3.10 - both RedHat and we (Virtuozzo) backport a lot of things from modern mainstream kernels and do own changes. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 63923 at fs/kernfs/dir.c:377 kernfs_get+0x2f/0x40 CPU: 2 PID: 63923 Comm: kworker/2:7 ve: 0 Kdump: loaded Not tainted 3.10.0-957.10.1.vz7.85.12 #1 85.12 ... 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 The warning has been triggered only once and so far i'm unable to reproduce it. i'm not completely sure why __kernfs_remove() believes "pos" should always have kn->counter > 0 as it holds kernfs_mutex, but kernfs_notify_workfn() could definitely do a kernfs_put() out of kernfs_mutex. So i suppose kernfs_put() should be put under kernfs_mutex() in kernfs_notify_workfn(). Konstantin Khorenko (1): kernfs: keep kernfs node alive for __kernfs_remove() fs/kernfs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.15.1