Received: by 2002:ac0:a874:0:0:0:0:0 with SMTP id c49csp343450ima; Fri, 15 Mar 2019 04:12:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqwOOwf7Tb2yinXpBLwlm3Gm6Db5PLZNxi8OPnw7Lxu5utq4NUN9gEtUR3HdYmNzI+crLfAg X-Received: by 2002:a17:902:8602:: with SMTP id f2mr3636204plo.263.1552648340509; Fri, 15 Mar 2019 04:12:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552648340; cv=none; d=google.com; s=arc-20160816; b=Z9jJN2XQXwzTdNc5+9b72Py6ih2tIKyvZMNbqgLnYagucuxl8saP7XDRt0ygOstQJG +V6aSXCLh2QchfU4tkAR3eFvFs/xkESHNZ0DoFrGQ+mEkRKsCiliEnv1D6DXKlWybfwM nOrY2zLYHt9rzkdPnsYuBpIdphFopyaNth6wJEdMhK3xpf1DKQMaaDmkrxMZpGSW5MW+ Ys5iqnW7SLd2y/1+vvFVfzDFwYu13GP0kcF+s1IL4gtxVN0wh53b9M822DVbLPXFemYX 0i9nFSP55NvJv1cns7O1zpIsSTYV7xEwPJfSByWJRj6T4hn7sgKiRwPGKsHSSo2r+7AS 4+sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=9a9xkL+OPPtZrHAAh5vS1TXbLnwxyuErFjB5ttC7PTA=; b=Kz94g3sV1DnaEQjVq3mmxpyRsSjlMrNiCiiwI+1PWgPaYA/fIXbDEsddOQJHORPN4a 966FNMSlpYH/NblY7lfWlvMRvWoOuwWIL2pnFj8jP73ZbmJmIjsD/IU1TPw4j9dJKc/2 i6HDq+4hLj5Ilq4mewSuLYK9qZ9VO3Cw6FILYAJKGqkInOrI3ykUiYplV/AVYf0bMAj0 gUt97t7lPnV0v4QhJeEeqIKWM/inC/+NCcrjPQA2vhA0BndW2WF2yhCXNsCBMHvpIYJC 8C+82sGnV11bzkKZo5nrSZAcuoE4huB8J8l72dJ++GeY2abOaVLSkhMq1nCBwKmBrsQA bI1Q== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r192si1551096pgr.331.2019.03.15.04.12.04; Fri, 15 Mar 2019 04:12:20 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727454AbfCOLLL (ORCPT + 99 others); Fri, 15 Mar 2019 07:11:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:44132 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726714AbfCOLLK (ORCPT ); Fri, 15 Mar 2019 07:11:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 432D2AF51; Fri, 15 Mar 2019 11:11:09 +0000 (UTC) From: Luis Henriques To: "Yan, Zheng" , Sage Weil , Ilya Dryomov Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org, Luis Henriques , stable@vger.kernel.org Subject: [PATCH] ceph: Fix a memory leak in ci->i_head_snapc Date: Fri, 15 Mar 2019 11:11:07 +0000 Message-Id: <20190315111107.15154-1-lhenriques@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I'm occasionally seeing a kmemleak warning in xfstest generic/013: unreferenced object 0xffff8881fccca940 (size 32): comm "kworker/0:1", pid 12, jiffies 4295005883 (age 130.648s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d741a1ea>] build_snap_context+0x5b/0x2a0 [<0000000021a00533>] rebuild_snap_realms+0x27/0x90 [<00000000ac538600>] rebuild_snap_realms+0x42/0x90 [<000000000e955fac>] ceph_update_snap_trace+0x2ee/0x610 [<00000000a9550416>] ceph_handle_snap+0x317/0x5f3 [<00000000fc287b83>] dispatch+0x362/0x176c [<00000000a312c741>] ceph_con_workfn+0x9ce/0x2cf0 [<000000004168e3a9>] process_one_work+0x1d4/0x400 [<000000002188e9e7>] worker_thread+0x2d/0x3c0 [<00000000b593e4b3>] kthread+0x112/0x130 [<00000000a8587dca>] ret_from_fork+0x35/0x40 [<00000000ba1c9c1d>] 0xffffffffffffffff It looks like it is possible that we miss a flush_ack from the MDS when, for example, umounting the filesystem. In that case, we can simply drop the reference to the ceph_snap_context obtained in ceph_queue_cap_snap(). Link: https://tracker.ceph.com/issues/38224 Cc: stable@vger.kernel.org Signed-off-by: Luis Henriques --- fs/ceph/caps.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index 36a8dc699448..208f4dc6f574 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -1054,6 +1054,7 @@ int ceph_is_any_caps(struct inode *inode) static void drop_inode_snap_realm(struct ceph_inode_info *ci) { struct ceph_snap_realm *realm = ci->i_snap_realm; + spin_lock(&realm->inodes_with_caps_lock); list_del_init(&ci->i_snap_realm_item); ci->i_snap_realm_counter++; @@ -1063,6 +1064,12 @@ static void drop_inode_snap_realm(struct ceph_inode_info *ci) spin_unlock(&realm->inodes_with_caps_lock); ceph_put_snap_realm(ceph_sb_to_client(ci->vfs_inode.i_sb)->mdsc, realm); + /* + * ci->i_head_snapc should be NULL, but we may still be waiting for a + * flush_ack from the MDS. In that case, we still hold a ref for the + * ceph_snap_context and we need to drop it. + */ + ceph_put_snap_context(ci->i_head_snapc); } /*