Difference between revisions of "Download/kernel/rhel5/028stab039.1/changes"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(→‎Changes: better list of changes)
(22)
Line 1: Line 1:
−
== Changes ==
+
For most of our generation, the management and ownership have turned us off from the organization. ,
−
* Rebase to RHEL5 8.1.8 kernel
 
−
* Critical fix in CPT
 
−
* Minor fixes for bridge, XEN x8664, CPT, 4GB split, nfs, vpids, etc.
 
−
* Fix swsusp on SLES, CBQ fairness on low rates, NFS startup deadlock.
 
−
* CBQ fairness on low rates fixed
 
−
* NFS startup deadlock.
 
−
 
 
−
=== Config changes ===
 
−
Added:
 
−
* +<code>CONFIG_DM_DELAY=m</code>
 
−
<includeonly>[[{{PAGENAME}}/changes#Patches|{{Long changelog message}}]]</includeonly><noinclude>
 
−
=== Patches ===
 
−
 
 
−
==== diff-arch-4gb-xen-b-20070613 ====
 
−
<div class="change">
 
−
Patch from Sergey Ya Korshunoff (seyko2@)<br/>
 
−
Fix TSS handling in vm86.c in Xen kernel.
 
−
 
 
−
Fix TSS handling in vm86.c in Xen kernel.
 
−
There was a stupid misprint due to which load_esp0()
 
−
was not called in Xen kernels at all.
 
−
</div>
 
−
 
 
−
==== diff-cpt-deleted-ref-b-20070613 ====
 
−
<div class="change">
 
−
Patch from Andrey Mirkin &lt;major@openvz.org&gt;<br/>
 
−
[PATCH] CPT: remove redundant kfree()
 
−
 
 
−
Remove redundant kfree() call from open_deleted() function.
 
−
Now ii is static structure and kfree on it leads to oops :/
 
−
 
 
−
Bug #84173.
 
−
</div>
 
−
 
 
−
==== diff-ms-bridge-nf-ebt-among-20070607 ====
 
−
<div class="change">
 
−
Patch from Evgeny Kravtsunov &lt;emkravts@openvz.org&gt;<br/>
 
−
[PATCH] ebtables: ebtables_among fails on check() on x86-64
 
−
 
 
−
ebtables module calls the checker ebt_among_check()
 
−
that compares the correct size of user supplied data.
 
−
 
 
−
Userspace size is calculated in the following way (ebtables-2.0.8-1):
 
−
  EBT_ALIGN(EBT_ALIGN(sizeof(struct ebt_among_info)) + X)
 
−
 
 
−
While kernel calculates size as:
 
−
  EBT_ALIGN(sizeof(struct ebt_among_info) + X)
 
−
 
 
−
On x86_64 EBT_ALIGN does alignment on 8 bytes, so the problem arises.
 
−
 
 
−
{{bug|576}}.
 
−
</div>
 
−
 
 
−
==== diff-ms-net-bridge-via-eth-c-20070613 ====
 
−
<div class="change">
 
−
Patch from Dmitry Mishin &lt;dim@openvz.org&gt;<br/>
 
−
[PATCH] Fix bridge removal with active master device
 
−
 
 
−
Fix bridge removal with active master device:
 
−
simple misprint.
 
−
</div>
 
−
 
 
−
==== diff-rh-mmap-return-addr-b-20070608 ====
 
−
<div class="change">
 
−
Patch from Vitaliy Gusev &lt;vgusev@openvz.org&gt;<br/>
 
−
[PATCH] IA64: mmap returns EINVAL if len==0
 
−
 
 
−
mmap on IA64 architecture returns EINVAL when len==0,
 
−
while old kernel behaviour is to return addr in this case.
 
−
 
 
−
Though POSIX requires EINVAL in this case and it was
 
−
fixed in mainstream around ~2.6.16, we still
 
−
have to keep compatibility for some time with old stupid
 
−
apps like rpm which did exactly this and expected success :/
 
−
 
 
−
Bug #83938.
 
−
</div>
 
−
 
 
−
==== diff-arch-4gb-suspend-fix-20070629 ====
 
−
<div class="change">
 
−
Patch from Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;<br/>
 
−
[PATCH] 4gb split: fix broken suspend
 
−
 
 
−
Following code was removed by 4gb split patch set,
 
−
after this suspend was broken. Fix it.
 
−
 
 
−
Bug #84909.
 
−
</div>
 
−
 
 
−
==== diff-cpt-dump-eintr-20070622 ====
 
−
<div class="change">
 
−
Patch from Andrey Mirkin &lt;major@openvz.org&gt;<br/>
 
−
[PATCH] CPT: check ctx-&gt;file for NULL
 
−
 
 
−
We need to be sure that dumpfile pointer (ctx-&gt;file) is not NULL, because we
 
−
can't start dump without it.
 
−
 
 
−
Also we need to return error like EINTR instead of ERESTART*, because we just
 
−
can't simply restart dump ioctl. The reason is that dumpfile is already
 
−
closed and we need to reopen it before calling dump ioctl second time.
 
−
 
 
−
Bug #84412.
 
−
</div>
 
−
 
 
−
==== diff-cpt-kernel-thread-ign-sigs-20070628 ====
 
−
<div class="change">
 
−
Patch from Andrey Mirkin &lt;major@openvz.org&gt;<br/>
 
−
[PATCH] CPT: ignore user signals in kernel threads
 
−
 
 
−
Under ptrace signals are not handled immediately and we have non-zero
 
−
shared_pending mask on current task, so fork() returns -ERESTARTNOINTR and
 
−
wait4() returns -ERESTARTSYS.
 
−
We need to block signals SIGCHLD, SIGWINCH, SIGCONT and SIGURG to be sure that
 
−
this signals will be ignored while kernel thread creation.
 
−
 
 
−
Bug #84412.
 
−
</div>
 
−
 
 
−
==== diff-cpt-rm-kill-external-process-20070702 ====
 
−
<div class="change">
 
−
Patch from Kirill Korotaev &lt;dev@openvz.org&gt;<br/>
 
−
[PATCH] CPT: remove killing of external processes
 
−
 
 
−
External processes can't be easily detected.
 
−
Even if process has a virtual pid, it doesn't
 
−
mean it has no any connectiions to VE0 like
 
−
opened files/libraries etc.
 
−
 
 
−
So remove this feature at all and return back as
 
−
it was - external processes should prevent from CPT.
 
−
 
 
−
Revert of the patches:
 
−
* diff-cpt-kill-external-process-20070125
 
−
* diff-cpt-kill-external-processes-b-20070515
 
−
</div>
 
−
 
 
−
==== diff-ms-ia32-compat-autofs4-20070618 ====
 
−
<div class="change">
 
−
Patch from Roman Chechnev &lt;rchechnev@openvz.org&gt;<br/>
 
−
[PATCH] autofs4: compat layer for x8664
 
−
 
 
−
autofs4 uses platform dependant protocol
 
−
which has 'long' data types inside data structures
 
−
which are passed to/from user-space via pipe (sic!)...
 
−
 
 
−
Thanks to this 32bit autofs tools do not work with 64 bit kernel.
 
−
 
 
−
Bug #82040.
 
−
</div>
 
−
 
 
−
==== diff-ms-jbd-cpt-list-20070702 ====
 
−
<div class="change">
 
−
Patch from Jan Kara &lt;jack@suse.cz&gt;<br/>
 
−
[PATCH] jbd: remove_transaction fix
 
−
 
 
−
We have to check that also the second checkpoint list is non-empty before
 
−
dropping the transaction.
 
−
 
 
−
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;<br/>
 
−
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;<br/>
 
−
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
 
−
 
 
−
X-Git-Tag: v2.6.16-rc2~350<br/>
 
−
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=43c3e6f5abdf6acac9b90c86bf03f995bf7d3d92 43c3e6f5abdf6acac9b90c86bf03f995bf7d3d92]
 
−
</div>
 
−
 
 
−
==== diff-ms-net-bridge-carrier-check-20070627 ====
 
−
<div class="change">
 
−
Patch from Konstantin Khorenko &lt;khorenko@openvz.org&gt;<br/>
 
−
[PATCH] bridge: race between br_del_if() and port_carrier_check()
 
−
 
 
−
This patch eliminates a race between br_del_if() and port_carrier_check()
 
−
which leads to the oops in the latter function.
 
−
This patch is a port of 2 mainstream patches:
 
−
<pre>
 
−
[BRIDGE] br_if: Fix oops in port_carrier_check
 
−
 
 
−
Signed-off-by: Jarek Poplawski &lt;jarkao2@o2.pl&gt;
 
−
Acked-by: Stephen Hemminger &lt;shemminger@linux-foundation.org&gt;
 
−
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
 
−
commit a10d567c89dfba90dde2e0515e25760fd74cde06
 
−
</pre>
 
−
and
 
−
<pre>
 
−
[BRIDGE]: eliminate workqueue for carrier check
 
−
 
 
−
Having a work queue for checking carrier leads to lots of race issues.
 
−
Simpler to just get the cost when data structure is created and
 
−
update on change.
 
−
 
 
−
Signed-off-by: Stephen Hemminger &lt;shemminger@linux-foundation.org&gt;
 
−
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
 
−
commit 269def7c505b4d229f9ad49bf88543d1e605533e
 
−
</pre>
 
−
http://bugzilla.kernel.org/show_bug.cgi?id=7962
 
−
 
 
−
Bug #84789.
 
−
</div>
 
−
 
 
−
==== diff-ms-net-bridge-port-enable-20070627 ====
 
−
<div class="change">
 
−
Patch from Konstantin Khorenko &lt;khorenko@openvz.org&gt;<br/>
 
−
[BRIDGE]: adding new device to bridge should enable if up
 
−
 
 
−
Port of mainstream patch:
 
−
 
 
−
<pre>
 
−
[BRIDGE]: adding new device to bridge should enable if up
 
−
Aji Srinivas [Thu, 8 Mar 2007 00:10:53 +0000 (16:10 -0800)]
 
−
One change introduced by the workqueue removal patch is that adding an
 
−
interface that is up to a bridge which is also up does not ever call
 
−
br_stp_enable_port(), leaving the port in DISABLED state until we do
 
−
ifconfig down and up or link events occur.
 
−
 
 
−
The following patch to the br_add_if function fixes it.
 
−
This is a regression introduced in 2.6.21.
 
−
 
 
−
Submitted-by: Aji_Srinivas@emc.com
 
−
Signed-off-by: Stephen Hemminger &lt;shemminger@linux-foundation.org&gt;
 
−
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
 
−
 
 
−
commit de79059ecd7cd650f3788ece978a64586921d1f1
 
−
</pre>
 
−
 
 
−
Bug #84789.
 
−
</div>
 
−
 
 
−
==== diff-ms-net-bridge-via-eth-d-20070622 ====
 
−
<div class="change">
 
−
Patch from Kirill Korotaev &lt;dev@openvz.org&gt;<br/>
 
−
[PATCH] bridge: fix unaligned access to br-&gt;bridge_id
 
−
 
 
−
bridge_id is an unaligned structure of chars, which
 
−
MUST be aligned on 2 bytes boundary for compare_ether_addr().
 
−
 
 
−
However, when we added
 
−
  unsigned char                  via_phys_dev;
 
−
field to struct net_bridge we broke this inexplicit alignment.
 
−
 
 
−
So move our field to a bit another place,
 
−
returning back alignment of bridge_id.
 
−
 
 
−
Bug #84852.
 
−
</div>
 
−
 
 
−
==== diff-ms-net-sched-cbq-dbg-20070626 ====
 
−
<div class="change">
 
−
Patch from Vitaliy Gusev &lt;vgusev@openvz.org&gt;<br/>
 
−
Debug and workaround patch for "division by zero" in sch_cbq module
 
−
 
 
−
Debug and workaround patch for "division by zero" in sch_cbq module
 
−
(in cbq_normalize_quanta() function).
 
−
For some unknown reason "division by zero" occurs and this patch
 
−
should help to understand the broken math.
 
−
 
 
−
Bug #83243.
 
−
</div>
 
−
 
 
−
==== diff-ms-reiser-key-decr-20070412 ====
 
−
<div class="change">
 
−
Patch from Kirill Korotaev &lt;dev@openvz.org&gt;<br/>
 
−
[PATCH] reiserfs: fix key decrementing
 
−
 
 
−
This patch fixes a bug in function decrementing a key of stat data item.
 
−
 
 
−
Offset of reiserfs keys are compared as signed values.  To set key offset
 
−
to maximal possible value maximal signed value has to be used.
 
−
 
 
−
This bug is responsible for severe reiserfs filesystem corruption which
 
−
shows itself as warning vs-13060.  reiserfsck fixes this corruption by
 
−
filesystem tree rebuilding.
 
−
 
 
−
Signed-off-by: Vladimir Saveliev &lt;vs@namesys.com&gt;<br/>
 
−
Cc: &lt;reiserfs-dev@namesys.com&gt;<br/>
 
−
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;<br/>
 
−
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
 
−
 
 
−
X-Git-Tag: v2.6.21-rc7~16<br/>
 
−
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=6d205f120547043de663315698dcf5f0eaa31b5c 6d205f120547043de663315698dcf5f0eaa31b5c]
 
