From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Colin Ian King <colin.king@canonical.com>,
Joseph Qi <jiangqi903@gmail.com>, Mark Fasheh <mark@fasheh.com>,
Joel Becker <jlbec@evilplan.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
ocfs2-devel@oss.oracle.com,
Andrew Morton <akpm@linux-foundation.org>
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][ocfs2-next] ocfs2: ensure ret is set to zero before returning
Date: Thu, 8 Aug 2019 09:08:46 +0800 [thread overview]
Message-ID: <0cee7ca9-8704-171a-ec82-ee6c16e3381b@linux.alibaba.com> (raw)
In-Reply-To: <bf4d059a-94fc-d8cf-78c7-8606644185a5@canonical.com>
On 19/8/7 20:42, Colin Ian King wrote:
> On 07/08/2019 13:35, Joseph Qi wrote:
>>
>>
>> On 19/8/7 20:19, Colin King wrote:
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> A previous commit introduced a regression where variable ret was
>>> originally being set from the return from a call to function
>>> dlm_create_debugfs_subroot and this set was removed. Currently
>>> ret is now uninitialized if no alloction errors are found which
>>> may end up with a bogus check on ret < 0 on the 'leave:' return
>>> path. Fix this by setting ret to zero on a successful execution
>>> path.
>>
>> Good catch.
>> Or shall we just initialize 'ret' at first?
>
> Initialized ret first may not catch subsequent coding errors where error
> returns paths have not initialized ret, so my preference is when it is
> required and not before.
>
Okay, looks good to me.
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
>>
>>>
>>> Addresses-Coverity: ("Uninitialzed scalar variable")
>
> Can this be fixed up when applied rather sending a V2?
>>
Currently ocfs2 patches are maintained in Andrew's mm tree.
So it depends on Andrew.
Thanks,
Joseph
prev parent reply other threads:[~2019-08-08 1:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 12:19 Colin King
2019-08-07 12:35 ` Joseph Qi
2019-08-07 12:42 ` Colin Ian King
2019-08-08 1:08 ` Joseph Qi [this message]
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=0cee7ca9-8704-171a-ec82-ee6c16e3381b@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=colin.king@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=jiangqi903@gmail.com \
--cc=jlbec@evilplan.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@oss.oracle.com \
/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®