2022-03-10 14:43:53

by Jiasheng Jiang

Subject: [PATCH] xfs: xfs_rmap_item: Add ASSERT after calling kmem_zalloc

As the potential failure of the kmem_zalloc() without __GFP_NOFAIL,
it should be better to check it in order to avoid the dereference
of NULL pointer.

Fixes: 5880f2d78ff1 ("xfs: create rmap update intent log items")
Signed-off-by: Jiasheng Jiang <[email protected]>
---
fs/xfs/xfs_rmap_item.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c
index c3966b4c58ef..66395faeeb87 100644
--- a/fs/xfs/xfs_rmap_item.c
+++ b/fs/xfs/xfs_rmap_item.c
@@ -143,6 +143,7 @@ xfs_rui_init(
else
ruip = kmem_cache_zalloc(xfs_rui_cache,
GFP_KERNEL | __GFP_NOFAIL);
+ ASSERT(ruip);

xfs_log_item_init(mp, &ruip->rui_item, XFS_LI_RUI, &xfs_rui_item_ops);
ruip->rui_format.rui_nextents = nextents;
--
2.25.1

2022-03-11 20:42:58

by Dave Chinner

Subject: Re: [PATCH] xfs: xfs_rmap_item: Add ASSERT after calling kmem_zalloc

On Thu, Mar 10, 2022 at 05:43:03PM +0800, Jiasheng Jiang wrote:
> As the potential failure of the kmem_zalloc() without __GFP_NOFAIL,
> it should be better to check it in order to avoid the dereference
> of NULL pointer.

kmem_zalloc() won't ever fail unless it is passed KM_MAYFAIL. i.e.
it has __GFP_NOFAIL behaviour when no flags are passed to it, as the
code in xfs_rui_init() does.

Cheers,

Dave.
--
Dave Chinner
[email protected]

2022-03-11 22:39:27

by Darrick J. Wong

Subject: Re: [PATCH] xfs: xfs_rmap_item: Add ASSERT after calling kmem_zalloc

On Thu, Mar 10, 2022 at 05:43:03PM +0800, Jiasheng Jiang wrote:
> As the potential failure of the kmem_zalloc() without __GFP_NOFAIL,
> it should be better to check it in order to avoid the dereference
> of NULL pointer.
>
> Fixes: 5880f2d78ff1 ("xfs: create rmap update intent log items")
> Signed-off-by: Jiasheng Jiang <[email protected]>
> ---
> fs/xfs/xfs_rmap_item.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c
> index c3966b4c58ef..66395faeeb87 100644
> --- a/fs/xfs/xfs_rmap_item.c
> +++ b/fs/xfs/xfs_rmap_item.c
> @@ -143,6 +143,7 @@ xfs_rui_init(
> else
> ruip = kmem_cache_zalloc(xfs_rui_cache,
> GFP_KERNEL | __GFP_NOFAIL);
> + ASSERT(ruip);
>
> xfs_log_item_init(mp, &ruip->rui_item, XFS_LI_RUI, &xfs_rui_item_ops);

Setting aside for a moment the fact that we'll crash immediately on the
very next line anyways --

The defer ops code will never create an rmap intent item with nextents >
XFS_RUI_MAX_FAST_EXTENTS, so the only way that we'd end up in the
kmem_zalloc path is if one came in via log recovery. We're allowed to
fail log recovery, so why not return NULL if kmem_zalloc fails, and then
patch xlog_recover_rui_commit_pass2 to return ENOMEM if it cannot
allocate ruip?

While we're on this topic -- do the other xfs log intent items need
similar corrections in the xfs_*_init() callers?

--D

> ruip->rui_format.rui_nextents = nextents;
> --
> 2.25.1
>