dma-buf: Handle dentry->d_fsdata being NULL

Since the dma_buf_dentry_ops ops are set on the dma-buf dentry, in
alloc_file_pseudo, and this is before the dma-buf is assigned to
dentry->d_fsdata, in dma_buf_getfile, it is possible for the
dma_buf_dentry_ops functions to be called with dentry->d_fsdata == NULL.

For example:

BUG: KASAN: null-ptr-deref in dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88
Call trace:
dump_backtrace+0x0/0x2c8 arch/arm64/kernel/time.c:50
show_stack+0x20/0x2c arch/arm64/kernel/traps.c:140
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x154/0x1f4 lib/dump_stack.c:118
__kasan_report+0x1ac/0x218 mm/kasan/report.c:510
kasan_report+0x10/0x18 mm/kasan/common.c:634
check_memory_region_inline mm/kasan/generic.c:181 [inline]
__asan_load4+0x90/0x98 mm/kasan/generic.c:250
dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88
__dentry_kill+0x294/0x31c fs/dcache.c:584
dentry_kill fs/dcache.c:673 [inline]
dput+0x250/0x380 fs/dcache.c:859
path_put+0x24/0x40 fs/namei.c:485
alloc_file_pseudo+0x1a4/0x200 fs/file_table.c:235
dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline]
dma_buf_export+0x25c/0x3ec drivers/dma-buf/dma-buf.c:585
ion_dmabuf_alloc+0x168/0x1d4 drivers/staging/android/ion/ion_dma_buf.c:394
ion_alloc_fd drivers/staging/android/ion/ion.c:54 [inline]
ion_ioctl+0x24c/0x5c8 drivers/staging/android/ion/ion.c:194
vfs_ioctl fs/ioctl.c:47 [inline]
do_vfs_ioctl+0x55c/0xcb4 fs/ioctl.c:699
ksys_ioctl fs/ioctl.c:714 [inline]
__do_sys_ioctl fs/ioctl.c:721 [inline]
__se_sys_ioctl fs/ioctl.c:719 [inline]
__arm64_sys_ioctl+0xa0/0xe4 fs/ioctl.c:719
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
el0_svc_common+0x130/0x294 arch/arm64/kernel/syscall.c:117
el0_svc_handler+0xdc/0xec arch/arm64/kernel/syscall.c:163
el0_svc+0x8/0xc arch/arm64/kernel/entry.S:1031

Ideally we would change the dma-buf code to ensure that the
dma_buf_dentry_ops ops are set on the dma-buf dentry after the dentry's
d_fsdata has been set, however there does not appear to be a clean way to
do this.
For example if the dma_buf_fs_type was changed so that it's dops weren't
configured the alloc_file_pseudo function would still assign the anon_ops
to the dma-buf dentry, and if we then tried to configure the dma-buf
dentry's dentry_operations later on, using d_set_d_op, the function would
WARN since the dma-buf's dentry already has its dentry_operations
configured.

So instead change the dma_buf_dentry_ops functions to handle the case
where the dma-buf dentry's d_fsdata may be NULL.

Change-Id: Idb1ef749c623b17fb8b7ce90f0c472a5ba298297
Signed-off-by: Liam Mark <lmark@codeaurora.org>