All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Artem Savkov <asavkov@redhat.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Make __xfs_xattr_put_listen preperly report errors.
Date: Mon, 29 Aug 2016 08:55:01 +1000	[thread overview]
Message-ID: <20160828225501.GJ19025@dastard> (raw)
In-Reply-To: <20160826085928.GA15715@shodan.usersys.redhat.com>

On Fri, Aug 26, 2016 at 10:59:28AM +0200, Artem Savkov wrote:
> On Fri, Aug 26, 2016 at 08:42:15AM +1000, Dave Chinner wrote:
> > So when I look at the fix, and see that it doesn't reproduce on my
> > systems, it's clear that it's either not yet fully understood or
> > hasn't been fully explained by the person who understands the issue.
> > These are some of the questions I've asked myself to understand why
> > we are seeing what we've been seeing:
> > 
> > 	- what condition in the unfixed code leads to the ASSERT
> > 	  being tripped?
> > 	- how does the patch prevent that from occurring?
> > 	- at what threshold does the problem trigger (i.e. n=0, n=1,
> > 	  n=2 .... ?)
> > 	- how do the environmental initial conditions affect the
> > 	  test being run?
> > 	- what do security layers automatically store in the inode
> > 	  at creation time?
> > 	- how can we modify the test to always trigger the assert?
> > 
> > I know the answer, and it would take much less time to tell everyone
> > that it does to write an email like this.  But that means I'll just
> > have to do the same thing next time, and the next time, and so on.
> > The more people we have that can think through issues like this and
> > come to the right conclusion without needing my help, the better off
> > we'll all be...
> 
> Fair enough.
> 
> The problem only shows itself with a minimum of 2 xattrs and only when
> the buffer gets depleted before the last one.

This sentence needs to be in the commit description. :P

> LTP's llistxattr02 test
> only sets one xattr, but on my testsystem "security.selinux" attribute
> is automatically added on file creation which allows this bug to be
> reproduced. So I would assume that on your systems there are no
> automatically created xattrs and thats why you can't reproduce this.

On /some/ of my systems. I have a mix of selinux enabled/disabled
test machines, precisely because of the way always having an
attribute fork in the inode can perturb test results. I happened to
try to reproduce this on a machine that doesn't have selinux
enabled....

> Furthermore if buffersize is such that it is enough to hold the last
> xattr's name, but not enough to hold the sum of preceeding xattrs
> listxattr won't fail with ERANGE, but will suceed returning that xattr's
> name without the first character. The first character end's up
> overwriting whatever is stored at (context->alist - 1).

That should probably also be in the commit description - that
way when we have an idea of what problems it fixes when trying to
match upstream fixes to problems with older kernels (e.g. for distro
kernel backports).

Yes, I know it's a lot to put in a commit message, but in a couple
of years time nobody will remember these details. We regularly have
to work out why something was done 10-15 years ago in the code base,
and having good commit messages makes this a much easier job.
Someone like me will thank you in future for writing a comprehensive
commit message for a relatively simple bug fix....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Artem Savkov <asavkov@redhat.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] Make __xfs_xattr_put_listen preperly report errors.
Date: Mon, 29 Aug 2016 08:55:01 +1000	[thread overview]
Message-ID: <20160828225501.GJ19025@dastard> (raw)
In-Reply-To: <20160826085928.GA15715@shodan.usersys.redhat.com>

On Fri, Aug 26, 2016 at 10:59:28AM +0200, Artem Savkov wrote:
> On Fri, Aug 26, 2016 at 08:42:15AM +1000, Dave Chinner wrote:
> > So when I look at the fix, and see that it doesn't reproduce on my
> > systems, it's clear that it's either not yet fully understood or
> > hasn't been fully explained by the person who understands the issue.
> > These are some of the questions I've asked myself to understand why
> > we are seeing what we've been seeing:
> > 
> > 	- what condition in the unfixed code leads to the ASSERT
> > 	  being tripped?
> > 	- how does the patch prevent that from occurring?
> > 	- at what threshold does the problem trigger (i.e. n=0, n=1,
> > 	  n=2 .... ?)
> > 	- how do the environmental initial conditions affect the
> > 	  test being run?
> > 	- what do security layers automatically store in the inode
> > 	  at creation time?
> > 	- how can we modify the test to always trigger the assert?
> > 
> > I know the answer, and it would take much less time to tell everyone
> > that it does to write an email like this.  But that means I'll just
> > have to do the same thing next time, and the next time, and so on.
> > The more people we have that can think through issues like this and
> > come to the right conclusion without needing my help, the better off
> > we'll all be...
> 
> Fair enough.
> 
> The problem only shows itself with a minimum of 2 xattrs and only when
> the buffer gets depleted before the last one.

This sentence needs to be in the commit description. :P

> LTP's llistxattr02 test
> only sets one xattr, but on my testsystem "security.selinux" attribute
> is automatically added on file creation which allows this bug to be
> reproduced. So I would assume that on your systems there are no
> automatically created xattrs and thats why you can't reproduce this.

On /some/ of my systems. I have a mix of selinux enabled/disabled
test machines, precisely because of the way always having an
attribute fork in the inode can perturb test results. I happened to
try to reproduce this on a machine that doesn't have selinux
enabled....

> Furthermore if buffersize is such that it is enough to hold the last
> xattr's name, but not enough to hold the sum of preceeding xattrs
> listxattr won't fail with ERANGE, but will suceed returning that xattr's
> name without the first character. The first character end's up
> overwriting whatever is stored at (context->alist - 1).

That should probably also be in the commit description - that
way when we have an idea of what problems it fixes when trying to
match upstream fixes to problems with older kernels (e.g. for distro
kernel backports).

Yes, I know it's a lot to put in a commit message, but in a couple
of years time nobody will remember these details. We regularly have
to work out why something was done 10-15 years ago in the code base,
and having good commit messages makes this a much easier job.
Someone like me will thank you in future for writing a comprehensive
commit message for a relatively simple bug fix....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-08-28 22:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 15:54 [PATCH] Make __xfs_xattr_put_listen preperly report errors Artem Savkov
2016-08-23 15:54 ` Artem Savkov
2016-08-24  1:55 ` Dave Chinner
2016-08-24  1:55   ` Dave Chinner
2016-08-24  8:08   ` Artem Savkov
2016-08-24  8:08     ` Artem Savkov
2016-08-25  0:24     ` Dave Chinner
2016-08-25  0:24       ` Dave Chinner
2016-08-25  8:21       ` Artem Savkov
2016-08-25  8:21         ` Artem Savkov
2016-08-25 22:42         ` Dave Chinner
2016-08-25 22:42           ` Dave Chinner
2016-08-26  8:59           ` Artem Savkov
2016-08-26  8:59             ` Artem Savkov
2016-08-28 22:55             ` Dave Chinner [this message]
2016-08-28 22:55               ` Dave Chinner
2016-08-29  8:12               ` [PATCH v2] " Artem Savkov
2016-08-29  8:12                 ` Artem Savkov
2016-08-25 21:36 ` [PATCH] " Eric Sandeen

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=20160828225501.GJ19025@dastard \
    --to=david@fromorbit.com \
    --cc=asavkov@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.