−
</div>
 
−
 
 
−
==== diff-ms-rm-proc-warn-20070508 ====
 
−
<div class="change">
 
−
Patch from Alexey Dobriyan &lt;adobriyan@openvz.org&gt;<br/>
 
−
[PATCH] proc: remove pathetic -&gt;deleted WARN_ON
 
−
 
 
−
WARN_ON(de &amp;&amp; de-&gt;deleted); is sooo unreliable. Why?
 
−
<pre>
 
−
proc_lookup remove_proc_entry
 
−
=========== =================
 
−
lock_kernel();
 
−
spin_lock(&amp;proc_subdir_lock);
 
−
[find proc entry]
 
−
spin_unlock(&amp;proc_subdir_lock);
 
−
spin_lock(&amp;proc_subdir_lock);
 
−
[find proc entry]
 
−
 
 
−
proc_get_inode
 
−
WARN_ON(de &amp;&amp; de-&gt;deleted); ...
 
−
 
 
−
if (!atomic_read(&amp;de-&gt;count))
 
−
free_proc_entry(de);
 
−
else
 
−
de-&gt;deleted = 1;
 
−
</pre>
 
−
So, if you have some strange oops [1], and doesn't see this WARN_ON it means
 
−
nothing.
 
−
 
 
−
[1] try_module_get() of module which doesn't exist, two lines below
 
