From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Greg KH <gregkh@linuxfoundation.org>,
Mark Tinguely <tinguely@sgi.com>,
stable@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [3.0-stable PATCH 00/36] Proposed 3.0-stable bug patches
Date: Fri, 7 Dec 2012 15:15:36 -0600 [thread overview]
Message-ID: <20121207211536.GW27055@sgi.com> (raw)
In-Reply-To: <20121207100646.GJ27172@dastard>
Hey,
On Fri, Dec 07, 2012 at 09:06:47PM +1100, Dave Chinner wrote:
> On Thu, Dec 06, 2012 at 11:27:22AM -0600, Mark Tinguely wrote:
> > On 12/05/12 15:45, Dave Chinner wrote:
> > >On Mon, Dec 03, 2012 at 05:42:08PM -0600, Mark Tinguely wrote:
> > >>Here a collection of bug fixes for 3.0-stable. Many of these patches
> > >>were also selected by Dave Chinner as possible 3.0-stable patches:
> > >> http://oss.sgi.com/archives/xfs/2012-08/msg00255.html
> > >>
> > >>I chose only bug fixes and kept the changes to a minimum.
> > >>
> > >>Patch 21/22 are required for the bug fix in patch 23 but they are
> > >>important changes in their own right.
> > >
> > >So I'll ask the same question that Christoph asked me: If nobody is
> > >reporting problems on 3.0.x, why do this and risk regression and
> > >fallout that requires fixing?
> > >
> > >FWIW, what testing have you done?
> >
> > Do you mean?
> >
> > http://oss.sgi.com/archives/xfs/2012-09/msg00002.html
> >
> > I read that message as a concern that your original Linux 3.0-stable
> > patch series contained some items that did not meet the -stable
> > criteria.
>
> I read it as "why change something that no-one is reporting bugs
> for?".
I guess we could all stop putting words in his mouth and let him speak for
himself. Christoph (cc'd), would you please clarify your position?
> I posted that series because I had to do the work for RHEL to
> address customer reported problems, not because I felt like pushing
> a bunch of fixes back to 3.0.
>
> I've spent quite a bit of time over the past few weeks dealing with
> various weird regressions as a result of that backport. If you're
> going to backport a singificant amount of stuff to 3.0.x, then
> that's what you are signing up for. i.e. doing all the bug triage
> and fixing that will result from the backport...
>
> > As for adding patches to 3.0-stable. I believed then and now that
> > proactively suggesting bug fixes into 3.0-stable is a good thing
> > because it is the long term stable branch.
>
> Which is in direct contrast to what most of us think. That is, if
> nobody is reporting problems, then it ain't broke and it doesn't
> need fixing.
Who are you speaking for?
In my opinion, proposing appropriate bug fixes for inclusion in -stable has
merit regardless of whether the bug has been reported by -stable users. If the
fix fits the -stable criteria and there is a chance a stable user will hit the
bug it can be proposed.
> > A few days after Christoph's email, I put my "Reviewed-by:" on your
> > series.
> >
> > http://oss.sgi.com/archives/xfs/2012-09/msg00167.html
> >
> > As for testing, the whole series is spun on xfstests loops for days on
> > x86_32 and x86_64 boxes, just like we test a top of tree patch series.
>
> Which we all know does not catch all possible regressions. What
> about crash/shutdown testing? Or load/stress testing?
I have no objection to additional testing of proposed -stable patches. However
I believe it is impossible to catch 'all possible regressions'. There will
always be some risk here.
> /me is playing Devil's Advocate because I'm not signing up to
> triage a whole new set of 3.0.x stable kernel regressions when
> nobody is currently reporting problems.....
SGI XFS product is based directly upon -stable branches and I'd like to track
these branches as closely as possible. This aligns the interests of the SGI
XFS team and -stable users. If there are regressions, myself, Mark, Phil,
Rich, and Andrew are signed up to fix them regardless of whether you wish to be
involved. Paying customers come first as always, but the bugs will be fixed
either way.
Stable folk (cc'd Greg), what is your disposition with regard to proposing
patches for -stable proactively? Do we really need to have a bug report from a
3.0-stable user for every bug we propose for 3.0-stable?
Thanks,
Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-12-07 21:13 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 23:42 [3.0-stable PATCH 00/36] Proposed 3.0-stable bug patches Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 01/36] xfs: fix possible overflow in xfs_ioc_trim() Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 02/36] xfs: fix allocation length overflow in xfs_bmapi_write() Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 03/36] xfs: mark the xfssyncd workqueue as non-reentrant Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 04/36] xfs: xfs_trans_add_item() - dont assign in ASSERT() when compare is intended Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 05/36] xfs: only take the ILOCK in xfs_reclaim_inode() Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 06/36] xfs: fallback to vmalloc for large buffers in xfs_attrmulti_attr_get Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 07/36] xfs: fallback to vmalloc for large buffers in xfs_getbmap Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 08/36] xfs: fix deadlock in xfs_rtfree_extent Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 09/36] xfs: Fix open flag handling in open_by_handle code Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 10/36] xfs: Account log unmount transaction correctly Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 11/36] xfs: fix fstrim offset calculations Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 12/36] xfs: dont fill statvfs with project quota for a directory Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 13/36] xfs: Ensure inode reclaim can run during quotacheck Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 14/36] xfs: use shared ilock mode for direct IO writes by default Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 15/36] xfs: punch all delalloc blocks beyond EOF on write failure Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 16/36] xfs: page type check in writeback only checks last buffer Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 17/36] xfs: punch new delalloc blocks out of failed writes inside EOF Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 18/36] xfs: dont assert on delalloc regions beyond EOF Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 19/36] xfs: limit specualtive delalloc to maxioffset Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 20/36] xfs: Use preallocation for inodes with extsz hints Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 21/36] xfs: Dont allocate new buffers on every call to _xfs_buf_find Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 22/36] xfs: clean up buffer allocation Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 23/36] xfs: fix buffer lookup race on allocation failure Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 24/36] xfs: use iolock on XFS_IOC_ALLOCSP calls Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 25/36] xfs: Properly exclude IO type flags from buffer flags Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 26/36] xfs: flush outstanding buffers on log mount failure Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 27/36] xfs: protect xfs_sync_worker with s_umount semaphore Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 28/36] xfs: fix memory reclaim deadlock on agi buffer Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 29/36] xfs: xfs_vm_writepage clear iomap_valid when Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 30/36] xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 31/36] xfs: shutdown xfs_sync_worker before the log Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 32/36] xfs: really fix the cursor leak in xfs_alloc_ag_vextent_near Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 33/36] xfs: check for stale inode before acquiring iflock on push Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 34/36] xfs: stop the sync worker before xfs_unmountfs Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 35/36] xfs: zero allocation_args on the kernel stack Mark Tinguely
2012-12-03 23:42 ` [3.0-stable PATCH 36/36] xfs: only update the last_sync_lsn when a transaction completes Mark Tinguely
2012-12-04 21:44 ` [3.0-stable PATCH 00/36] Proposed 3.0-stable bug patches Ben Myers
2012-12-05 21:45 ` Dave Chinner
2012-12-06 17:27 ` Mark Tinguely
2012-12-07 10:06 ` Dave Chinner
2012-12-07 21:15 ` Ben Myers [this message]
2012-12-08 12:06 ` Christoph Hellwig
2012-12-08 19:12 ` Greg KH
2012-12-10 0:24 ` Dave Chinner
2012-12-10 22:03 ` Ben Myers
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=20121207211536.GW27055@sgi.com \
--to=bpm@sgi.com \
--cc=david@fromorbit.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tinguely@sgi.com \
--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