6,534
edits
Changes
created
== Changes ==
* Major x8664 security fix (CVE-2007-4573)
* Other security fixes
* Rebase to RHEL5 8.1.14 kernel
* areca and DRBD driver updates
* Fixes for NFS client in VE, CPT, UBC, VZDQ, IPv6, fairsched, 4GB split.
=== Config changes ===
Added:
* +<code>CONFIG_PREEMPT_VOLUNTARY=y</code>
* +<code>CONFIG_REISERFS_FS=m</code>
* +<code>CONFIG_REISERFS_PROC_INFO=y</code>
* +<code>CONFIG_REISERFS_FS_XATTR=y</code>
* +<code>CONFIG_REISERFS_FS_POSIX_ACL=y</code>
* +<code>CONFIG_JFS_FS=m</code>
* +<code>CONFIG_JFS_POSIX_ACL=y</code>
* +<code>CONFIG_XFS_FS=m</code>
* +<code>CONFIG_XFS_QUOTA=y</code>
* +<code>CONFIG_XFS_POSIX_ACL=y</code>
Removed:
* -<code>CONFIG_PREEMPT_NONE</code>
* -<code>CONFIG_DEBUG_HIGHMEM</code>
<includeonly>[[{{PAGENAME}}/changes#Patches|{{Long changelog message}}]]</includeonly><noinclude>
=== Patches ===
==== diff-i2o-iosched-fix-20070806 ====
<div class="change">
Patch from Alexey Kuznetsov (alexey@):
It is I2O device, which siffers of the same problem, which I found
with nbd.
The fact that this is troggered even with anticipatory scheduler
says that this scheduler is broken as well, only race window is more narrow.
<source lang="c">
if (ad->changed_batch && ad->nr_dispatched == 1) {
kblockd_schedule_work(&ad->antic_work);
ad->changed_batch = 0;
if (ad->batch_data_dir == REQ_SYNC)
ad->new_batch = 1;
}
</source>
I guess that it freezes when we hit this place with changed_batch==0.
</div>
==== diff-cpt-lock-fd-fix-20070822 ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org> <br/>
[PATCH] CPT: correct handling of lock fd error codes
Undump in CPT is performed in 2 stages (create env and init process; full
undump). These 2 stages are separated with help of pipe: when this pipe is
closed from vzctl we can proceed with second stage in CPT.
So, possible scenario is following:
1. We are waiting in CPT in pipe_read() when pipe will be closed.
2. someone is sending signal to our task which is waiting in pipe_read().
3. pipe_read() exits with -ERESTARTSYS, but we ignore this error and continue
with undump process, but vzctl do not perform all intermediate stages, so we
can't proceed with undump.
Bug #88618.
</div>
==== diff-debug-busy-inodes-b-20070828 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org>
Additional debug for busy inodes after umount:
print more dentry information
</div>
==== diff-ms-bond802.3ad-carrier-20070818 ====
<div class="change">
Patch from Jay Vosburgh <fubar@us.ibm.com><br/>
[PATCH] bonding: Fix 802.3ad no carrier on "no partner found" instance
Modify carrier state determination for 802.3ad mode to comply
with section 43.3.9 of IEEE 802.3, which requires that "Links that are
not successful candidates for aggregation (e.g., links that are attached
to other devices that cannot perform aggregation or links that have been
manually configured to be non-aggregatable) are enabled to operate as
individual IEEE 802.3 links."
Bug reported by Laurent Chavey <chavey@google.com>. This patch
is an updated version of his patch that changes the wording of
commentary and adds an update to the driver version.
<pre class="simple">
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Laurent Chavey <chavey@google.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
</pre>
GIT: 031ae4deb095a1f18a842740459c5ae184ec931c
{{bug|666}}
</div>
==== diff-ms-proc-enoent-if-task-is-dead-20070824 ====
<div class="change">
Patch from Pavel Emelianov <xemul@openvz.org> <br/>
[PATCH proc: return ENOENT instead of EACCESS when task is dead
When reading the symlink /proc/<pid>/exe or /proc/<pid>/fd/<any>
of a task, that has managed to die after opening the appropriate
dir, but before reading the symlink, kernel returns -EACCESS due
to strange code in proc_fd_access_allowed().
Unlike the ms/RHEL5 kernel, the SuSE kernel returns -ENOENT in this
case and it turned out, that some SuSE software (inetd) is aware
of it and cannot stand any deviations.
Make the kernel return -ENOENT when the task is dead to make VEs
based on SuSE templates work. Keep the return value in any other
case (-EACCESS).
Bug #82009.
</div>
==== diff-ms-security-signals-20070817 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org><br/>
[PATCH] Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)
Severity: minor
This fixes a vulnerability in the "parent process death signal"
implementation discoverd by Wojciech Purczynski of COSEINC PTE Ltd.
and iSEC Security Research.
http://marc.info/?l=bugtraq&m=118711306802632&w=2
<pre class="simple">
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
</pre>
X-Git-Tag: v2.6.22.4~1<br/>
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.22.y.git;a=commitdiff_plain;h=c27a3393808acab7243da7455c713fe763ea2627 c27a3393808acab7243da7455c713fe763ea2627]
</div>
==== diff-ms-sigqueue-race-20070828 ====
<div class="change">
Patch from Oleg Nesterov <oleg@tv-sign.ru><br/>
[PATCH] sigqueue_free: fix the race with collect_signal()
Spotted by taoyue <yue.tao@windriver.com> and Jeremy Katz <jeremy.katz@windriver.com>.
<pre class="simple">
collect_signal: sigqueue_free:
list_del_init(&first->list);
if (!list_empty(&q->list)) {
// not taken
}
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(first); __sigqueue_free(q);
</pre>
Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the
obviously bad implications.
In particular, this double free breaks the array_cache->avail logic, so the
same sigqueue could be "allocated" twice, and the bug can manifest itself via
the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue.
Hopefully this can explain these mysterious bug-reports, see
http://marc.info/?t=118766926500003<br/>
http://marc.info/?t=118466273000005
Alexey Dobriyan reports this patch makes the difference for the testcase, but
nobody has an access to the application which opened the problems originally.
Also, this patch removes tasklist lock/unlock, ->siglock is enough.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru><br/>
Cc: taoyue <yue.tao@windriver.com><br/>
Cc: Jeremy Katz <jeremy.katz@windriver.com><br/>
Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com><br/>
Cc: Alexey Dobriyan <adobriyan@sw.ru><br/>
Cc: Ingo Molnar <mingo@elte.hu><br/>
Cc: Thomas Gleixner <tglx@linutronix.de><br/>
Cc: Roland McGrath <roland@redhat.com><br/>
Cc: <stable@kernel.org><br/>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
</div>
==== diff-ubc-ioprio-exports-20070823 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
[PATCH] UBC: add CFQ ioprio exports for CONFIG_IOSCHED_CFQ=m case
<pre class="simple">
Add CFQ ioprio exports for CONFIG_IOSCHED_CFQ=m case
</pre>
{{bug|669}}
</div>
==== diff-ubc-tcp-wakeup-20070823 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] UBC: missed wakup on one ub refill path
The following scenario is possible:
* TCPSNDBUF rejected by ub_sock_get_wreserv
* sys_poll -> ub_sock_snd_queue_add
* uncharge -> sk->sk_write_space DOES NOT wakeup the waiting poll as the queue is too long
After this, no one will wakeup the process :(
And it will block till the poll timeout end.
The patch makes sure, that the generic code will send wakeup when appropriate.
Bug #89127
</div>
==== diff-ve-nfs-client-lookup-20070817 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
This patch fixes NFS client socket transport creation.
This patch fixes NFS client socket transport creation.
RPC client is cached in NFS client structure.
So, correct allocation/lookup for NFS client.
</div>
==== diff-ve-nfs-xdev-20070817 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org>
This patch allows VE to traverse mountpoints if exported NFS tree contains ones.
</div>
==== diff-ve-venet-rmmod-20070824 ====
<div class="change">
Patch from Vitaliy Gusev <vgusev@openvz.org> <br/>
[PATCH] VENET: allow rmmod even if VE0 venet is UP
This patch allows delete module even if venet ifterface in VE0 is up.
Note, we must shutdown all interfaces in others VEs before delete module still.
Bug #83537
</div>
==== linux-2.6.18-drbd-8.0.4-8.0.5.patch ====
<div class="change">
Patch from DRBD, prepared by Evgeniy Kravtsunov:<br/>
Update drbd from 8.0.4 to 8.0.5.
</div>
==== diff-ubc-unaligned-to-pb-20070829 ====
<div class="change">
Patch from Vitaliy Gusev <vgusev@openvz.org><br/>
[PATCH] BC: fix unaliagned access on ia64
struct page contains union of the fields:
<source lang="c">
union {
struct user_beancounter *page_ub;
struct page_beancounter *page_pb;
} bc;
</source>
and there are three cases for value 'bc':
1) pointer to user_beancounter<br/>
2) pointer to page_beancounter<br/>
3) IO marked pointer to page_beancounter
This patch corrects access to 3-rd case pointer.
Bug #86554.
</div>
==== diff-ve-net-lost-reset-env-20070831 ====
<div class="change">
Patch from Pavel Emelianov <xemul@openvz.org> <br/>
[PATCH] IPv6: lost exec env reset in number of places
On is in for() loop - we could got to next loop iteration and
make the original env lost.
The other two are in error paths.
</div>
==== diff-dlm-fix-user-unlocking-20070829 ====
<div class="change">
Bug #88675.
From Andrey Mirkin, backported from mainstream:
The following patches are ported from mainstream to fix deadlock in dlm
The problem was in this path:
<pre class="simple">
do_exit
put_files_struct
...
dlm_clear_proc_locks <<< Here we are taking mutex ls_clear_proc_locks
unlock_lock
do_unlock
grant_pending_locks
grant_lock_pending
dlm_user_add_ast <<< Here we are trying to take the same mutex
</pre>
Following patches changes lock/unlock mechanism and fixes this and other
deadlocks which are present in rhel5 kernel.
Tested on 2.6.18-rhel5-041.1 kernel.
<pre class="simple">
diff-tree a1bc86e6bddd34362ca08a3a4d898eb4b5c15215 (from 1d6e8131cf0064ef5ab5f3411a82b800afbfadee)
Author: David Teigland <teigland@redhat.com>
Date: Mon Jan 15 10:34:52 2007 -0600
[DLM] fix user unlocking
When a user process exits, we clear all the locks it holds. There is a
problem, though, with locks that the process had begun unlocking before it
exited. We couldn't find the lkb's that were in the process of being
unlocked remotely, to flag that they are DEAD. To solve this, we move
lkb's being unlocked onto a new list in the per-process structure that
tracks what locks the process is holding. We can then go through this
list to flag the necessary lkb's when clearing locks for a process when it
exits.
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
</pre>
</div>
==== diff-dlm-can-miss-clearing-resend-flag-20070829 ====
<div class="change">
Patch from Andrey (amirkin@) ported from mainstream:
[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b790c3b7c38aae28c497bb363a6fe72f7c96568f b790c3b7c38aae28c497bb363a6fe72f7c96568f]
<pre class="simple">
Author: David Teigland <teigland@redhat.com>
Date: Wed Jan 24 10:21:33 2007 -0600
[DLM] can miss clearing resend flag
A long, complicated sequence of events, beginning with the RESEND flag not
being cleared on an lkb, can result in an unlock never completing.
- lkb on waiters list for remote lookup
- the remote node is both the dir node and the master node, so
it optimizes the lookup into a request and sends a request
reply back
- the request reply is saved on the requestqueue to be processed
after recovery
- recovery runs dlm_recover_waiters_pre() which sets RESEND flag
so the lookup will be resent after recovery
- end of recovery: process_requestqueue takes saved request reply
which removes the lkb off the waitesr list, _without_ clearing
the RESEND flag
- end of recovery: dlm_recover_waiters_post() doesn't do anything
with the now completed lookup lkb (would usually clear RESEND)
- later, the node unmounts, unlocks this lkb that still has RESEND
flag set
- the lkb is on the waiters list again, now for unlock, when recovery
occurs, dlm_recover_waiters_pre() shows the lkb for unlock with RESEND
set, doesn't do anything since the master still exists
- end of recovery: dlm_recover_waiters_post() takes this lkb off
the waiters list because it has the RESEND flag set, then reports
an error because unlocks are never supposed to be handled in
recover_waiters_post().
- later, the unlock reply is received, doesn't find the lkb on
the waiters list because recover_waiters_post() has wrongly
removed it.
- the unlock operation has been lost, and we're left with a
stray granted lock
- unmount spins waiting for the unlock to complete
The visible evidence of this problem will be a node where gfs umount is
spinning, the dlm waiters list will be empty, and the dlm locks list will
show a granted lock.
The fix is simply to clear the RESEND flag when taking an lkb off the
waiters list.
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
</pre>
Bug #88675
</div>
==== diff-dlm-overlapping-cancel-and-unlock-20070829 ====
<div class="change">
Patch from Andrey (amirkin@) ported from mainstream:
[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef0c2bb05f40f9a0cd2deae63e199bfa62faa7fa ef0c2bb05f40f9a0cd2deae63e199bfa62faa7fa]
Author: David Teigland <teigland@redhat.com><br/>
Date: Wed Mar 28 09:56:46 2007 -0500
<pre class="simple">
[DLM] overlapping cancel and unlock
Full cancel and force-unlock support. In the past, cancel and
force-unlock wouldn't work if there was another operation in progress on
the lock. Now, both cancel and unlock-force can overlap an operation on
a lock, meaning there may be 2 or 3 operations in progress on a lock in
parallel. This support is important not only because cancel and
force-unlock are explicit operations that an app can use, but both are
used implicitly when a process exits while holding locks.
Summary of changes:
- add-to and remove-from waiters functions were rewritten to handle
situations with more than one remote operation outstanding on a lock
- validate_unlock_args detects when an overlapping cancel/unlock-force
can be sent and when it needs to be delayed until a request/lookup
reply is received
- processing request/lookup replies detects when cancel/unlock-force
occured during the op, and carries out the delayed cancel/unlock-force
- manipulation of the "waiters" (remote operation) state of a lock moved
under the standard rsb mutex that protects all the other lock state
- the two recovery routines related to locks on the waiters list changed
according to the way lkb's are now locked before accessing waiters state
- waiters recovery detects when lkb's being recovered have overlapping
cancel/unlock-force, and may not recover such locks
- revert_lock (cancel) returns a value to distinguish cases where it did
nothing vs cases where it actually did a cancel; the cancel completion
ast should only be done when cancel did something
- orphaned locks put on new list so they can be found later for purging
- cancel must be called on a lock when making it an orphan
- flag user locks (ENDOFLIFE) at the end of their useful life (to the
application) so we can return an error for any further
cancel/unlock-force
- we weren't setting COMP/BAST ast flags if one was already set, so we'd
lose either a completion or blocking ast
- clear an unread bast on a lock that's become unlocked
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
</pre>
Bug #88675
</div>
==== linux-2.6.18-arcmsr-1.20.0X.14.devel.patch ====
<div class="change">
Patch prepared by Kostja (khorenko@):
<br/>
Areca driver v1.20.0X.14.devel provided to Thomas Krenn AG by Areca people.
Areca driver v1.20.0X.14.devel provided to Thomas Krenn AG by Areca people.
Declared to fix the memory leak problem caused by Areca command line
utility (about 7 MB per execution of the CLI according to Thomas Krenn AG).
P.S. the issue with ARCMSR_MAX_XFER_SECTORS[_B] fixed.
Bug #87569.
</div>
==== diff-arch-4gb-ldt-leak-20070918 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org><br/>
[PATCH] fix possible page leak during LDT allocation
Fix possible page leak during LDT allocation:
alloc_ldt() doesn't free new pages on error path and
doesn't change context->size value.
Thus we can have more pages on destroy_context() than
we think we have according to our context->size.
Let's scan all 16 pages to make sure everything is freed.
</div>
==== diff-cpt-remove-local-var-20070911 ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org> <br/>
[PATCH] CPT: lock fd close correct error handling
Lock fd close correct error handling:
on undump local variable 'err' was used to store an error,
that is why this error was ignored and undump continues
in spite of the error.
</div>
==== diff-cpt-rst-ldt-leak-20070918 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
[PATCH] CPT: fix LDT pages leak with 4GB split
In case 4GB split kernel is used, CPT can leak
some of LDT pages - it allocates pages first,
but doesn't set context->size, thus destroy_context()
won't try to free these additional LDT pages.
Relevant for -ent kernel flavors only.
</div>
==== diff-cpt-vsyscall-x64-fix ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org><br/>
[PATCH] Fix CPT vsyscall part for x8664 case
</div>
==== diff-debug-busy-inodes-c-20070830 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH debug: additional debug for busy inodes after umount (part 2)
print also all mnt points for given super block on umount
</div>
==== diff-fairsched-preempt-20070921 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org>
<br/>
[PATCH] fairsched: fix warning on preempt kernels
rq->curr should be initialized to something to avoid
its dereference e.g. in try_to_wakeup() on first
process wakeup.
Actually it doesn't matter to what it is initialized.
Let's use init_task for initial rq->curr.
</div>
==== diff-ms-broken-cond-resched-lock-20070919 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] cond_resched_lock() doesn't work in 2.6.18
When CONFIG_PREEMPT=n, cond_resched_lock() and cond_resched_softirq()
don't work, since they check for preempt_count to be sane,
but this counter is not tracked w/o preemption and is always 0.
So the fix is:
* ignore preempt count when CONFIG_PREEMPT=n
* plus if we want to check preempt_count in CONFIG_PREEMPT=y case (just to be on the safe side), we need to account lock_kernel() effect on preempt_count correctly.
Bug #91012
</div>
==== diff-ms-fibrules-list-cleanup-20070918 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org><br/>
[PATCH] small cleanup for fib rules
This patch slightly cleanups FIB rules framework. rules_list as a pointer
on struct fib_rules_ops is useless. It is always assigned with a static
per/subsystem list in IPv4, IPv6 and DecNet.
Signed-off-by: Denis V. Lunev <den@openvz.org><br/>
Acked-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
</div>
==== diff-ms-fs-odirect-20070822 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org>
<br/>
[FS]: disable O_DIRECT by default inside VE
We still have to disable O_DIRECT by default inside VE due to
compatibility with old broken software (e.g. rpm)
Bug #91550.
</div>
==== diff-ms-fs-shrink-dcache-reverse-20070913 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] improve shrink_dcache_sb()
This patch makes shrink_dcache_sb consistent with dentry pruning policy.
On the first pass we iterate over dentry unused list and prepare some
dentries for removal.
However, since the existing code moves evicted dentries
to the beginning of the LRU it can happen that fresh dentries from
other superblocks will be inserted *before* our dentries.
This can result in significant slowdown of shrink_dcache_sb().
Moreover, for virtual filesystems like unionfs which can call dput()
during dentries kill existing code results in O(n2) complexity.
We observed 2 minutes shrink_dcache_sb() with only 35000 dentries.
To avoid this effects we propose to isolate sb dentries at the end
of LRU list.
Signed-off-by: Denis V. Lunev <den@openvz.org><br/>
Signed-off-by: Kirill Korotaev <dev@openvz.org><br/>
Signed-off-by: Andrey Mirkin <amirkin@openvz.org>
</div>
==== diff-ms-ipv6-anycast-refcnt-20070914 ====
<div class="change">
Patch from David S. Miller <davem@davemloft.net><br/>
[IPV6]: /proc/net/anycast6 unbalanced inet6_dev refcnt
Reading /proc/net/anycast6 when there is no anycast address
on an interface results in an ever-increasing inet6_dev reference
count, as well as a reference to the netdevice you can't get rid of.
Signed-off-by: David S. Miller <davem@davemloft.net>
Bug #75822
X-Git-Tag: v2.6.21-rc3~1492~5<br/>
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=aa6e4a96e7589948fe770744f7bb4f0f743dddaa aa6e4a96e7589948fe770744f7bb4f0f743dddaa]
</div>
==== diff-ms-ppc64-atmhe-init-20070912 ====
<div class="change">
Patch from Roland Dreier <roland@digitalvampire.org><br/>
[ATM] he: Fix __init/__devinit conflict
he_init_one() is declared __devinit, but calls lots of init functions
that are marked __init. However, if CONFIG_HOTPLUG is enabled,
__devinit functions go into normal .text, which leads to
<pre class="simple">
WARNING: drivers/atm/he.o - Section mismatch: reference to .init.text: from .text between 'he_start' (at offset 0x2130) and 'he_service_tbrq'
</pre>
Fix this by changing the __init functions to __devinit.
Signed-off-by: Roland Dreier <roland@digitalvampire.org><br/>
Signed-off-by: David S. Miller <davem@davemloft.net>
X-Git-Tag: v2.6.19-rc1~1232^2~10<br/>
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=5b7c714ec27584b18279b741b6043016f8adb9de 5b7c714ec27584b18279b741b6043016f8adb9de]
Found by kir@openvz.org while building ovzkernel-2.6.18-8.1.8.el5.028stab039.1 on ppc64
</div>
==== diff-ms-security-x8664-rax-check-20070919 ====
<div class="change">
Patch from Eugene Teo <eugeneteo@kernel.sg> <br/>
[PATCH] syscall invalid validation x86_64 (CVE-2007-4573)
This patch fixes a vulnerability discovered by Wojciech Purczynski. It
appears that the 64-bit values stored in the %rax register is not properly
validated. This may lead to an out-of-bounds system call table access
resulting in the ability to execute arbitrary code in the context of the
kernel on x86_64 platform.
{{CVE|2007-4573}}
Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
</pre>
</div>
==== diff-ms-sysrq-debug-fix-needless-help-20070924 ====
<div class="change">
Patch from Alexey Dobriyan <adobriyan@openvz.org> <br/>
[PATCH] Fix needless SysRq help message
Every time one does
<pre class="simple">
echo p >/proc/sysrq-trigger
</pre>
newline sneaks into kernel buffer, sysrq code doesn't find it in
handlers table, and spits help banner.
</div>
==== diff-sysrqkey-scancode-20061121 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org> <br/>
This patch lets you to change the SysRq key in Alt+SysRq+XXX combination
This patch lets you to change the SysRq key in Alt+SysRq+XXX combination
with any other key:
You can get scancodes of your keyboard with programs like showkey or
evtest.
The default Alt+SysRq combination still works after redefinition.
</div>
==== diff-ubc-netlink-exec-ub-20070912 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] BC: set correct ub context in netlink processing
* rtnl netlink socket is asynchronous and can be processed during rtnl_unlock in the other context.
* rtnl netlink socket is used to create kernel objects
* these objects are planned to be accounted at least to UB_KMEMSIZE
So, let's set correct UB context for packets processing.
</div>
==== diff-ve-fibrules-20070918 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] virtualize fib rules, add kmemsize accounting
* this patch virtualizes IPv6 routing rules
* fixes IPv4 routing rules implementation
* adds UBC accounting to kmemsize for fibrules
Bug #90085.
</div>
==== diff-ve-net-ioctl-sifflags-20070917 ====
<div class="change">
Patch from Vitaliy Gusev <vgusev@openvz.org> <br/>
[PATCH] net: allow SIOCSIFFLAGS in dev_ioctl()
This patch allows ioctl SIOCSIFFLAGS from VE on PF_INET6 socket.
In old VEs (with redhat-6.2) ifconfig calls ioctl() on IPv6 socket,
while tries to make venet UP inside VE. And fails.
Since this ioctl is prohibited in dev_ioctl(). Newer ifconfig's
call this ioctl() on IPv4 socket and thus end up with inet_ioctl().
Bug #91248
</div>
==== diff-ve-rm-unused-vars-20070914 ====
<div class="change">
Patch from Pavel Emelianov <xemul@openvz.org><br/>
[PATCH] clenup: remove unused vars from init_ve_system()
</div>
==== diff-ve-vzevent-20061120 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
Fix vzevent module. It is incompatible with kobject uevents in reallity.
Fix vzevent module. It is incompatible with kobject uevents in reallity.
Current code does *nothing*, since kobj is not fully configured.
Instead let's send messages via a separate netlink channel.
</div>
==== diff-vzdq-forced-off-20070817 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org> <br/>
[PATCH] VZDQ: add force quota off option
Add force quota off option:
Just return 0 instead of EBUSY in case of VZQUOTA_OFF_FORCED ioctl.
</div>
==== diff-vzdq-report-busy-dentries-20070816 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org> <br/>
[PATCH] VZDQ: report busy dentries on quota off
In case of vzquota off fail, find and pass to the userspace
information about busy dentries. vzquota must pass PAGE_SIZE
buffer, and kernel fill it with found filenames.
<pre class="simple">
V2:
- use free_page() instead of kfree()
- remove unnecessary \n after the last file name
V3:
- use generic __d_path()
- don't call copy_to_user() if both ubuf and buf == NULL
V4:
- remove VZ_DQ_OFF_FORCED declaration from header, it relates to another
patch
</pre>
Bug #86944.
</div>
==== diff-vzdq-report-busy-dentries-on-20070817 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org><br/>
[PATCH] VZDQ: report busy dentries on vzquota on
In case of vzquota ON fail, find and pass to the userspace
information about busy dentries.
vzquota must pass user buffer, and kernel fill it with found filenames.
</div>
==== diff-xen-x8664-vsyscall-fixes-20070822 ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org> <br/>
[PATCH] Xen specific changes to support vsyscall in CPT.
Tested on x86_64 and i386 on Xen and non-Xen kernels with
enabled/disabled vsyscall.
</div>
==== diff-fs-sysctl-lsyscalls-20070926 ====
<div class="change">
Patch from Dmitry Monakhov <dmonakhov@openvz.org> <br/>
[PATCH] sysctl: add lsyscalls sysctl
This patch introduce /proc/sys/fs/lsyscall_enable sysctl.
Sysctl instoduced mostly for testing purposes.
</div>
==== linux-2.6.18-drbd-8.0.5-8.0.6.patch ====
<div class="change">
Patch from Evgeniy (emkravts@sw.ru):<br/>
[PATCH 2.6.18] drbd update 8.0.5 - 8.0.6
</div>
==== diff-ve-fibrules-b-20070928 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org>
<br/>
This patch fixes allocation size for default IPv6 FIB rules.
This patch fixes allocation size for default IPv6 FIB rules.
These hunks were accidentally missed in the previous patch.
Bug #92085.
</div>
==== diff-ms-broken-cond-resched-lock-b-20070928 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org>
<br/>
[PATCH] fix for cond_resched() fix: remove wrong WARN_ON(1)
WARN_ON(1) is illegal, since when we return from cond_resched()->schedule() we
have preempt_count = PREEMPT_ACTIVE, and if we have still current->need_resched
flag set we can get to cond_resched() again from
schedule()->reacquire_kernel_lock()->cond_resched()
and thus this WARN_ON(1) gets triggered.
Bug #92140.
</div>
==== diff-ms-broken-cond-resched-lock-c-20070930 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
[PATCH] another cond_resched() fix
cond_resched() should check that it is not nexted
via preempt_count() & PREEMPT_ACTIVE flag.
Drop the whole super-logic from Den checking preempt count
at al.
Bug #92140.
</div>
</noinclude>
* Major x8664 security fix (CVE-2007-4573)
* Other security fixes
* Rebase to RHEL5 8.1.14 kernel
* areca and DRBD driver updates
* Fixes for NFS client in VE, CPT, UBC, VZDQ, IPv6, fairsched, 4GB split.
=== Config changes ===
Added:
* +<code>CONFIG_PREEMPT_VOLUNTARY=y</code>
* +<code>CONFIG_REISERFS_FS=m</code>
* +<code>CONFIG_REISERFS_PROC_INFO=y</code>
* +<code>CONFIG_REISERFS_FS_XATTR=y</code>
* +<code>CONFIG_REISERFS_FS_POSIX_ACL=y</code>
* +<code>CONFIG_JFS_FS=m</code>
* +<code>CONFIG_JFS_POSIX_ACL=y</code>
* +<code>CONFIG_XFS_FS=m</code>
* +<code>CONFIG_XFS_QUOTA=y</code>
* +<code>CONFIG_XFS_POSIX_ACL=y</code>
Removed:
* -<code>CONFIG_PREEMPT_NONE</code>
* -<code>CONFIG_DEBUG_HIGHMEM</code>
<includeonly>[[{{PAGENAME}}/changes#Patches|{{Long changelog message}}]]</includeonly><noinclude>
=== Patches ===
==== diff-i2o-iosched-fix-20070806 ====
<div class="change">
Patch from Alexey Kuznetsov (alexey@):
It is I2O device, which siffers of the same problem, which I found
with nbd.
The fact that this is troggered even with anticipatory scheduler
says that this scheduler is broken as well, only race window is more narrow.
<source lang="c">
if (ad->changed_batch && ad->nr_dispatched == 1) {
kblockd_schedule_work(&ad->antic_work);
ad->changed_batch = 0;
if (ad->batch_data_dir == REQ_SYNC)
ad->new_batch = 1;
}
</source>
I guess that it freezes when we hit this place with changed_batch==0.
</div>
==== diff-cpt-lock-fd-fix-20070822 ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org> <br/>
[PATCH] CPT: correct handling of lock fd error codes
Undump in CPT is performed in 2 stages (create env and init process; full
undump). These 2 stages are separated with help of pipe: when this pipe is
closed from vzctl we can proceed with second stage in CPT.
So, possible scenario is following:
1. We are waiting in CPT in pipe_read() when pipe will be closed.
2. someone is sending signal to our task which is waiting in pipe_read().
3. pipe_read() exits with -ERESTARTSYS, but we ignore this error and continue
with undump process, but vzctl do not perform all intermediate stages, so we
can't proceed with undump.
Bug #88618.
</div>
==== diff-debug-busy-inodes-b-20070828 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org>
Additional debug for busy inodes after umount:
print more dentry information
</div>
==== diff-ms-bond802.3ad-carrier-20070818 ====
<div class="change">
Patch from Jay Vosburgh <fubar@us.ibm.com><br/>
[PATCH] bonding: Fix 802.3ad no carrier on "no partner found" instance
Modify carrier state determination for 802.3ad mode to comply
with section 43.3.9 of IEEE 802.3, which requires that "Links that are
not successful candidates for aggregation (e.g., links that are attached
to other devices that cannot perform aggregation or links that have been
manually configured to be non-aggregatable) are enabled to operate as
individual IEEE 802.3 links."
Bug reported by Laurent Chavey <chavey@google.com>. This patch
is an updated version of his patch that changes the wording of
commentary and adds an update to the driver version.
<pre class="simple">
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Laurent Chavey <chavey@google.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
</pre>
GIT: 031ae4deb095a1f18a842740459c5ae184ec931c
{{bug|666}}
</div>
==== diff-ms-proc-enoent-if-task-is-dead-20070824 ====
<div class="change">
Patch from Pavel Emelianov <xemul@openvz.org> <br/>
[PATCH proc: return ENOENT instead of EACCESS when task is dead
When reading the symlink /proc/<pid>/exe or /proc/<pid>/fd/<any>
of a task, that has managed to die after opening the appropriate
dir, but before reading the symlink, kernel returns -EACCESS due
to strange code in proc_fd_access_allowed().
Unlike the ms/RHEL5 kernel, the SuSE kernel returns -ENOENT in this
case and it turned out, that some SuSE software (inetd) is aware
of it and cannot stand any deviations.
Make the kernel return -ENOENT when the task is dead to make VEs
based on SuSE templates work. Keep the return value in any other
case (-EACCESS).
Bug #82009.
</div>
==== diff-ms-security-signals-20070817 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org><br/>
[PATCH] Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)
Severity: minor
This fixes a vulnerability in the "parent process death signal"
implementation discoverd by Wojciech Purczynski of COSEINC PTE Ltd.
and iSEC Security Research.
http://marc.info/?l=bugtraq&m=118711306802632&w=2
<pre class="simple">
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
</pre>
X-Git-Tag: v2.6.22.4~1<br/>
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.22.y.git;a=commitdiff_plain;h=c27a3393808acab7243da7455c713fe763ea2627 c27a3393808acab7243da7455c713fe763ea2627]
</div>
==== diff-ms-sigqueue-race-20070828 ====
<div class="change">
Patch from Oleg Nesterov <oleg@tv-sign.ru><br/>
[PATCH] sigqueue_free: fix the race with collect_signal()
Spotted by taoyue <yue.tao@windriver.com> and Jeremy Katz <jeremy.katz@windriver.com>.
<pre class="simple">
collect_signal: sigqueue_free:
list_del_init(&first->list);
if (!list_empty(&q->list)) {
// not taken
}
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(first); __sigqueue_free(q);
</pre>
Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the
obviously bad implications.
In particular, this double free breaks the array_cache->avail logic, so the
same sigqueue could be "allocated" twice, and the bug can manifest itself via
the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue.
Hopefully this can explain these mysterious bug-reports, see
http://marc.info/?t=118766926500003<br/>
http://marc.info/?t=118466273000005
Alexey Dobriyan reports this patch makes the difference for the testcase, but
nobody has an access to the application which opened the problems originally.
Also, this patch removes tasklist lock/unlock, ->siglock is enough.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru><br/>
Cc: taoyue <yue.tao@windriver.com><br/>
Cc: Jeremy Katz <jeremy.katz@windriver.com><br/>
Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com><br/>
Cc: Alexey Dobriyan <adobriyan@sw.ru><br/>
Cc: Ingo Molnar <mingo@elte.hu><br/>
Cc: Thomas Gleixner <tglx@linutronix.de><br/>
Cc: Roland McGrath <roland@redhat.com><br/>
Cc: <stable@kernel.org><br/>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
</div>
==== diff-ubc-ioprio-exports-20070823 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
[PATCH] UBC: add CFQ ioprio exports for CONFIG_IOSCHED_CFQ=m case
<pre class="simple">
Add CFQ ioprio exports for CONFIG_IOSCHED_CFQ=m case
</pre>
{{bug|669}}
</div>
==== diff-ubc-tcp-wakeup-20070823 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] UBC: missed wakup on one ub refill path
The following scenario is possible:
* TCPSNDBUF rejected by ub_sock_get_wreserv
* sys_poll -> ub_sock_snd_queue_add
* uncharge -> sk->sk_write_space DOES NOT wakeup the waiting poll as the queue is too long
After this, no one will wakeup the process :(
And it will block till the poll timeout end.
The patch makes sure, that the generic code will send wakeup when appropriate.
Bug #89127
</div>
==== diff-ve-nfs-client-lookup-20070817 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
This patch fixes NFS client socket transport creation.
This patch fixes NFS client socket transport creation.
RPC client is cached in NFS client structure.
So, correct allocation/lookup for NFS client.
</div>
==== diff-ve-nfs-xdev-20070817 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org>
This patch allows VE to traverse mountpoints if exported NFS tree contains ones.
</div>
==== diff-ve-venet-rmmod-20070824 ====
<div class="change">
Patch from Vitaliy Gusev <vgusev@openvz.org> <br/>
[PATCH] VENET: allow rmmod even if VE0 venet is UP
This patch allows delete module even if venet ifterface in VE0 is up.
Note, we must shutdown all interfaces in others VEs before delete module still.
Bug #83537
</div>
==== linux-2.6.18-drbd-8.0.4-8.0.5.patch ====
<div class="change">
Patch from DRBD, prepared by Evgeniy Kravtsunov:<br/>
Update drbd from 8.0.4 to 8.0.5.
</div>
==== diff-ubc-unaligned-to-pb-20070829 ====
<div class="change">
Patch from Vitaliy Gusev <vgusev@openvz.org><br/>
[PATCH] BC: fix unaliagned access on ia64
struct page contains union of the fields:
<source lang="c">
union {
struct user_beancounter *page_ub;
struct page_beancounter *page_pb;
} bc;
</source>
and there are three cases for value 'bc':
1) pointer to user_beancounter<br/>
2) pointer to page_beancounter<br/>
3) IO marked pointer to page_beancounter
This patch corrects access to 3-rd case pointer.
Bug #86554.
</div>
==== diff-ve-net-lost-reset-env-20070831 ====
<div class="change">
Patch from Pavel Emelianov <xemul@openvz.org> <br/>
[PATCH] IPv6: lost exec env reset in number of places
On is in for() loop - we could got to next loop iteration and
make the original env lost.
The other two are in error paths.
</div>
==== diff-dlm-fix-user-unlocking-20070829 ====
<div class="change">
Bug #88675.
From Andrey Mirkin, backported from mainstream:
The following patches are ported from mainstream to fix deadlock in dlm
The problem was in this path:
<pre class="simple">
do_exit
put_files_struct
...
dlm_clear_proc_locks <<< Here we are taking mutex ls_clear_proc_locks
unlock_lock
do_unlock
grant_pending_locks
grant_lock_pending
dlm_user_add_ast <<< Here we are trying to take the same mutex
</pre>
Following patches changes lock/unlock mechanism and fixes this and other
deadlocks which are present in rhel5 kernel.
Tested on 2.6.18-rhel5-041.1 kernel.
<pre class="simple">
diff-tree a1bc86e6bddd34362ca08a3a4d898eb4b5c15215 (from 1d6e8131cf0064ef5ab5f3411a82b800afbfadee)
Author: David Teigland <teigland@redhat.com>
Date: Mon Jan 15 10:34:52 2007 -0600
[DLM] fix user unlocking
When a user process exits, we clear all the locks it holds. There is a
problem, though, with locks that the process had begun unlocking before it
exited. We couldn't find the lkb's that were in the process of being
unlocked remotely, to flag that they are DEAD. To solve this, we move
lkb's being unlocked onto a new list in the per-process structure that
tracks what locks the process is holding. We can then go through this
list to flag the necessary lkb's when clearing locks for a process when it
exits.
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
</pre>
</div>
==== diff-dlm-can-miss-clearing-resend-flag-20070829 ====
<div class="change">
Patch from Andrey (amirkin@) ported from mainstream:
[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b790c3b7c38aae28c497bb363a6fe72f7c96568f b790c3b7c38aae28c497bb363a6fe72f7c96568f]
<pre class="simple">
Author: David Teigland <teigland@redhat.com>
Date: Wed Jan 24 10:21:33 2007 -0600
[DLM] can miss clearing resend flag
A long, complicated sequence of events, beginning with the RESEND flag not
being cleared on an lkb, can result in an unlock never completing.
- lkb on waiters list for remote lookup
- the remote node is both the dir node and the master node, so
it optimizes the lookup into a request and sends a request
reply back
- the request reply is saved on the requestqueue to be processed
after recovery
- recovery runs dlm_recover_waiters_pre() which sets RESEND flag
so the lookup will be resent after recovery
- end of recovery: process_requestqueue takes saved request reply
which removes the lkb off the waitesr list, _without_ clearing
the RESEND flag
- end of recovery: dlm_recover_waiters_post() doesn't do anything
with the now completed lookup lkb (would usually clear RESEND)
- later, the node unmounts, unlocks this lkb that still has RESEND
flag set
- the lkb is on the waiters list again, now for unlock, when recovery
occurs, dlm_recover_waiters_pre() shows the lkb for unlock with RESEND
set, doesn't do anything since the master still exists
- end of recovery: dlm_recover_waiters_post() takes this lkb off
the waiters list because it has the RESEND flag set, then reports
an error because unlocks are never supposed to be handled in
recover_waiters_post().
- later, the unlock reply is received, doesn't find the lkb on
the waiters list because recover_waiters_post() has wrongly
removed it.
- the unlock operation has been lost, and we're left with a
stray granted lock
- unmount spins waiting for the unlock to complete
The visible evidence of this problem will be a node where gfs umount is
spinning, the dlm waiters list will be empty, and the dlm locks list will
show a granted lock.
The fix is simply to clear the RESEND flag when taking an lkb off the
waiters list.
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
</pre>
Bug #88675
</div>
==== diff-dlm-overlapping-cancel-and-unlock-20070829 ====
<div class="change">
Patch from Andrey (amirkin@) ported from mainstream:
[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef0c2bb05f40f9a0cd2deae63e199bfa62faa7fa ef0c2bb05f40f9a0cd2deae63e199bfa62faa7fa]
Author: David Teigland <teigland@redhat.com><br/>
Date: Wed Mar 28 09:56:46 2007 -0500
<pre class="simple">
[DLM] overlapping cancel and unlock
Full cancel and force-unlock support. In the past, cancel and
force-unlock wouldn't work if there was another operation in progress on
the lock. Now, both cancel and unlock-force can overlap an operation on
a lock, meaning there may be 2 or 3 operations in progress on a lock in
parallel. This support is important not only because cancel and
force-unlock are explicit operations that an app can use, but both are
used implicitly when a process exits while holding locks.
Summary of changes:
- add-to and remove-from waiters functions were rewritten to handle
situations with more than one remote operation outstanding on a lock
- validate_unlock_args detects when an overlapping cancel/unlock-force
can be sent and when it needs to be delayed until a request/lookup
reply is received
- processing request/lookup replies detects when cancel/unlock-force
occured during the op, and carries out the delayed cancel/unlock-force
- manipulation of the "waiters" (remote operation) state of a lock moved
under the standard rsb mutex that protects all the other lock state
- the two recovery routines related to locks on the waiters list changed
according to the way lkb's are now locked before accessing waiters state
- waiters recovery detects when lkb's being recovered have overlapping
cancel/unlock-force, and may not recover such locks
- revert_lock (cancel) returns a value to distinguish cases where it did
nothing vs cases where it actually did a cancel; the cancel completion
ast should only be done when cancel did something
- orphaned locks put on new list so they can be found later for purging
- cancel must be called on a lock when making it an orphan
- flag user locks (ENDOFLIFE) at the end of their useful life (to the
application) so we can return an error for any further
cancel/unlock-force
- we weren't setting COMP/BAST ast flags if one was already set, so we'd
lose either a completion or blocking ast
- clear an unread bast on a lock that's become unlocked
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
</pre>
Bug #88675
</div>
==== linux-2.6.18-arcmsr-1.20.0X.14.devel.patch ====
<div class="change">
Patch prepared by Kostja (khorenko@):
<br/>
Areca driver v1.20.0X.14.devel provided to Thomas Krenn AG by Areca people.
Areca driver v1.20.0X.14.devel provided to Thomas Krenn AG by Areca people.
Declared to fix the memory leak problem caused by Areca command line
utility (about 7 MB per execution of the CLI according to Thomas Krenn AG).
P.S. the issue with ARCMSR_MAX_XFER_SECTORS[_B] fixed.
Bug #87569.
</div>
==== diff-arch-4gb-ldt-leak-20070918 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org><br/>
[PATCH] fix possible page leak during LDT allocation
Fix possible page leak during LDT allocation:
alloc_ldt() doesn't free new pages on error path and
doesn't change context->size value.
Thus we can have more pages on destroy_context() than
we think we have according to our context->size.
Let's scan all 16 pages to make sure everything is freed.
</div>
==== diff-cpt-remove-local-var-20070911 ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org> <br/>
[PATCH] CPT: lock fd close correct error handling
Lock fd close correct error handling:
on undump local variable 'err' was used to store an error,
that is why this error was ignored and undump continues
in spite of the error.
</div>
==== diff-cpt-rst-ldt-leak-20070918 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
[PATCH] CPT: fix LDT pages leak with 4GB split
In case 4GB split kernel is used, CPT can leak
some of LDT pages - it allocates pages first,
but doesn't set context->size, thus destroy_context()
won't try to free these additional LDT pages.
Relevant for -ent kernel flavors only.
</div>
==== diff-cpt-vsyscall-x64-fix ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org><br/>
[PATCH] Fix CPT vsyscall part for x8664 case
</div>
==== diff-debug-busy-inodes-c-20070830 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH debug: additional debug for busy inodes after umount (part 2)
print also all mnt points for given super block on umount
</div>
==== diff-fairsched-preempt-20070921 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org>
<br/>
[PATCH] fairsched: fix warning on preempt kernels
rq->curr should be initialized to something to avoid
its dereference e.g. in try_to_wakeup() on first
process wakeup.
Actually it doesn't matter to what it is initialized.
Let's use init_task for initial rq->curr.
</div>
==== diff-ms-broken-cond-resched-lock-20070919 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] cond_resched_lock() doesn't work in 2.6.18
When CONFIG_PREEMPT=n, cond_resched_lock() and cond_resched_softirq()
don't work, since they check for preempt_count to be sane,
but this counter is not tracked w/o preemption and is always 0.
So the fix is:
* ignore preempt count when CONFIG_PREEMPT=n
* plus if we want to check preempt_count in CONFIG_PREEMPT=y case (just to be on the safe side), we need to account lock_kernel() effect on preempt_count correctly.
Bug #91012
</div>
==== diff-ms-fibrules-list-cleanup-20070918 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org><br/>
[PATCH] small cleanup for fib rules
This patch slightly cleanups FIB rules framework. rules_list as a pointer
on struct fib_rules_ops is useless. It is always assigned with a static
per/subsystem list in IPv4, IPv6 and DecNet.
Signed-off-by: Denis V. Lunev <den@openvz.org><br/>
Acked-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
</div>
==== diff-ms-fs-odirect-20070822 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org>
<br/>
[FS]: disable O_DIRECT by default inside VE
We still have to disable O_DIRECT by default inside VE due to
compatibility with old broken software (e.g. rpm)
Bug #91550.
</div>
==== diff-ms-fs-shrink-dcache-reverse-20070913 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] improve shrink_dcache_sb()
This patch makes shrink_dcache_sb consistent with dentry pruning policy.
On the first pass we iterate over dentry unused list and prepare some
dentries for removal.
However, since the existing code moves evicted dentries
to the beginning of the LRU it can happen that fresh dentries from
other superblocks will be inserted *before* our dentries.
This can result in significant slowdown of shrink_dcache_sb().
Moreover, for virtual filesystems like unionfs which can call dput()
during dentries kill existing code results in O(n2) complexity.
We observed 2 minutes shrink_dcache_sb() with only 35000 dentries.
To avoid this effects we propose to isolate sb dentries at the end
of LRU list.
Signed-off-by: Denis V. Lunev <den@openvz.org><br/>
Signed-off-by: Kirill Korotaev <dev@openvz.org><br/>
Signed-off-by: Andrey Mirkin <amirkin@openvz.org>
</div>
==== diff-ms-ipv6-anycast-refcnt-20070914 ====
<div class="change">
Patch from David S. Miller <davem@davemloft.net><br/>
[IPV6]: /proc/net/anycast6 unbalanced inet6_dev refcnt
Reading /proc/net/anycast6 when there is no anycast address
on an interface results in an ever-increasing inet6_dev reference
count, as well as a reference to the netdevice you can't get rid of.
Signed-off-by: David S. Miller <davem@davemloft.net>
Bug #75822
X-Git-Tag: v2.6.21-rc3~1492~5<br/>
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=aa6e4a96e7589948fe770744f7bb4f0f743dddaa aa6e4a96e7589948fe770744f7bb4f0f743dddaa]
</div>
==== diff-ms-ppc64-atmhe-init-20070912 ====
<div class="change">
Patch from Roland Dreier <roland@digitalvampire.org><br/>
[ATM] he: Fix __init/__devinit conflict
he_init_one() is declared __devinit, but calls lots of init functions
that are marked __init. However, if CONFIG_HOTPLUG is enabled,
__devinit functions go into normal .text, which leads to
<pre class="simple">
WARNING: drivers/atm/he.o - Section mismatch: reference to .init.text: from .text between 'he_start' (at offset 0x2130) and 'he_service_tbrq'
</pre>
Fix this by changing the __init functions to __devinit.
Signed-off-by: Roland Dreier <roland@digitalvampire.org><br/>
Signed-off-by: David S. Miller <davem@davemloft.net>
X-Git-Tag: v2.6.19-rc1~1232^2~10<br/>
X-Git-Url: [http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=5b7c714ec27584b18279b741b6043016f8adb9de 5b7c714ec27584b18279b741b6043016f8adb9de]
Found by kir@openvz.org while building ovzkernel-2.6.18-8.1.8.el5.028stab039.1 on ppc64
</div>
==== diff-ms-security-x8664-rax-check-20070919 ====
<div class="change">
Patch from Eugene Teo <eugeneteo@kernel.sg> <br/>
[PATCH] syscall invalid validation x86_64 (CVE-2007-4573)
This patch fixes a vulnerability discovered by Wojciech Purczynski. It
appears that the 64-bit values stored in the %rax register is not properly
validated. This may lead to an out-of-bounds system call table access
resulting in the ability to execute arbitrary code in the context of the
kernel on x86_64 platform.
{{CVE|2007-4573}}
Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
</pre>
</div>
==== diff-ms-sysrq-debug-fix-needless-help-20070924 ====
<div class="change">
Patch from Alexey Dobriyan <adobriyan@openvz.org> <br/>
[PATCH] Fix needless SysRq help message
Every time one does
<pre class="simple">
echo p >/proc/sysrq-trigger
</pre>
newline sneaks into kernel buffer, sysrq code doesn't find it in
handlers table, and spits help banner.
</div>
==== diff-sysrqkey-scancode-20061121 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org> <br/>
This patch lets you to change the SysRq key in Alt+SysRq+XXX combination
This patch lets you to change the SysRq key in Alt+SysRq+XXX combination
with any other key:
You can get scancodes of your keyboard with programs like showkey or
evtest.
The default Alt+SysRq combination still works after redefinition.
</div>
==== diff-ubc-netlink-exec-ub-20070912 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] BC: set correct ub context in netlink processing
* rtnl netlink socket is asynchronous and can be processed during rtnl_unlock in the other context.
* rtnl netlink socket is used to create kernel objects
* these objects are planned to be accounted at least to UB_KMEMSIZE
So, let's set correct UB context for packets processing.
</div>
==== diff-ve-fibrules-20070918 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org> <br/>
[PATCH] virtualize fib rules, add kmemsize accounting
* this patch virtualizes IPv6 routing rules
* fixes IPv4 routing rules implementation
* adds UBC accounting to kmemsize for fibrules
Bug #90085.
</div>
==== diff-ve-net-ioctl-sifflags-20070917 ====
<div class="change">
Patch from Vitaliy Gusev <vgusev@openvz.org> <br/>
[PATCH] net: allow SIOCSIFFLAGS in dev_ioctl()
This patch allows ioctl SIOCSIFFLAGS from VE on PF_INET6 socket.
In old VEs (with redhat-6.2) ifconfig calls ioctl() on IPv6 socket,
while tries to make venet UP inside VE. And fails.
Since this ioctl is prohibited in dev_ioctl(). Newer ifconfig's
call this ioctl() on IPv4 socket and thus end up with inet_ioctl().
Bug #91248
</div>
==== diff-ve-rm-unused-vars-20070914 ====
<div class="change">
Patch from Pavel Emelianov <xemul@openvz.org><br/>
[PATCH] clenup: remove unused vars from init_ve_system()
</div>
==== diff-ve-vzevent-20061120 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
Fix vzevent module. It is incompatible with kobject uevents in reallity.
Fix vzevent module. It is incompatible with kobject uevents in reallity.
Current code does *nothing*, since kobj is not fully configured.
Instead let's send messages via a separate netlink channel.
</div>
==== diff-vzdq-forced-off-20070817 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org> <br/>
[PATCH] VZDQ: add force quota off option
Add force quota off option:
Just return 0 instead of EBUSY in case of VZQUOTA_OFF_FORCED ioctl.
</div>
==== diff-vzdq-report-busy-dentries-20070816 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org> <br/>
[PATCH] VZDQ: report busy dentries on quota off
In case of vzquota off fail, find and pass to the userspace
information about busy dentries. vzquota must pass PAGE_SIZE
buffer, and kernel fill it with found filenames.
<pre class="simple">
V2:
- use free_page() instead of kfree()
- remove unnecessary \n after the last file name
V3:
- use generic __d_path()
- don't call copy_to_user() if both ubuf and buf == NULL
V4:
- remove VZ_DQ_OFF_FORCED declaration from header, it relates to another
patch
</pre>
Bug #86944.
</div>
==== diff-vzdq-report-busy-dentries-on-20070817 ====
<div class="change">
Patch from Alexandr Andreev <aandreev@openvz.org><br/>
[PATCH] VZDQ: report busy dentries on vzquota on
In case of vzquota ON fail, find and pass to the userspace
information about busy dentries.
vzquota must pass user buffer, and kernel fill it with found filenames.
</div>
==== diff-xen-x8664-vsyscall-fixes-20070822 ====
<div class="change">
Patch from Andrey Mirkin <major@openvz.org> <br/>
[PATCH] Xen specific changes to support vsyscall in CPT.
Tested on x86_64 and i386 on Xen and non-Xen kernels with
enabled/disabled vsyscall.
</div>
==== diff-fs-sysctl-lsyscalls-20070926 ====
<div class="change">
Patch from Dmitry Monakhov <dmonakhov@openvz.org> <br/>
[PATCH] sysctl: add lsyscalls sysctl
This patch introduce /proc/sys/fs/lsyscall_enable sysctl.
Sysctl instoduced mostly for testing purposes.
</div>
==== linux-2.6.18-drbd-8.0.5-8.0.6.patch ====
<div class="change">
Patch from Evgeniy (emkravts@sw.ru):<br/>
[PATCH 2.6.18] drbd update 8.0.5 - 8.0.6
</div>
==== diff-ve-fibrules-b-20070928 ====
<div class="change">
Patch from Denis Lunev <den@openvz.org>
<br/>
This patch fixes allocation size for default IPv6 FIB rules.
This patch fixes allocation size for default IPv6 FIB rules.
These hunks were accidentally missed in the previous patch.
Bug #92085.
</div>
==== diff-ms-broken-cond-resched-lock-b-20070928 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org>
<br/>
[PATCH] fix for cond_resched() fix: remove wrong WARN_ON(1)
WARN_ON(1) is illegal, since when we return from cond_resched()->schedule() we
have preempt_count = PREEMPT_ACTIVE, and if we have still current->need_resched
flag set we can get to cond_resched() again from
schedule()->reacquire_kernel_lock()->cond_resched()
and thus this WARN_ON(1) gets triggered.
Bug #92140.
</div>
==== diff-ms-broken-cond-resched-lock-c-20070930 ====
<div class="change">
Patch from Kirill Korotaev <dev@openvz.org> <br/>
[PATCH] another cond_resched() fix
cond_resched() should check that it is not nexted
via preempt_count() & PREEMPT_ACTIVE flag.
Drop the whole super-logic from Den checking preempt count
at al.
Bug #92140.
</div>
</noinclude>