From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: Juerg Haefliger <juerg.haefliger@canonical.com>,
jfs-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [Jfs-discussion] [PATCH] jfs: Add missing NULL pointer check in __get_metapage
Date: Thu, 2 Nov 2017 08:15:36 -0500 [thread overview]
Message-ID: <0c8c1f0e-c3af-308f-aee0-d7b8c14f45d8@oracle.com> (raw)
In-Reply-To: <778bc3d1-4bf4-ed83-3cc3-19d6efb5cceb@canonical.com>
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;
>>>>
>
next prev parent reply other threads:[~2017-11-02 13:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-04 8:24 Juerg Haefliger
2017-10-25 7:50 ` Juerg Haefliger
2017-10-30 22:13 ` [Jfs-discussion] " Dave Kleikamp
2017-11-02 6:59 ` Juerg Haefliger
2017-11-02 13:15 ` Dave Kleikamp [this message]
2017-11-02 13:43 ` Juerg Haefliger
2017-11-02 14:44 ` Dave Kleikamp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0c8c1f0e-c3af-308f-aee0-d7b8c14f45d8@oracle.com \
--to=dave.kleikamp@oracle.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=juerg.haefliger@canonical.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®