linux-kernel - Re: [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFo99gZm0b8QodT56r+wegY7LM=oWFqLmpE5cnN_MaiBrx1Fqg@mail.gmail.com>
Date:	Fri, 30 May 2014 00:39:24 +0200
From:	Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dave Jones <davej@...hat.com>, Mark Fasheh <mfasheh@...e.com>,
	Joel Becker <jlbec@...lplan.org>, ocfs2-devel@....oracle.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jeff Liu <jeff.liu@...cle.com>
Subject: Re: [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer
 checks that could never happen

Hi all!

First, I'm no expert on this code, but after a patch which I thought
was most accurate for the current code was written before, which was
rather something like the code below.
Then Jeff Liu that this was not something that could happen. So I send
a patch where the check was removed instead.
And that's where we are now. :-)


@@ -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))



Best regards
Rickard Strandqvist


2014-05-29 23:38 GMT+02:00 Andrew Morton <akpm@...ux-foundation.org>:
> On Thu, 29 May 2014 17:23:08 -0400 Dave Jones <davej@...hat.com> wrote:
>
>> On Thu, May 29, 2014 at 02:03:37PM -0700, Andrew Morton wrote:
>>  > On Tue, 27 May 2014 22:23:51 +0200 Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se> wrote:
>>  >
>>  > > Removal of null pointer checks that could never happen
>>  >
>>  > How do you know it never happens?
>>  >
>>  > > --- a/fs/ocfs2/move_extents.c
>>  > > +++ b/fs/ocfs2/move_extents.c
>>  > > @@ -904,9 +904,6 @@ static int ocfs2_move_extents(struct ocfs2_move_extents_context *context)
>>  > >          struct buffer_head *di_bh = NULL;
>>  > >          struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
>>  > >
>>  > > -        if (!inode)
>>  > > -                return -ENOENT;
>>  > > -
>>  >
>>  > If it's due to assuming that the previous statement would have oopsed
>>  > then that is mistaken.  Is is sometimes the case that gcc will move the
>>  > evaluation of inode->i_sb to after the test, so this function can be
>>  > passed NULL and it will not oops.
>>
>> 'sometimes' ?
>>
>> You have a lot more faith in gcc than I do. What happens if we decide to
>> switch to llvm one day ? Can we guarantee every compiler will implement
>> the same magic ?  This seems fragile as hell to me.
>>
>
> Well yes.  There are two ways to go here:
>
> a) work out if `inode' can legitimately be NULL.  If so, do
>
>         struct ocfs2_super *osb;
>
>         if (!inode)
>                 return -ENOENT;
>         osb = OCFS2_SB(inode->i_sb);
>
>    or
>
> b) if `inode' cannot legitimately be NULL then Rickard's patch is OK.
>
>
> My point is that we *cannot* assume that `inode' cannot be NULL from
> observed runtime results.  Because of the compiler's behaviour.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/