diff options
| author |   Mateusz Guzik <mjguzik@gmail.com> | 2025-03-05 13:36:43 +0100 |
|---|---|---|
| committer |   Christian Brauner <brauner@kernel.org> | 2025-03-05 18:31:23 +0100 |
| commit | a914bd93f3edfedcdd59deb615e8dd1b3643cac5 (patch) | |
| tree | 086e2fe315a62b168d7d33831f933c85327f15fa | |
| parent | fs: use fput_close_sync() in close() (diff) | |
| download | wireguard-linux-a914bd93f3edfedcdd59deb615e8dd1b3643cac5.tar.xz wireguard-linux-a914bd93f3edfedcdd59deb615e8dd1b3643cac5.zip | |
fs: use fput_close() in filp_close()
When tracing a kernel build over refcounts seen this is a wash:
@[kprobe:filp_close]:
[0] 32195 |@@@@@@@@@@ |
[1] 164567 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
I verified vast majority of the skew comes from do_close_on_exec() which
could be changed to use a different variant instead.
Even without changing that, the 19.5% of calls which got here still can
save the extra atomic. Calls here are borderline non-existent compared
to fput (over 3.2 mln!), so they should not negatively affect
scalability.
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20250305123644.554845-4-mjguzik@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
| -rw-r--r-- | fs/open.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/open.c b/fs/open.c index 47615d0e1d9c..39a89df7c37e 100644 --- a/fs/open.c +++ b/fs/open.c @@ -1550,7 +1550,7 @@ int filp_close(struct file *filp, fl_owner_t id) int retval; retval = filp_flush(filp, id); - fput(filp); + fput_close(filp); return retval; } |