On Thu 11-04-19 11:53:18, Yufen Yu wrote:
> This patch can avoid protential null pointer dereference for resv_map.
>
> As Mike Kravetz say:
> Even if we can not hit this condition today, I still believe it
> would be a good idea to make this type of change. It would
> prevent a possible NULL dereference in case the structure of code
> changes in the future.
What kind of change would that be and wouldn't it require much more
changes?
In other words it is not really clear why is this an improvement. Random
checks for NULL that cannot happen tend to be more confusing long term
because people will simply blindly follow them and build a cargo cult
around.
> Cc: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
> Cc: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
> Cc: Michal Hocko <mhocko@xxxxxxxxxx>
> Suggested-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
> Signed-off-by: Yufen Yu <yuyufen@xxxxxxxxxx>
> ---
> mm/hugetlb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 97b1e0290c66..fe74f94e5327 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4465,6 +4465,8 @@ int hugetlb_reserve_pages(struct inode *inode,
> */
> if (!vma || vma->vm_flags & VM_MAYSHARE) {
> resv_map = inode_resv_map(inode);
> + if (!resv_map)
> + return -EACCES;
>
> chg = region_chg(resv_map, from, to);
>
> --
> 2.16.2.dirty
--
Michal Hocko
SUSE Labs
