<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.openvz.org/index.php?action=history&amp;feed=atom&amp;title=Download%2Fkernel%2Frhel4%2F023stab048.6%2Fchanges</id>
	<title>Download/kernel/rhel4/023stab048.6/changes - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.openvz.org/index.php?action=history&amp;feed=atom&amp;title=Download%2Fkernel%2Frhel4%2F023stab048.6%2Fchanges"/>
	<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Download/kernel/rhel4/023stab048.6/changes&amp;action=history"/>
	<updated>2026-05-14T13:43:43Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.31.1</generator>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Download/kernel/rhel4/023stab048.6/changes&amp;diff=7760&amp;oldid=prev</id>
		<title>Kir: Protected &quot;Download/kernel/rhel4/023stab048.6/changes&quot;: Robot: Protecting a list of files. [edit=autoconfirmed:move=autoconfirmed]</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Download/kernel/rhel4/023stab048.6/changes&amp;diff=7760&amp;oldid=prev"/>
		<updated>2009-10-22T18:28:23Z</updated>

		<summary type="html">&lt;p&gt;Protected &amp;quot;&lt;a href=&quot;/Download/kernel/rhel4/023stab048.6/changes&quot; title=&quot;Download/kernel/rhel4/023stab048.6/changes&quot;&gt;Download/kernel/rhel4/023stab048.6/changes&lt;/a&gt;&amp;quot;: Robot: Protecting a list of files. [edit=autoconfirmed:move=autoconfirmed]&lt;/p&gt;
&lt;table class=&quot;diff diff-contentalign-left&quot; data-mw=&quot;interface&quot;&gt;
				&lt;tr class=&quot;diff-title&quot; lang=&quot;en&quot;&gt;
				&lt;td colspan=&quot;1&quot; style=&quot;background-color: #fff; color: #222; text-align: center;&quot;&gt;← Older revision&lt;/td&gt;
				&lt;td colspan=&quot;1&quot; style=&quot;background-color: #fff; color: #222; text-align: center;&quot;&gt;Revision as of 18:28, 22 October 2009&lt;/td&gt;
				&lt;/tr&gt;&lt;tr&gt;&lt;td colspan=&quot;2&quot; class=&quot;diff-notice&quot; lang=&quot;en&quot;&gt;&lt;div class=&quot;mw-diff-empty&quot;&gt;(No difference)&lt;/div&gt;
&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;</summary>
		<author><name>Kir</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Download/kernel/rhel4/023stab048.6/changes&amp;diff=7250&amp;oldid=prev</id>
		<title>Kir: created</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Download/kernel/rhel4/023stab048.6/changes&amp;diff=7250&amp;oldid=prev"/>
		<updated>2009-04-17T11:42:35Z</updated>

		<summary type="html">&lt;p&gt;created&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;== Changes ==&lt;br /&gt;
