* [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen
@ 2014-05-27 20:23 Rickard Strandqvist
2014-05-29 21:03 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Rickard Strandqvist @ 2014-05-27 20:23 UTC (permalink / raw)
To: Mark Fasheh, Joel Becker; +Cc: Rickard Strandqvist, ocfs2-devel, linux-kernel
Removal of null pointer checks that could never happen
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
fs/ocfs2/move_extents.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/ocfs2/move_extents.c b/fs/ocfs2/move_extents.c
index 599eb4c..9ba3a10 100644
--- 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 (ocfs2_is_hard_readonly(osb) || ocfs2_is_soft_readonly(osb))
return -EROFS;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen
2014-05-27 20:23 [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen Rickard Strandqvist
@ 2014-05-29 21:03 ` Andrew Morton
2014-05-29 21:23 ` Dave Jones
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2014-05-29 21:03 UTC (permalink / raw)
To: Rickard Strandqvist; +Cc: Mark Fasheh, Joel Becker, ocfs2-devel, linux-kernel
On Tue, 27 May 2014 22:23:51 +0200 Rickard Strandqvist <rickard_strandqvist@spectrumdigital.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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen
2014-05-29 21:03 ` Andrew Morton
@ 2014-05-29 21:23 ` Dave Jones
2014-05-29 21:38 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Dave Jones @ 2014-05-29 21:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Rickard Strandqvist, Mark Fasheh, Joel Becker, ocfs2-devel, linux-kernel
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@spectrumdigital.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.
Dave
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen
2014-05-29 21:23 ` Dave Jones
@ 2014-05-29 21:38 ` Andrew Morton
2014-05-29 22:39 ` Rickard Strandqvist
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2014-05-29 21:38 UTC (permalink / raw)
To: Dave Jones
Cc: Rickard Strandqvist, Mark Fasheh, Joel Becker, ocfs2-devel, linux-kernel
On Thu, 29 May 2014 17:23:08 -0400 Dave Jones <davej@redhat.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@spectrumdigital.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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen
2014-05-29 21:38 ` Andrew Morton
@ 2014-05-29 22:39 ` Rickard Strandqvist
2014-05-29 22:42 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Rickard Strandqvist @ 2014-05-29 22:39 UTC (permalink / raw)
To: Andrew Morton
Cc: Dave Jones, Mark Fasheh, Joel Becker, ocfs2-devel, linux-kernel,
Jeff Liu
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@linux-foundation.org>:
> On Thu, 29 May 2014 17:23:08 -0400 Dave Jones <davej@redhat.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@spectrumdigital.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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen
2014-05-29 22:39 ` Rickard Strandqvist
@ 2014-05-29 22:42 ` Andrew Morton
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2014-05-29 22:42 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Dave Jones, Mark Fasheh, Joel Becker, ocfs2-devel, linux-kernel,
Jeff Liu
On Fri, 30 May 2014 00:39:24 +0200 Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> wrote:
> 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. :-)
>
Well if Jeff says that inode==NULL cannot happen then that is the info
I was after, and the original patch is OK. Please resend, with that
important info in the changelog ;)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-29 22:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-27 20:23 [PATCH] fs: ocfs2: move_extents.c: Fix to remove null pointer checks that could never happen Rickard Strandqvist
2014-05-29 21:03 ` Andrew Morton
2014-05-29 21:23 ` Dave Jones
2014-05-29 21:38 ` Andrew Morton
2014-05-29 22:39 ` Rickard Strandqvist
2014-05-29 22:42 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).