−
should suffice, or not?
 
−
 
 
−
Signed-off-by: Alexey Dobriyan &lt;adobriyan@sw.ru&gt;
 
−
 
 
−
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;<br/>
 
−
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
 
−
 
 
−
X-Git-Tag: v2.6.22-rc1~756<br/>
 
−
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=578c8183c116e623d53b05d4c79762d053c7090f 578c8183c116e623d53b05d4c79762d053c7090f]
 
−
</div>
 
−
 
 
−
==== diff-rh-utrace-late-ptrace-may-attach-20070626 ====
 
−
<div class="change">
 
−
Patch from Alexey Dobriyan &lt;adobriyan@openvz.org&gt;<br/>
 
−
Code implementing ptrace_attach() does ~1/3 of job of attaching _before_
 
−
 
 
−
Code implementing ptrace_attach() does ~1/3 of job of attaching _before_
 
−
checking if attaching process have permissions to mess with target task
 
−
at all. Given the overall raciness of utrace such code is recipe for
 
−
trouble. Do ptrace_may_attach() check earlier.
 
−
 
 
−
NOTE: Right now
 
−
<source lang="c">
 
−
while (1)
 
−
ptrace(PTRACE_ATTACH, pid, NULL, NULL);
 
−
</source>
 
−
reliably (and _quickly_) crashes kernel if pid is pid of process
 
