Hi
Ok good, then everything is under control.
The result has been that I've done a number of these types of patches to :)
Sending a new patch of that kind then.
Best regards
Rickard Strandqvist
2014-05-26 5:28 GMT+02:00 Jeff Liu :
> Hi,
>
> On 05/23/2014 04:46 AM, Rickard Strandqvist wrote:
>> There is otherwise a risk of a possible null pointer dereference.
>>
>> Was largely found by using a static code analysis program called cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist
>> ---
>> fs/ocfs2/move_extents.c |4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/ocfs2/move_extents.c b/fs/ocfs2/move_extents.c
>> index 599eb4c..6a8e3c8 100644
>> --- a/fs/ocfs2/move_extents.c
>> +++ b/fs/ocfs2/move_extents.c
>> @@ -902,11 +902,13 @@ static int ocfs2_move_extents(struct
>> ocfs2_move_extents_context *context)
>> struct inode *inode = context->inode;
>> struct ocfs2_dinode *di;
>> struct buffer_head *di_bh = NULL;
>> - struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
>> + struct ocfs2_super *osb;
>>
>> if (!inode)
>> return -ENOENT;
>>
>> + osb = OCFS2_SB(inode->i_sb);
>> +
>> if (ocfs2_is_hard_readonly(osb) || ocfs2_is_soft_readonly(osb))
>> return -EROFS;
>
> Thanks for your patch, it looks reasonable if we consider it in the context
> of above function only. However, the inode should not be NULL in any case
> given that ocfs2_move_extents() is called by ocfs2_ioctl_move_extents() at
> where the inode is already validated.
>
> IMO, maybe we can just get rid of the useless inode pre-checkup, i.e,
>
> if (!inode)
> return -ENOENT;
>
>
> Thanks,
> -Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
