From: Dave Chinner <david@fromorbit.com>
To: Greg KH <greg@kroah.com>
Cc: "Thomas D." <whissi@whissi.de>,
spender@grsecurity.net, stable@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: Something badly broken with the latest XFS changeset in all stable kernels?
Date: Wed, 15 Jun 2016 16:40:22 +1000 [thread overview]
Message-ID: <20160615064022.GD26977@dastard> (raw)
In-Reply-To: <20160615013056.GA23074@kroah.com>
On Tue, Jun 14, 2016 at 06:30:56PM -0700, Greg KH wrote:
> On Wed, Jun 15, 2016 at 10:02:41AM +1000, Dave Chinner wrote:
> > On Mon, Jun 13, 2016 at 11:57:53PM +0200, Thomas D. wrote:
> > > The bad commit according to grsec's statement is
> > >
> > > > From b1438f477934f5a4d5a44df26f3079a7575d5946 Mon Sep 17 00:00:00 2001
> > > > From: Dave Chinner <dchinner@redhat.com>
> > > > Date: Wed, 18 May 2016 13:53:42 +1000
> > > > Subject: [PATCH] xfs: xfs_iflush_cluster fails to abort on error
> > >
> > > Would be nice to get some clarification.
> >
> > There's nothing wrong with that commit in the upstream kernel,
> > it's the backport that has a bug in it because it failed to take
> > into account changes outside the context of the upstream commit that
> > the older kernels don't have.
>
> Thanks for letting me know about this.
>
> As the patch was tagged with 3.10+, I assumed that it was safe to be
> merged to those older kernels, otherwise I would never have done so. We
> do have ways to mark external things like this for stable patches, it's
> a great help when doing backports.
Little things like this are very easy to forget about - those error
sign changes are ancient history as far as upstream development is
concerned. This is why we have regression tests - the zero-day
kernel robot can run xfstests - perhaps stable kernels should be
submitted to a full round of testing before release to catch
subtle "patch applies but ends up wrong" issues like this...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Greg KH <greg@kroah.com>
Cc: "Thomas D." <whissi@whissi.de>,
xfs@oss.sgi.com, stable@vger.kernel.org, spender@grsecurity.net
Subject: Re: Something badly broken with the latest XFS changeset in all stable kernels?
Date: Wed, 15 Jun 2016 16:40:22 +1000 [thread overview]
Message-ID: <20160615064022.GD26977@dastard> (raw)
In-Reply-To: <20160615013056.GA23074@kroah.com>
On Tue, Jun 14, 2016 at 06:30:56PM -0700, Greg KH wrote:
> On Wed, Jun 15, 2016 at 10:02:41AM +1000, Dave Chinner wrote:
> > On Mon, Jun 13, 2016 at 11:57:53PM +0200, Thomas D. wrote:
> > > The bad commit according to grsec's statement is
> > >
> > > > From b1438f477934f5a4d5a44df26f3079a7575d5946 Mon Sep 17 00:00:00 2001
> > > > From: Dave Chinner <dchinner@redhat.com>
> > > > Date: Wed, 18 May 2016 13:53:42 +1000
> > > > Subject: [PATCH] xfs: xfs_iflush_cluster fails to abort on error
> > >
> > > Would be nice to get some clarification.
> >
> > There's nothing wrong with that commit in the upstream kernel,
> > it's the backport that has a bug in it because it failed to take
> > into account changes outside the context of the upstream commit that
> > the older kernels don't have.
>
> Thanks for letting me know about this.
>
> As the patch was tagged with 3.10+, I assumed that it was safe to be
> merged to those older kernels, otherwise I would never have done so. We
> do have ways to mark external things like this for stable patches, it's
> a great help when doing backports.
Little things like this are very easy to forget about - those error
sign changes are ancient history as far as upstream development is
concerned. This is why we have regression tests - the zero-day
kernel robot can run xfstests - perhaps stable kernels should be
submitted to a full round of testing before release to catch
subtle "patch applies but ends up wrong" issues like this...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-06-15 6:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-13 21:57 Something badly broken with the latest XFS changeset in all stable kernels? Thomas D.
2016-06-15 0:02 ` Dave Chinner
2016-06-15 0:02 ` Dave Chinner
2016-06-15 1:30 ` Greg KH
2016-06-15 1:30 ` Greg KH
2016-06-15 5:28 ` Willy Tarreau
2016-06-15 5:28 ` Willy Tarreau
2016-06-15 6:51 ` Dave Chinner
2016-06-15 6:51 ` Dave Chinner
2016-06-15 7:14 ` Willy Tarreau
2016-06-15 7:14 ` Willy Tarreau
2016-06-15 7:00 ` Jiri Slaby
2016-06-15 7:00 ` Jiri Slaby
2016-06-15 6:40 ` Dave Chinner [this message]
2016-06-15 6:40 ` Dave Chinner
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=20160615064022.GD26977@dastard \
--to=david@fromorbit.com \
--cc=greg@kroah.com \
--cc=spender@grsecurity.net \
--cc=stable@vger.kernel.org \
--cc=whissi@whissi.de \
--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.