−
like syslogd normal user can't attach to:
 
−
<pre>
 
−
Unable to handle kernel NULL pointer dereference at 0000000000000000
 
−
RIP: [&lt;0000000000000000&gt;]
 
−
report_quiescent+0x36/0x154
 
−
utrace_quiescent+0x2b/0x238
 
−
utrace_get_signal+0x45d/0x4c0
 
−
get_signal_to_deliver+0x169/0x47a
 
−
do_notify_resume+0xd0/0x7e2
 
−
_spin_unlock_irqrestore+0x3f/0x45
 
−
trace_hardirqs_on+0x11b/0x13f
 
−
tty_read+0x81/0xc7
 
−
trace_hardirqs_on_thunk+0x35/0x37
 
−
trace_hardirqs_on+0x11b/0x13f
 
−
sysret_signal+0x21/0x31
 
−
ptregscall_common+0x67/0xac
 
−
</pre>
 
−
 
 
−
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245735
 
−
</div>
 
−
 
 
−
==== diff-ve-nf-nat-assertion-20070620 ====
 
−
<div class="change">
 
−
Patch from Vasily Tarasov &lt;vtaras@openvz.org&gt;<br/>
 
−
[PATCH] netfilter: wrong debug assertion in nat code
 
−
 
 
−
Simple compilation fix if NETFILTER_DEBUG is on
 
−
</div>
 
−
 
 
−
==== diff-ve-rm-nf_debug-20070620 ====
 
−
<div class="change">
 
−
Patch from Vasily Tarasov &lt;vtaras@openvz.org&gt;<br/>
 
−
[PATCH] netfilter: skb struct doesn't have nf_debug anymore
 
−
 
 
−
nf_debug field is missing in modern kernels,
 
−
but in some places we still refer to it.
 
−
 
 
−
{{bug|627}}.
 
−
</div>
 
−
 
 
−
==== diff-ve-veinfo-large-space-20070620 ====
 
−
<div class="change">
 
−
Patch from Vasily Tarasov &lt;vtaras@openvz.org&gt;<br/>
 
−
[PATCH] venet: lots of spaces in /proc/vz/veinfo output
 
−
 
 
−
After introducing IPv6 support for venet device, field width for IP
 
−
addresses in /proc/vz/veinfo was increased from 15 to 39:
 
−
http://git.openvz.org/?p=linux-2.6.16-openvz;a=commitdiff;h=ddb2b95ff38b528f5def1bd4ae87108bf3fa6b7a
 
−
 
 
−
The output seems a bit ridiculous, when VE owns only IPv4 addresses: to
 
−
much strange spaces.
 
−
 
 
−
This patch corrects it and fixes the bug:
 
−
 
 
−
{{bug|625}}.
 
−
</div>
 
−
 
 
−
==== diff-xen-x8664-subarch-changes-20070702 ====
 
−
<div class="change">
 
−
Patch from Evgeny Kravtsunov &lt;emkravts@openvz.org&gt;<br/>
 
−
[PATCH] Xen: x8664 OVZ changes
 
−
 
 
−
x8664 Xen OVZ changes according to x8664 arch changes.
 
−
</div>
 
−
 
 
−
==== diff-arch-4gb-copy-mnt-options-20070703 ====
 
−
<div class="change">
 
−
Patch from Andrey Mirkin &lt;major@openvz.org&gt;<br/>
 
−
[PATCH] 4GB split: add KERNEL_DS handling to copy_mount_options()
 
−
 
 
−
On i386 arch with 4gb split kernel addresses can be more than
 
−
TASK_SIZE (e.g. &gt; 0xc0000000).
 
−
That causes copy_mount_options() to return -EFAULT
 
−
when called with kernel supplied buffers, i.e.
 
−
when get_fs() == KERNEL_DS.
 
−
 
 
−
Bug #85041.
 
−
</div>
 
−
 
 
−
==== diff-fairsched-off-comp-20070712 ====
 
−
<div class="change">
 
−
Patch from Alexandr Andreev &lt;aandreev@openvz.org&gt;<br/>
 
−
[PATCH]: small fix to compile kernel without VCPU support
 
−
</div>
 
