* [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@vger.kernel.org, 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@vger.kernel.org, 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