Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1382956 > unrolled thread

Umount failing due to a file leak on 3.18 Android

Started byNikhilesh Reddy <reddyn@codeaurora.org>
First post2016-04-20 03:30 +0200
Last post2016-04-20 08:00 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  Umount failing due to a file leak on 3.18 Android Nikhilesh Reddy <reddyn@codeaurora.org> - 2016-04-20 03:30 +0200
    Re: Umount failing due to a file leak on 3.18 Android Nikhilesh Reddy <reddyn@codeaurora.org> - 2016-04-20 03:40 +0200
      Re: Umount failing due to a file leak on 3.18 Android Nikhilesh Reddy <reddyn@codeaurora.org> - 2016-04-20 04:00 +0200
    Re: Umount failing due to a file leak on 3.18 Android Greg KH <gregkh@linuxfoundation.org> - 2016-04-20 08:00 +0200

#1382956 — Umount failing due to a file leak on 3.18 Android

FromNikhilesh Reddy <reddyn@codeaurora.org>
Date2016-04-20 03:30 +0200
SubjectUmount failing due to a file leak on 3.18 Android
Message-ID<rpP7P-86l-1@gated-at.bofh.it>
Hi

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?

-- 
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.

[toc] | [next] | [standalone]


#1382970

FromNikhilesh Reddy <reddyn@codeaurora.org>
Date2016-04-20 03:40 +0200
Message-ID<rpPhx-8ai-13@gated-at.bofh.it>
In reply to#1382956
On Tue 19 Apr 2016 06:26:27 PM PDT, Nikhilesh Reddy wrote:
> Hi
>
> 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.

[toc] | [prev] | [next] | [standalone]


#1382993

FromNikhilesh Reddy <reddyn@codeaurora.org>
Date2016-04-20 04:00 +0200
Message-ID<rpPAS-8hw-5@gated-at.bofh.it>
In reply to#1382970
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.

[toc] | [prev] | [next] | [standalone]


#1383061

FromGreg KH <gregkh@linuxfoundation.org>
Date2016-04-20 08:00 +0200
Message-ID<rpTl8-2P4-3@gated-at.bofh.it>
In reply to#1382956
On Tue, Apr 19, 2016 at 06:26:27PM -0700, Nikhilesh Reddy wrote:
> Hi
> 
> 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.

3.18 is very old, can you duplicate this on 4.5 or newer?

thanks,

greg k-h

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web