−
 
 
−
==== diff-ms-security-h323-20070706 ====
 
−
<div class="change">
 
−
Patch from Jing Min Zhao &lt;zhaojingmin@vivecode.com&gt;<br/>
 
−
[NETFILTER]: nf_conntrack_h323: add checking of out-of-range on choices' index values
 
−
 
 
−
Choices' index values may be out of range while still encoded in the fixed
 
−
length bit-field. This bug may cause access to undefined types (NULL
 
−
pointers) and thus crashes (Reported by Zhongling Wen).
 
−
 
 
−
This patch also adds checking of decode flag when decoding SEQUENCEs.
 
−
 
 
−
Signed-off-by: Jing Min Zhao &lt;zhaojingmin@vivecode.com&gt;<br/>
 
−
Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
 
−
</pre>
 
−
</div>
 
−
 
 
−
==== diff-ms-security-random-buf-20070711 ====
 
−
<div class="change">
 
−
Patch from Matt Mackall &lt;mpm@selenic.com&gt;<br/>
 
−
[PATCH] PaX: wakeup threshold limits
 
−
 
 
−
If root raised the default wakeup threshold over the size of the
 
−
output pool, the pool transfer function could overflow the stack with
 
−
RNG bytes.
 
−
 
 
−
(Bug reported by the PaX Team &lt;pageexec@freemail.hu&gt;)
 
−
 
 
−
Cc: Theodore Tso &lt;tytso@mit.edu&gt;<br/>
 
−
Cc: Willy Tarreau &lt;w@1wt.eu&gt;<br/>
 
−
Signed-off-by: Matt Mackall &lt;mpm@selenic.com&gt;<br/>
 
−
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
 
−
 
 
−
drivers/char/random.c |    9 +++++++--
 
−
1 files changed, 7 insertions(+), 2 deletions(-)
 
−
</div>
 
−
 
 
−
==== diff-ms-shmem-lock-user-leak-20070716 ====
 
−
 
 
−
<div class="change">
 
−
Patch from Pavel Emelianov &lt;xemul@openvz.org&gt;<br/>
 
−
[PATCH] IPC: fix potential user leak
 
−
 
 
−
When user locks an ipc shmem segmant with SHM_LOCK ctl and the
 
−
segment is already locked the shmem_lock() function returns 0. After this the subsequent code leaks the existing user struct:
 
−
 
 
−
== ipc/shm.c: sys_shmctl() ==
 
−
<source lang="c">
 
−
...
 
−
err = shmem_lock(shp-&gt;shm_file, 1, user);
 
−
if (!err) {
 
−
    shp-&gt;shm_perm.mode |= SHM_LOCKED;
 
−
    shp-&gt;mlock_user = user;
 
−
}
 
−
...
 
−
</source>
 
−
Other results of this are:
 
−
# the new shp-&gt;mlock_user is not get-ed and will point to freed memory when the task dies.
 
−
# the RLIMIT_MEMLOCK is screwed on both user structs.
 
−
 
 
−
The exploit looks like this:
 
−
 
 
−
  id = shmget(...);
 
−
  setresuid(uid, 0, 0);
 
−
  shmctl(id, SHM_LOCK, NULL);
 
−
  setresuid(uid + 1, 0, 0);
 
−
  shmctl(id, SHM_LOCK, NULL);
 
−
 
 
−
My solution is to return 0 to the userspace and do not change the
 
−
segment's user.
 
−
 
 
−
Bug #78998.
 
−
</div>
 
−
 
 
−
==== diff-ms-swiotlb-phys-to-virt-20070713 ====
 
−
<div class="change">
 
−
Patch from David Moore &lt;dcm@acm.org&gt;<br/>
 
−
[PATCH] swiotlb: add missing phys_to_virt() call
 
−
 
 
−
Adds missing call to phys_to_virt() in the
 
−
lib/swiotlb.c:swiotlb_sync_sg() function.  Without this change, a kernel
 
−
panic will always occur whenever a SWIOTLB bounce buffer from a
 
−
scatter-gather list gets synced.  Affected are especially Intel x86_64
 
−
machines with more than about 3 GB RAM.
 
−
 
 
−
Signed-off-by: David Moore &lt;dcm@acm.org&gt;<br/>
 
−
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;<br/>
 
−
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
 
−
 
 
−
[http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.20.y.git;a=commitdiff_plain;h=e16b67f9a0ac6d9f89f680b7f3b439abfb1dac5e e16b67f9a0ac6d9f89f680b7f3b439abfb1dac5e]
 
−
 
 
−
{{bug|645}}.
 
−
</div>
 
−
 
 
−
==== diff-ubc-mmap-accounting-flags-20070709 ====
 
−
<div class="change">
 
−
 
 
−
Patch from Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;<br/>
 
−
[PATCH] BC: recharge vma if vm_flags changed after -&gt;mmap() call
 
−
 
 
−
Several device drivers (sigh... ATI) can change vm_flags
 
−
in their f_op-&gt;mmap method. Because of this mm-&gt;locked_vm
 
−
changed after f_op-&gt;mmap was called.
 
