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: <alpine.DEB.2.02.1106071239530.28905@asgard.lang.hm>
Date:	Tue, 7 Jun 2011 12:45:15 -0700 (PDT)
From:	david@...g.hm
To:	Stefan Priebe - Profihost AG <s.priebe@...fihost.ag>
cc:	Theodore Tso <tytso@....EDU>, linux-kernel@...r.kernel.org
Subject: Re: XFS problem in 2.6.32

On Tue, 7 Jun 2011, Stefan Priebe - Profihost AG wrote:

> Date: Tue, 07 Jun 2011 15:49:36 +0200
>>> So who keeps track on which patches needs to get backported or not? And 
>>> who will backport XFS fixes back to 2.6.32?
>> 
>> An interested kernel developer.   They can become interested because they 
>> personally have the time or interest, or because someone pays them to 
>> become interested.  Support of the stable kernel series is not something 
>> that happens magically, or which is funded by a charity, you know.  That's 
>> why some companies pay $$$ for a supported distribution kernel.

> OK so my thought was totally wrong. I thought the longterm stable releases 
> will still get bugfixed by SGI or whoever wrote the stuff. Sorry for that 
> then. But what is then the idea of a longterm stable?

development and bugfixes are done on the latest kernel, if the problem is 
known to affect old kernels the developers sometimes remember to notify 
the -stable list that this patch is important and needs to be applied to 
older kernels.

whoever the maintainer of the -stable/-longterm tree is (be it an 
individual or a team employeed by some comapny) then looks at the patch 
and considers backporting it (if it's too hard, or to intrusive, they may 
decide not to).

the idea of the lonterm kernels is that organizations need to maintain a 
kernel for a long time due to commitments that they have made (Debian 
doesn't want to change the kernel it ships in a stable version, RedHat 
doesn't want to change the kernel version in a RHEL release, etc), and so 
they publicly announce this so that anyone else wanting to use the same 
kernel version can share in the work (and therefor everyone can benifit 
from each other's work)

David Lang
--
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/