In a previous commit we switched from a d_alloc_name() + d_lookup()
combination to setup a new dentry and find potential duplicates to the more
idiomatic lookup_one_len(). As far as I understand, this also means we need
to switch from d_add() to d_instantiate() since lookup_one_len() will
create a new dentry when it doesn't find an existing one and add the new
dentry to the hash queues. So we only need to call d_instantiate() to
connect the dentry to the inode and turn it into a positive dentry.

If we were to use d_add() we sure see stack traces like the following
indicating that adding the same dentry twice over the same inode:

[  744.441889] CPU: 4 PID: 2849 Comm: landscape-sysin Not tainted 5.0.0-rc1-brauner-binderfs #243
[  744.441889] Hardware name: Dell      DCS XS24-SC2          /XS24-SC2              , BIOS S59_3C20 04/07/2011
[  744.441889] RIP: 0010:__d_lookup_rcu+0x76/0x190
[  744.441889] Code: 89 75 c0 49 c1 e9 20 49 89 fd 45 89 ce 41 83 e6 07 42 8d 04 f5 00 00 00 00 89 45 c8 eb 0c 48 8b 1b 48 85 db 0f 84 81 00 00 00 <44> 8b 63 fc 4c 3b 6b 10 75 ea 48 83 7b 08 00 74 e3 41 83 e4 fe 41
[  744.441889] RSP: 0018:ffffb8c984e27ad0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
[  744.441889] RAX: 0000000000000038 RBX: ffff9407ef770c08 RCX: ffffb8c980011000
[  744.441889] RDX: ffffb8c984e27b54 RSI: ffffb8c984e27ce0 RDI: ffff9407e6689600
[  744.441889] RBP: ffffb8c984e27b28 R08: ffffb8c984e27ba4 R09: 0000000000000007
[  744.441889] R10: ffff9407e5c4f05c R11: 973f3eb9d84a94e5 R12: 0000000000000002
[  744.441889] R13: ffff9407e6689600 R14: 0000000000000007 R15: 00000007bfef7a13
[  744.441889] FS:  00007f0db13bb740(0000) GS:ffff9407f3b00000(0000) knlGS:0000000000000000
[  744.441889] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  744.441889] CR2: 00007f0dacc51024 CR3: 000000032961a000 CR4: 00000000000006e0
[  744.441889] Call Trace:
[  744.441889]  lookup_fast+0x53/0x300
[  744.441889]  walk_component+0x49/0x350
[  744.441889]  ? inode_permission+0x63/0x1a0
[  744.441889]  link_path_walk.part.33+0x1bc/0x5a0
[  744.441889]  ? path_init+0x190/0x310
[  744.441889]  path_lookupat+0x95/0x210
[  744.441889]  filename_lookup+0xb6/0x190
[  744.441889]  ? __check_object_size+0xb8/0x1b0
[  744.441889]  ? strncpy_from_user+0x50/0x1a0
[  744.441889]  user_path_at_empty+0x36/0x40
[  744.441889]  ? user_path_at_empty+0x36/0x40
[  744.441889]  vfs_statx+0x76/0xe0
[  744.441889]  __do_sys_newstat+0x3d/0x70
[  744.441889]  __x64_sys_newstat+0x16/0x20
[  744.441889]  do_syscall_64+0x5a/0x120
[  744.441889]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  744.441889] RIP: 0033:0x7f0db0ec2775
[  744.441889] Code: 00 00 00 75 05 48 83 c4 18 c3 e8 26 55 02 00 66 0f 1f 44 00 00 83 ff 01 48 89 f0 77 30 48 89 c7 48 89 d6 b8 04 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 03 f3 c3 90 48 8b 15 e1 b6 2d 00 f7 d8 64 89
[  744.441889] RSP: 002b:00007ffc36bc9388 EFLAGS: 00000246 ORIG_RAX: 0000000000000004
[  744.441889] RAX: ffffffffffffffda RBX: 00007ffc36bc9300 RCX: 00007f0db0ec2775
[  744.441889] RDX: 00007ffc36bc9400 RSI: 00007ffc36bc9400 RDI: 00007f0dad26f050
[  744.441889] RBP: 0000000000c0bc60 R08: 0000000000000000 R09: 0000000000000001
[  744.441889] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc36bc9400
[  744.441889] R13: 0000000000000001 R14: 00000000ffffff9c R15: 0000000000c0bc60

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christian Brauner <christian@brauner.io>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>