−
If -&gt;vm_flags has been changed we have to recharge ub memory.
 
−
</div>
 
−
 
 
−
==== diff-ubc-ub-pb-conflict-20070710 ====
 
−
 
 
−
<div class="change">
 
−
Patch from Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;<br/>
 
−
[PATCH] BC: aidband - uncharge UB pages before charging to PB
 
−
 
 
−
By design we assume that page may be accounted only in UB or only
 
−
in PB counter.
 
−
 
 
−
Unfortunately this is not always true, and ATI driver does
 
−
some strange things like mmaping pages with PTEs to user space
 
−
(maybe it is even a security hole in ATI driver, who knows?)
 
−
 
 
−
So ATI driver exports pages via mmap(2) to userspace
 
−
which was already accounted in UB (pte pages are charged to kmemsize).
 
−
In this case accounting conflict happens and
 
−
BUG_ON(head-&gt;pb_magic != PB_MAGIC) is triggered.
 
−
 
 
−
Solution: Uncharge page from UB counter and account it in PB.
 
−
 
 
−
Changes from v1: Add WARN_ON_ONCE according to Pavel's cmomments.
 
−
</div>
 
−
 
 
−
==== diff-ve-allow-kthreads-20070716 ====
 
−
<div class="change">
 
−
Patch from Denis Lunev &lt;den@openvz.org&gt;<br/>
 
−
[PATCH] allow kthreads by default in VE (for NFS)
 
−
 
 
−
This patch allows kernel threads by default inside VE.
 
−
</div>
 
−
 
 
−
==== diff-ve-net-protocols-check-20070705 ====
 
−
<div class="change">
 
−
Patch from Evgeny Kravtsunov &lt;emkravts@openvz.org&gt;<br/>
 
−
When creating socket within VE the following ones are allowed:
 
−
 
 
−
<pre class="simple">
 
−
-----------------------------------------------------------------------------------
 
−
  family            |      type                  |  protocol
 
−
---------------------------------------------------------------------------------
 
−
  PF_UNIX            |                            |
 
−
  PF_LOCAL          |                            |
 
−
  PF_PACKET          |  Any existing*              |  Any existing
 
−
  PF_NETLINK        |                            |
 
−
---------------------------------------------------------------------------------
 
−
  PF_INET            | SOCK_DGRAM  +  IPPROTO_UDP
 
−
                    | SOCK_STREAM +  IPPROTO_TCP
 
−
                    | SOCK_RAW    +  Any
 
−
                    |                            |  forced to
 
−
                    |                            |  IPPROTO_IP
 
−
---------------------------------------------------------------------------------
 
−
  PF_INET6          | SOCK_DGRAM  +  IPPROTO_UDP
 
−
                    | SOCK_STREAM +  IPPROTO_TCP
 
−
                    | SOCK_RAW    +  Any
 
−
                    |                            |  forced to
 
−
                    |                            |  IPPROTO_IP
 
−
--------------------------------------------------------------------------------
 
−
</pre>
 
−
Here "any existing" means that only SOCK_RAW and SOCK_DGRAM will work:
 
−
other ones will be rejected by corresponding -&gt;create function (for.ex.
 
−
netlink_create). And this reject is ok, as it is not bug provoking.
 
−
 
 
−
Other families (PF_IPX, PF_X25, PF_AX25, PF_ATMPVC, PF_APPLETALK) are not
 
−
allowed for sockets within VE as they are not virtualized.
 
−
 
 
−
The problem is function vz_security_proto_check prevents creating sockets with
 
−
family=PF_INET/PF_INET6 type=SOCK_RAW protocol=(something except IP, UDP,
 
−
TCP, ICMP, RAW) which are valid according to source.
 
−
 
 
−
Patch splits vz_security_proto_check into 2 separate checks: 1) family check
 
−
vz_security_family_check and 2) protocol check vz_security_protocol_check.
 
−
First one checks is the family value allowed in __sock_create, second one -
 
−
checks if created socket contains the correct (virtualized) protocol.
 
−
vz_security_protocol_check is placed inside create functions inet_create and
 
−
inet6_create. This change will allow to create any socket within VE with type
 
−
SOCK_RAW for any protocol that is not implemented in kernel and encapsulates
 
−
its packets into IP packet (for example VRRP protocol).
 
−
 
 
−
In rtnetlink_dump_all and rtnetlink_rcv_msg functions calls of
 
−
vz_security_proto_check are replaced by the call of vz_security_family_check.
 
−
 
 
−
Patch implements default deny security policy.
 
−
 
 
−
{{bug|611}}.
 
−
</div>
 
−
 
 
−
==== diff-ve-net-udp-regress-20070712 ====
 
−
<div class="change">
 
−
Patch from Vitaliy Gusev &lt;vgusev@openvz.org&gt;<br/>
 
−
[PATCH] net: excessive UDP lost on VE send path
 
−
 
 
−
When tring to send big UDP packets from VE then other side
 
−
receive about 60% of all IP fragmentated packets and about 10% of all UDP packets
 
−
that was sent from VE. Fragmentated IP-packets are dropped on an ethernet interface
 
