Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754141AbcDTB5N (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 Apr 2016 21:57:13 -0400
Received: from smtp.codeaurora.org ([198.145.29.96]:40861 "EHLO
	smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752529AbcDTB5M (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 Apr 2016 21:57:12 -0400
Message-ID: <5716E1F5.1020109@codeaurora.org>
Date: Tue, 19 Apr 2016 18:57:09 -0700
From: Nikhilesh Reddy <reddyn@codeaurora.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        arve@android.com, riandrews@android.com
Subject: Re: Umount failing due to a file leak on 3.18 Android
References: <5716DAC3.4070404@codeaurora.org> <5716DB92.2080002@codeaurora.org>
In-Reply-To: <5716DB92.2080002@codeaurora.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1483
Lines: 45


Adding Arve Hjønnevåg and Riley Andrews


I am looking into a bug that results in umount failures ( since there
is a mount ref from the leaked file that is never freed on the mount )

The issue seems to be a result of the following callstack

      39.958104:   <6> Call trace:
      39.958108:   <2> [<ffffffc0001baa58>] fput+0x1e0/0x1f8
      39.958113:   <2> [<ffffffc0001b6ce8>] filp_close+0xa0/0xb8
      39.958119:   <2> [<ffffffc0001d3ca8>] put_files_struct+0x88/0xf0
      39.958123:   <2> [<ffffffc000973c40>]
binder_deferred_func+0x6a8/0x704
      39.958129:   <2> [<ffffffc0000ba32c>] process_one_work+0x238/0x3f0
      39.958133:   <2> [<ffffffc0000bb160>] worker_thread+0x2f8/0x418

What seems to occur is that once in a while a file ( say a.txt) is
fput in the above stack
right as the task is being killed

And then we see that the  fput schedules a delayed_fput_work on this
file

But when the function delayed_fput() is actually run :
     the file that was put i.e this a.txt is not in the delayed_fput_list

Any chance you can help me get to the bottom of this leak?
I dont understand why the delayed_fput_list is missing the file.

Is there some sort of race condition?


I will appreciate any pointers you can give me to debug this issue
Thanks so much in advance for your help.


-- 
Thanks
Nikhilesh Reddy

Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.