* {{CVE|2008-5029}} (Unix sockets kernel panic) fixed&lt;br /&gt;
* Fixed an oops on x86_64 in case Container constantly tries to exceed privvmpages&lt;br /&gt;
* Return EOPNOTSUPP when RTNL message is not supported by the kernel&lt;br /&gt;
&lt;br /&gt;
=== Configs ===&lt;br /&gt;
* Same as {{Kernel link|rhel4|023stab048.4}}.&lt;br /&gt;
&amp;lt;includeonly&amp;gt;[[{{PAGENAME}}/changes#Patches|{{Long changelog message}}]]&amp;lt;/includeonly&amp;gt;&amp;lt;noinclude&amp;gt;&lt;br /&gt;
=== Patches ===&lt;br /&gt;
&lt;br /&gt;
==== diff-ms-__scm_destroy-recursion-20081113.9 ====&lt;br /&gt;
&amp;lt;div class=&amp;quot;change&amp;quot;&amp;gt;&lt;br /&gt;
Patch from mainstream, ported by Kostja (khorenko@).&lt;br /&gt;
&lt;br /&gt;
net: Fix recursive descent in __scm_destroy().&lt;br /&gt;
&lt;br /&gt;
__scm_destroy() walks the list of file descriptors in the scm_fp_list&lt;br /&gt;
pointed to by the scm_cookie argument.&lt;br /&gt;
&lt;br /&gt;
Those, in turn, can close sockets and invoke __scm_destroy() again.&lt;br /&gt;
&lt;br /&gt;
There is nothing which limits how deeply this can occur.&lt;br /&gt;
&lt;br /&gt;
The idea for how to fix this is from Linus.  Basically, we do all of&lt;br /&gt;
the fput()s at the top level by collecting all of the scm_fp_list&lt;br /&gt;
objects hit by an fput().  Inside of the initial __scm_destroy() we&lt;br /&gt;
keep running the list until it is empty.&lt;br /&gt;
&lt;br /&gt;
Bug #128590.&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== diff-ms-AF_UNIX-garbage-20081113.9 ====&lt;br /&gt;
&amp;lt;div class=&amp;quot;change&amp;quot;&amp;gt;&lt;br /&gt;
Patch from mainstream, ported by Kostja (khorenko@).&lt;br /&gt;
&lt;br /&gt;
This is a prereq patch for next one.&lt;br /&gt;
&lt;br /&gt;
[AF_UNIX]: Rewrite garbage collector, fixes race.&lt;br /&gt;
&lt;br /&gt;
Throw out the old mark &amp;amp; sweep garbage collector and put in a&lt;br /&gt;
refcounting cycle detecting one.&lt;br /&gt;
&lt;br /&gt;
The old one had a race with recvmsg, that resulted in false positives&lt;br /&gt;
and hence data loss.  The old algorithm operated on all unix sockets&lt;br /&gt;
in the system, so any additional locking would have meant performance&lt;br /&gt;
problems for all users of these.&lt;br /&gt;
&lt;br /&gt;
The new algorithm instead only operates on «in flight» sockets, which&lt;br /&gt;
are very rare, and the additional locking for these doesn't negatively&lt;br /&gt;
impact the vast majority of users.&lt;br /&gt;
&lt;br /&gt;
In fact it's probable, that there weren't *any* heavy senders of&lt;br /&gt;
sockets over sockets, otherwise the above race would have been&lt;br /&gt;
discovered long ago.&lt;br /&gt;
&lt;br /&gt;
The patch works OK with the app that exposed the race with the old&lt;br /&gt;
code.  The garbage collection has also been verified to work in a few&lt;br /&gt;
simple cases.&lt;br /&gt;
&lt;br /&gt;
Bug #128590.&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== diff-ms-AF_UNIX-garbage-inflight-20081113.9 ====&lt;br /&gt;
&amp;lt;div class=&amp;quot;change&amp;quot;&amp;gt;&lt;br /&gt;
Patch from mainstream, ported by Kostja (khorenko).&lt;br /&gt;
&lt;br /&gt;
net: unix: fix inflight counting bug in garbage collector&lt;br /&gt;
&lt;br /&gt;
Previously I assumed that the receive queues of candidates don't&lt;br /&gt;
change during the GC.  This is only half true, nothing can be received&lt;br /&gt;
from the queues (see comment in unix_gc()), but buffers could be added&lt;br /&gt;
through the other half of the socket pair, which may still have file&lt;br /&gt;
descriptors referring to it.&lt;br /&gt;
&lt;br /&gt;
This can result in inc_inflight_move_tail() erronously increasing the&lt;br /&gt;
«inflight» counter for a unix socket for which dec_inflight() wasn't&lt;br /&gt;
previously called.  This in turn can trigger the «BUG_ON(total_refs &amp;lt;&lt;br /&gt;
inflight_refs)» in a later garbage collection run.&lt;br /&gt;
&lt;br /&gt;
Fix this by only manipulating the «inflight» counter for sockets which&lt;br /&gt;
are candidates themselves.  Duplicating the file references in&lt;br /&gt;
unix_attach_fds() is also needed to prevent a socket becoming a&lt;br /&gt;
candidate for GC while the skb that contains it is not yet queued.&lt;br /&gt;
&lt;br /&gt;
Bug #128590.&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== diff-misc-fix-topdown-loop-20080815 ====&lt;br /&gt;
&amp;lt;div class=&amp;quot;change&amp;quot;&amp;gt;&lt;br /&gt;
Patch from Konstantin (khlebnikov@):&lt;br /&gt;
&lt;br /&gt;
fix endless loop in x86_64 arch_get_unmapped_area_topdown&lt;br /&gt;
&lt;br /&gt;
if we hit in hole between NULL address and first vma in mm,&lt;br /&gt;
and requested len equal to this hole size — addr become NULL and we got&lt;br /&gt;
endless loop.&lt;br /&gt;
&lt;br /&gt;
this patch change loop exit condition, and terminate loop in this case.&lt;br /&gt;
&lt;br /&gt;
the same condition used in newer kernel and mainstream.&lt;br /&gt;
&lt;br /&gt;
Bug #119137.&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== diff-ms-rtnlcompat-20080711 ====&lt;br /&gt;
&amp;lt;div class=&amp;quot;change&amp;quot;&amp;gt;&lt;br /&gt;
Patch from Denis (den@):&lt;br /&gt;
&lt;br /&gt;
rtnl: return EOPNOTSUPP when RTNL message is not supported by the kernel&lt;br /&gt;
&lt;br /&gt;
More precicusely, return EOPNOTSUPP for RTM_NEWLINK only and EINVAL for&lt;br /&gt;
the rest. This is a SUSE11 compatibility.&lt;br /&gt;
&lt;br /&gt;
Bug #115250.&lt;br /&gt;
&lt;br /&gt;
Signed-off-by: Denis V. Lunev &amp;lt;den@parallels.com&amp;gt;&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
==== diff-ub-meminfo-subub-20080807 ====&lt;br /&gt;
&amp;lt;div class=&amp;quot;change&amp;quot;&amp;gt;&lt;br /&gt;
Patch from Denis (den@), ported by Kostja (khorenko):&lt;br /&gt;
&lt;br /&gt;
ub: get parent UB instead of sub-group one to calculate usage&lt;br /&gt;
&lt;br /&gt;
When MEMINFO=&amp;quot;privvmpages:1&amp;quot; on SLM enabled system, one should get&lt;br /&gt;
actual VE usage from a whole group rather than sub-group. Follow&lt;br /&gt;
UBC hierarchy to the root for this.&lt;br /&gt;
&lt;br /&gt;
Bug #118541.&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
==== diff-ubc-net-orphan-msg-20071225-b ====&lt;br /&gt;
&amp;lt;div class=&amp;quot;change&amp;quot;&amp;gt;&lt;br /&gt;
Patch from Kostja (khorenko@):&lt;br /&gt;
&lt;br /&gt;
fix typo: parameters order in printk&lt;br /&gt;
&lt;br /&gt;
Typo was in patch for {{Bug|760}}.&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>Kir</name></author>
		
	</entry>
</feed>