−
because an interface's queue is full.
 
−
 
 
−
The ethernet interface's queue get full as venet/veth device passes
 
−
fragmentated IP-packet with calling a sk_buff's destructor (by skb_orphan),
 
−
socket's buffer become free, although it
 
−
IP-packet isn't passed through the ethernet device.
 
−
Therefore bulk IP-packets are sent through venet/veth interface
 
−
that is much more than the real ethernet interface can transfer.
 
−
 
 
−
Decision:
 
−
venet/veth interface call skb_orphan only for non IP-packets.
 
−
For IP packets skb_orhpan (actually destructor) is called later:
 
−
in IP local or when skb is delivered to ethernet and __kfree_skb() is called.
 
−
 
 
−
Tested with venet, veth, veth + vlan (host-node).
 
−
 
 
−
Thanks to Denis Lunev and Alexey Kuznetsov for ideas and help.
 
−
</div>
 
−
 
 
−
==== diff-ve-nfs-stop-c-20070704 ====
 
−
<div class="change">
 
−
Patch from Denis Lunev &lt;den@openvz.org&gt;<br/>
 
−
This patch ensures that VE is up and running during RPC connect. This
 
−
 
 
−
This patch ensures that VE is up and running during RPC connect. This
 
−
staff can be run as a schedule_work when all tasks has been dead.
 
−
 
 
−
{{bug|513}}.
 
−
</div>
 
−
 
 
−
==== diff-ve-vpid-tsk-pgid-20070706 ====
 
−
<div class="change">
 
−
Patch from Kirill Korotaev &lt;dev@openvz.org&gt;<br/>
 
−
[PATCH] VE: sys_getpgid/sid should depend on context
 
−
 
 
−
sys_getpgid/sid() should return global pid of
 
−
VE task if info is requisted from VE0 task.
 
−
Actually, not critical, but still. let's fix it.
 
−
 
 
−
Bug #85662.
 
−
</div>
 
−
 
 
−
==== diff-xen-x8664-subarch-changes-b-20070709 ====
 
−
<div class="change">
 
−
Patch from Evgeny Kravtsunov &lt;emkravts@openvz.org&gt;<br/>
 
−
Patch fixes compilation error: XEN_CPUID is undefined in
 
−
 
 
−
Patch fixes compilation error: XEN_CPUID is undefined in
 
−
include/asm-x86_64/mach-xen/asm/msr.h. To define XEN_CPUID on x84_64 patch
 
−
attached makes msr.h to include xen/interface/arch-x86_64.h.
 
−
<pre class="simple">
 
−
linux-2.6.18-drbd-8.0.3-8.0.4.patch:
 
−
Patch prepared by Evgeniy Kravtsunov:
 
−
DRBD driver update 8.0.3 -&gt; 8.0.4
 
−
</pre>
 
−
Patch attached updates drbd version from 8.0.3 to 8.0.4.
 
−
In 8.0.4 a set of oopses is fixed according to drbd changelog:
 
−
http://svn.drbd.org/drbd/trunk/ChangeLog.
 
−
 
 
−
{{bug|615}}.
 
−
</div>
 
−
 
 
−
==== diff-megaraid-64bit-dma-20070716 ====
 
−
 
 
−
<div class="change">
 
−
Patch from Vasily (vvs@):
 
−
 
 
−
RHEL5 forget to apply last of our megaraid_mbox fixes:
 
−
http://forum.openvz.org/index.php?t=msg&amp;goto=14975
 
−
<pre class="simple">
 
−
From: Andrey Mirkin &lt;amirkin@sw.ru&gt;
 
−
Date: Mon, 16 Oct 2006 08:08:43 +0000 (+0400)
 
−
Subject: [PATCH] scsi: megaraid_{mm,mbox}: 64-bit DMA capability fix
 
−
X-Git-Tag: v2.6.19-rc3~208
 
−
X-Git-Url:
 
−
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=8741ca71a3f626a56595b88200ebf952ce77ceef
 
−
 
 
−
[PATCH] scsi: megaraid_{mm,mbox}: 64-bit DMA capability fix
 
−
 
 
−
It is known that 2 LSI Logic MegaRAID SATA RAID Controllers (150-4 and
 
−
150-6) don't support 64-bit DMA.  Unfortunately currently this check is
 
−
wrong and driver sets 64-bit DMA mode for these devices.
 
−
 
 
−
Signed-off-by: Andrey Mirkin &lt;amirkin@sw.ru&gt;
 
−
Acked-by: Vasily Averin &lt;vvs@sw.ru&gt;
 
−
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
 
−
</pre>
 
−
</div>
 
−
 
 
−
==== diff-gfs-bh-leak-fix-20070716 ====
 
−
<div class="change">
 
−
Patch from Dmitry Monakhov (dmonakhov@):<br/>
 
−
If gfs_blk2rgrpd() has failed bh is leaked on error path in gfs_shrink().
 
−
</div>
 
−
 
 
−
==== diff-backport-dm-delay-20070716 ====
 
−
<div class="change">
 
