Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [Jfs-discussion] [PATCH] jfs: Add missing NULL pointer check in
 __get_metapage
To:     Juerg Haefliger <juerg.haefliger@canonical.com>,
        jfs-discussion@lists.sourceforge.net, linux-kernel@vger.kernel.org
References: <20171004082441.2405-1-juerg.haefliger@canonical.com>
 <1dbf4a54-968f-0ca7-da96-e262c653fecb@canonical.com>
 <c3ce64a1-65dc-0ed1-52ec-8bf950b77fb2@oracle.com>
 <778bc3d1-4bf4-ed83-3cc3-19d6efb5cceb@canonical.com>
From:   Dave Kleikamp <dave.kleikamp@oracle.com>
Message-ID: <0c8c1f0e-c3af-308f-aee0-d7b8c14f45d8@oracle.com>
Date:   Thu, 2 Nov 2017 08:15:36 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <778bc3d1-4bf4-ed83-3cc3-19d6efb5cceb@canonical.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/02/2017 01:59 AM, Juerg Haefliger wrote:
> 
> 
> On 10/30/2017 11:13 PM, Dave Kleikamp wrote:
>> On 10/25/2017 02:50 AM, Juerg Haefliger wrote:
>>> Is this a patch you might consider?
>>
>> Sorry it's taken me so long to respond.
>>
>> I don't think this is the right fix. A failed allocation will still
>> result in a null pointer dereference by the caller, __get_metapage(). I
>> think the check needs to be put there. Like this:
>>
>> --- a/fs/jfs/jfs_metapage.c
>> +++ b/fs/jfs/jfs_metapage.c
>> @@ -663,6 +663,8 @@ struct metapage *__get_metapage(struct inode *inode,
>> unsigned long lblock,
>>  	} else {
>>  		INCREMENT(mpStat.pagealloc);
>>  		mp = alloc_metapage(GFP_NOFS);
>> +		if (!mp)
>> +			goto unlock;
>>  		mp->page = page;
>>  		mp->sb = inode->i_sb;
>>  		mp->flag = 0;
> 
> I don't understand. This is part of the patch that I sent.

Doh! How'd I miss that?

> 
> 
>>
>> Furthermore, it looks like all the callers of __get_metapage() check for
>> a null return, so I'm not sure we need to handle the error at this
>> point. I might have to look a bit harder at that, since there are many
>> callers.
> 
> I don't understand this either :-) Yes, the callers do check for a null
> pointer but things blow up (in __get_metapage) before that check without
> the above fix.

Yeah, the fix to __get_metapage() is necessary. I'm not convinced the
first part of the patch, to alloc_metapage(), is necessary.

> 
> ...Juerg
> 
> 
>>
>> Thanks,
>> Shaggy
>>
>>>
>>> Thanks
>>> ...Juerg
>>>
>>>
>>> On 10/04/2017 10:24 AM, Juerg Haefliger wrote:
>>>> alloc_metapage can return a NULL pointer so check for that. And also emit
>>>> an error message if that happens.
>>>>
>>>> Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
>>>> ---
>>>>  fs/jfs/jfs_metapage.c | 20 +++++++++++++-------
>>>>  1 file changed, 13 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
>>>> index 1c4b9ad4d7ab..00f21af66872 100644
>>>> --- a/fs/jfs/jfs_metapage.c
>>>> +++ b/fs/jfs/jfs_metapage.c
>>>> @@ -187,14 +187,18 @@ static inline struct metapage *alloc_metapage(gfp_t gfp_mask)
>>>>  {
>>>>  	struct metapage *mp = mempool_alloc(metapage_mempool, gfp_mask);
>>>>  
>>>> -	if (mp) {
>>>> -		mp->lid = 0;
>>>> -		mp->lsn = 0;
>>>> -		mp->data = NULL;
>>>> -		mp->clsn = 0;
>>>> -		mp->log = NULL;
>>>> -		init_waitqueue_head(&mp->wait);
>>>> +	if (!mp) {
>>>> +		jfs_err("mempool_alloc failed!\n");
>>>> +		return NULL;
>>>>  	}
>>>> +
>>>> +	mp->lid = 0;
>>>> +	mp->lsn = 0;
>>>> +	mp->data = NULL;
>>>> +	mp->clsn = 0;
>>>> +	mp->log = NULL;
>>>> +	init_waitqueue_head(&mp->wait);
>>>> +
>>>>  	return mp;
>>>>  }
>>>>  
>>>> @@ -663,6 +667,8 @@ struct metapage *__get_metapage(struct inode *inode, unsigned long lblock,
>>>>  	} else {
>>>>  		INCREMENT(mpStat.pagealloc);
>>>>  		mp = alloc_metapage(GFP_NOFS);
>>>> +		if (!mp)
>>>> +			goto unlock;
>>>>  		mp->page = page;
>>>>  		mp->sb = inode->i_sb;
>>>>  		mp->flag = 0;
>>>>
> 

From 1582936626463752223@xxx Thu Nov 02 07:00:05 +0000 2017
X-GM-THRID: 1580314796840603396
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread