linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Geyslan Gregório Bem" <geyslan@gmail.com>,
	"Ben Myers" <bpm@sgi.com>, "Alex Elder" <elder@kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	"XFS FILESYSTEM" <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs: fix possible NULL dereference
Date: Wed, 23 Oct 2013 08:03:00 +1100	[thread overview]
Message-ID: <20131022210300.GC2797@dastard> (raw)
In-Reply-To: <5266E4BD.8030601@sandeen.net>

On Tue, Oct 22, 2013 at 03:49:01PM -0500, Eric Sandeen wrote:
> On 10/22/13 3:39 PM, Dave Chinner wrote:
> > On Tue, Oct 22, 2013 at 08:12:51AM -0200, Geyslan Gregório Bem wrote:
> >> 2013/10/21 Dave Chinner <david@fromorbit.com>:
> >>> On Mon, Oct 21, 2013 at 07:00:59PM -0500, Eric Sandeen wrote:
> >>>> On 10/21/13 6:56 PM, Dave Chinner wrote:
> >>>>> On Mon, Oct 21, 2013 at 06:18:49PM -0500, Ben Myers wrote:
> >>>
> >>> Yes, but to continue the Devil's Advocate argument, the purpose of
> >>> debug code isn't to enlightent the casual reader or drive-by
> >>> patchers - it's to make life easier for people who actually spend
> >>> time debugging the code. And the people who need the debug code
> >>> are expected to understand why an ASSERT is not necessary. :)
> >>>
> >> Dave, Eric and Ben,
> >>
> >> This was catched by coverity (CID 102348).
> > 
> > You should have put that in the patch description.
> > 
> > Now I understand why there's been a sudden surge of irrelevant one
> > line changes from random people that have never touched XFS before.
> > 
> > <sigh>
> > 
> > Ok, lets churn the code just to shut the stupid checker up. This
> > doesn't fix a bug, it doesn't change behaviour, it just makes
> > coverity happy. Convert it to the for loop plus ASSERT I mentioned
> > in a previous message.
> 
> You know, I respectfully disagree, but we might just have to agree
> to disagree.  The code, as it stands, tests for a null ptr
> and then dereferences it.  That's always going to raise some
> eyebrows, coverity or not, debug code or not, drive by or not.

> So even for future developers, making the code more self-
> documenting about this behavior would be a plus, whether it's by
> comment, by explicit ASSERT(), or whatever.  (I don't think
> that xfs_emerg() has quite enough context to make it obvious.)

Sure, but if weren't for the fact that Coverity warned about it,
nobody other that us people who work on the XFS code day in, day out
would have even cared about it.

That's kind of my point - again, as the Devil's Advocate - that
coverity is encouraging drive-by "fixes" by people who don't
actually understand any of the context, history and/or culture
surrounding the code being modified.

I have no problems with real bugs being fixed, but if we are
modifying code for no gain other than closing "coverity doesn't like
it" bugs, then we *should* be questioning whether the change is
really necessary.

Asking the question may not change the outcome, but we need to ask
and answer the question regardless.

> (We don't have to change code to shut up coverity; we can flag
> it in the database and nobody else will see it.)

Only if you are the first to see it and make an executive decision
that it's not necessary to fix.... :/

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2013-10-22 21:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 18:32 [PATCH] xfs: fix possible NULL dereference Geyslan G. Bem
     [not found] ` <5265956F.4010700@sandeen.net>
2013-10-21 22:44   ` Dave Chinner
2013-10-21 23:12     ` Eric Sandeen
2013-10-21 23:18       ` Ben Myers
2013-10-21 23:56         ` Dave Chinner
2013-10-22  0:00           ` Eric Sandeen
2013-10-22  0:17             ` Dave Chinner
2013-10-22 10:12               ` Geyslan Gregório Bem
2013-10-22 20:39                 ` Dave Chinner
2013-10-22 20:49                   ` Eric Sandeen
2013-10-22 21:03                     ` Dave Chinner [this message]
2013-10-22 21:19                       ` Eric Sandeen
2013-10-22 22:02                         ` Dave Chinner
2013-10-22 22:33                           ` Ben Myers
2013-10-25  9:15                           ` Dave Jones
2013-10-23 10:58                         ` Geyslan Gregório Bem
2013-10-23 20:34                           ` Ben Myers
2013-10-23 20:53                             ` Geyslan Gregório Bem
2013-10-30 20:08                             ` Eric Sandeen
2013-10-31 15:55                               ` Ben Myers
2013-10-31 16:15                                 ` Geyslan Gregório Bem

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=20131022210300.GC2797@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.com \
    --cc=elder@kernel.org \
    --cc=geyslan@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).