linux-kernel - Re: XFS problem in 2.6.32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110609025742.GS32466@dastard>
Date:	Thu, 9 Jun 2011 12:57:42 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Theodore Tso <tytso@....EDU>,
	Stefan Priebe - Profihost AG <s.priebe@...fihost.ag>,
	david@...g.hm, linux-kernel@...r.kernel.org
Subject: Re: XFS problem in 2.6.32

On Wed, Jun 08, 2011 at 09:30:37AM -0400, Steven Rostedt wrote:
> On Tue, Jun 07, 2011 at 11:28:59PM -0400, Theodore Tso wrote:
> 
> Ted, you need a new MUA, as it reads horribly in mutt.

Seconded. ;)

> > Not all distributions will participate in the maintenance stable
> > tree.  Red Hat for example is probably worried about people
> > (specifically, Oracle) taking their kernel expertise "for free"
> > and bidding it against them.  So it doesn't surprise me that
> > they aren't submitting patches to the stable tree.  After all,
> > they would like you to purchase a support contract if you want
> > to get high quality, supported kernel.   Why should they give
> > that work away for free?  After all, their salaried developers
> > have to get paid somehow.  Others will contribute work in the
> > hopes that other people will also contribute fixes back, but of
> > course nothing forces Red Hat to do this.
> 
> As a Red Hat employee, I must speak against this. I have *never* been
> told to keep something from stable. In fact, I've always been encouraged
> to push to stable. But it is usually the individual engineer's
> responsibility to get a patch into stable. If something was missed, it
> was more the fault of that individual engineer that made the fix than
> Red Hat.

If you want someone to blame, then point the fingers at me, not
RedHat or RedHat's processes - RedHat is not involved in the
processes and decisions as to what fixes
get backported into the community stable trees. How that is done
is mainly dictated by available resources, which are generally
scarce. We push bug fixes into the lastest kernel release, and if
known to be needed for stable series they get pushed back via the
stable queues.

This particular case is clearly an oversight - when we fixed the
problem I pushed it into the current stable release, but forgot
that we'd also backported fixes to .32 that meant we also needed to
backport this fix to .32 as well.

If you look at a 2.6.32 kernel the fix is not needed for backport,
but somewhere in the 2.6.32.y series, other fixes were backported
which introduce the bug that make this fix necessary. That history
is not in the mainline git tree and so it's really quite easy to
make such a mistake.  So the real cause of this oversight is the
fact that there are simply too many disjoint community trees and
that makes it difficult to determine what fixes need to go where.

As a result of the difficulty tracking stable trees, I don't even
bother trying. Instead I use bug reports as triggers for "we need to
backport this fix" to a stable kernel because I do not have the time
to waste backporting fixes for bugs no-one is actually hitting...

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/