−
Patch from Vagin Andrey (avagin@):
 
−
 
 
−
Device-Mapper's "delay" target delays reads and/or writes
 
−
and maps them to different devices.
 
−
 
 
−
QA team needs this feature to do certain tests on top of a slow storage:
 
−
vzabackup, filesystem tests, etc.
 
−
 
 
−
Backport from 2.6.22.
 
−
</div>
 
−
 
 
−
==== diff-ms-emt64-swsusp-oops-20070717 ====
 
−
<div class="change">
 
−
Patch from Alexandr Andreev &lt;aandreev@openvz.org&gt;<br/>
 
−
[PATCH] x86-64: do not use virt_to_page on kernel data address
 
−
 
 
−
* virt_to_page() call should be used on kernel linear addresses and not on kernel text and data addresses. Swsusp code uses it on kernel data (statically allocated swsusp_header).
 
−
 
 
−
* Allocate swsusp_header dynamically so that virt_to_page() can be used safely.
 
−
 
 
−
* I am changing this because in next few patches, __pa() on x86_64 will no longer support kernel text and data addresses and hibernation breaks.
 
−
 
 
−
Signed-off-by: Vivek Goyal &lt;vgoyal@in.ibm.com&gt;<br/>
 
−
Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
 
−
 
 
−
[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1b29c1643c0d82512477ccd97dc290198fe23e22 1b29c1643c0d82512477ccd97dc290198fe23e22]
 
−
 
 
−
[SWSUSP]: correct virt_to_page() usage in swsusp
 
−
 
 
−
Bug #86406.
 
−
</div>
 
−
 
 
−
==== diff-ms-net-cbq-fairness2-20070720 ====
 
−
<div class="change">
 
−
Patch from Vitaliy Gusev &lt;vgusev@openvz.org&gt;<br/>
 
−
[PATCH] CBQ: fix unfairness when gettimeofday clock source is used
 
−
 
 
−
sch_cbq with gettimeofday clock source has limit 2000000 usec for the idle
 
−
(undertime) time.
 
−
Therefore when we try to set bandwidth less than 10000 bits/s then
 
−
sch_cbq doesn't work (idle time want to become about 4000000 usec).
 
−
 
 
−
Triggered by RHEL5 which switched from jiffies clocksource to gettimeofday()
 
−
BTW, why? According to ANK this should work poorly, since
 
−
gettimeofday can take as much as 100 microseconds...
 
−
 
 
−
Bug #86375.
 
−
</div>
 
−
 
 
−
==== diff-ubc-proc-issues-20070717 ====
 
−
<div class="change">
 
−
Patch from Pavel Emelianov &lt;xemul@openvz.org&gt;<br/>
 
−
[PATCH] BC: fix several issues in /proc/bc
 
−
 
 
−
find /proc/bc doesn't work with several errors reported.
 
−
 
 
−
Reasons:
 
−
# getdents() sometimes returns EOVERFLOW due to sign expansion in generated entries' inode numbers;
 
−
# bc and subbc have equal generated inode numbers;
 
−
# /proc/bc has broken (from find's POV) nlink count.
 
−
 
 
−
Fix it all.
 
−
</div>
 
−
 
 
−
==== diff-ve-allow-ethtool-20070718 ====
 
−
<div class="change">
 
−
Patch from Vitaliy Gusev &lt;vgusev@openvz.org&gt; <br/>
 
−
[PATCH] net: allow ethtool ops inside VE
 
−
 
 
−
This patch allows ethtool operations into VE with
 
−
CAP_VE_NET_ADMIN capability.
 
−
</div>
 
−
 
 
−
==== diff-ve-net-udp-regress-b-20070716 ====
 
−
<div class="change">
 
−
Patch from Vitaliy Gusev &lt;vgusev@openvz.org&gt; <br/>
 
−
[PATCH] venet: compilation warning fix
 
−
 
 
−
label "out" is not used anymore. Fix the warning.
 
−
</div>
 
−
 
 
−
==== diff-ve-opseminit-20070723 ====
 
−
<div class="change">
 
−
Patch from Denis Lunev &lt;den@openvz.org&gt; <br/>
 
−
[PATCH] initialize ve0.op_sem earlier
 
−
 
 
−
ve0-&gt;op_sem has been initialized on vecalls modules loading,
 
−
but nowdays can be used before vzmon during NFS initialization...
 
−
 
 
−
Bug #86869.
 
−
</div>
 
−
 
 
−
==== diff-ve-vpsdumpable-extend-b-20070718 ====
 
−
<div class="change">
 
−
Patch from Alexey Dobriyan &lt;adobriyan@openvz.org&gt; <br/>
 
−
[PATCH] ptrace: fix task-&gt;mm dereference out of task_lock()
 
−
 
 
−
Utrace code removed task_lock() around -&gt;mm checks in ptrace_attach(),
 
−
but -&gt;mm-&gt;vps_dumpable continued to be checked without task_lock().
 
−
</div>
 
−
</noinclude>
 

Revision as of 15:45, 22 October 2009

For most of our generation, the management and ownership have turned us off from the organization. ,