linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>
To: Viacheslav Dubeyko <slava@dubeyko.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org, "Xu, Wen" <wen.xu@gatech.edu>
Subject: Re: [PATCH] hfsplus: fix NULL dereference in hfsplus_lookup()
Date: Wed, 22 Aug 2018 18:38:47 -0300	[thread overview]
Message-ID: <20180822213847.lob454eebulasbjg@eaf> (raw)
In-Reply-To: <1534969119.2878.6.camel@slavad-ubuntu-14.04>

On Wed, Aug 22, 2018 at 01:18:39PM -0700, Viacheslav Dubeyko wrote:
> On Wed, 2018-08-22 at 15:46 -0300, Ernesto A. Fernández wrote:
> > On Tue, Aug 21, 2018 at 04:05:25PM -0700, Andrew Morton wrote:
> > > On Thu, 12 Jul 2018 15:55:33 -0700 Viacheslav Dubeyko <slava@dubeyko.com> wrote:
> > > 
> > > > On Thu, 2018-07-12 at 18:53 -0300, Ernesto A. Fernández wrote:
> > > > > Check that the hidden directory is not NULL before using it, instead of
> > > > > after.
> > > > > 
> > > > > Reported-by: Wen Xu <wen.xu@gatech.edu>
> > > > > Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
> > > > > ---
> > > > 
> > > > It's really hard to understand this simple patch. I believe it makes
> > > > sense to rework the patch slightly with the goal to make it more clear.
> > > > Also, it will be great to add a short comment in the code to explain
> > > > what's wrong.
> > 
> > I don't think it's reasonable to expect a comment explaining why we can't
> > dereference NULL.
> > 
> 
> The good comment is always really important part of the patch.

That's your idea of a good comment?

> > > > I think it makes sense to split this long check condition on something
> > > > more clear, simple and elegant.
> > 
> > The long check condition may not be ideal, but there's a lot of code in
> > the module that could use style improvements. I don't think that should be
> > a priority right now, with plenty of serious bugs left to fix.
> > 
> 
> Bad style of code is one of the reason of bugs. If you don't try to
> improve the code then you can simply create an another serious bug and
> nobody will be able to understand your fix.

All this does is reorder a check. Where could I possibly introduce a bug?

Large unnecessary rewrites with little testing in unmaintained code are far
more likely to cause trouble. I will be more comfortable with such things
once I get the module to pass xfstests, but there's still plenty of bugs in
the way.

> The bad style of code in the
> module is not the excuse at all. It's the way of open-source community
> to achieve the good style of code by means of the discussion. Moreover,
> the goal of bug fix is the improvement of code style too but not only to
> resolve the issue. Another guys need to understand your way of the fix
> too.

This patch couldn't be any simpler. Anybody who finds it confusing would be
completely overwhelmed by a big rewrite.

> Thanks,
> Vyacheslav Dubeyko.
> 
> > > 
> > > No response, causing this patch to be stuck in limbo land?
> > 
> > I believe I sent a second version of this patch.
> > 
> > 
> > Ernest
> 
> 

  reply	other threads:[~2018-08-23  1:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12 21:53 [PATCH] hfsplus: fix NULL dereference in hfsplus_lookup() Ernesto A. Fernández
2018-07-12 22:55 ` Viacheslav Dubeyko
2018-08-21 23:05   ` Andrew Morton
2018-08-22 18:46     ` Ernesto A. Fernández
2018-08-22 20:18       ` Viacheslav Dubeyko
2018-08-22 21:38         ` Ernesto A. Fernández [this message]
     [not found] ` <20180712153311.71495c0ea5ba0115414f5301@linux-foundation.org>
2018-07-12 23:07   ` Ernesto A. Fernández
     [not found]     ` <20180712161907.c93f4e70e5d406fd3d2d373e@linux-foundation.org>
2018-07-12 23:23       ` Ernesto A. Fernández

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=20180822213847.lob454eebulasbjg@eaf \
    --to=ernesto.mnd.fernandez@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=wen.xu@gatech.edu \
    /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).