Suspected leak of 'name'

[Jens Axboe <axboe@xxxxxxxxx>]

Hi Al,

Same reproducer I sent you, was running testing and kmemleak complained
about 'name' from proc_self_get_link() never getting freed:

unreferenced object 0xffff8881086f0a30 (size 16):
  comm "al", pid 35226, jiffies 4295022637 (age 74.420s)
  hex dump (first 16 bytes):
    33 35 32 32 36 00 00 00 20 0a 6f 08 81 88 ff ff  35226... .o.....
  backtrace:
    [<00000000dbe89ca0>] proc_self_get_link+0x99/0xc0
    [<0000000090ccc390>] step_into+0x530/0x6b0
    [<00000000934729a9>] walk_component+0x70/0x1c0
    [<00000000fc19296d>] link_path_walk.part.0+0x234/0x370
    [<000000006f9abd8e>] path_openat+0xb3/0xe50
    [<00000000d07cfec9>] do_filp_open+0x88/0x130
    [<000000007de40bab>] do_sys_openat2+0x97/0x150
    [<00000000bf0f331a>] __x64_sys_openat2+0x66/0xc0
    [<000000007ec2351f>] do_syscall_64+0x2d/0x40
    [<00000000758089a7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Are we missing a drop_links() for the LOOKUP_CACHED case?

diff --git a/fs/namei.c b/fs/namei.c
index 58962569cc20..de74ad2bc6e2 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -631,6 +631,7 @@ static bool legitimize_links(struct nameidata *nd)
 {
 	int i;
 	if (unlikely(nd->flags & LOOKUP_CACHED)) {
+		drop_links(nd);
 		nd->depth = 0;
 		return false;
 	}

-- 
Jens Axboe