Download/kernel/rhel5/028stab035.1/changes

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search

Contents

Changes

  • Rebase to RHEL5 8.1.4 kernel.
  • Mainstream security fixes.
  • Improvements, optimizations, fixes in most subsystems.
  • DRBD update to 8.0.3.
  • Xen/OpenVZ fixes to run RHEL5 in Dom0/U.
  • Fixes for SPARC and PPC.

Config changes

Added:

  • +CONFIG_LEGACY_PTYS=y
  • +CONFIG_LEGACY_PTY_COUNT=256
  • +CONFIG_GFS_FS=m
  • +CONFIG_PREEMPT_VOLUNTARY=y
  • +CONFIG_PREEMPT_BKL=y

Removed:

  • CONFIG_UBC_DEBUG_KMEM

Patches

diff-arch-4gb-ldt-irqs-20070515

Patch from Kirill Korotaev <dev@openvz.org>
4GB split LDT reload fix from RHEL4u5

diff-cpt-features-known-mask-20070514

Patch from Andrey Mirkin <major@openvz.org>
[CPT] 2.6.9 <-> 2.6.18 features mask compatibility issue 

Use VE_FEATURES_OLD mask for old (< 2.6.18 kernel) CPT images.

Bug #81468

diff-cpt-futex-eintr-20070510

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] too aggressive sys_futex() restart 

Checkpointing used to enforce restart of sys_futex even when
it returns -EINTR to workaround for sick return value of FUTEX_WAIT.
Of course, this is wrong (f.e. it means restart of timed FUTEX_WAIT
with original timeout :-(), but do not have much of choice if we do
not want to break everything.

At least one case can be relaxed. If we have signal pending,
when we restore we must not restart. This pending signal would
interrupt FUTEX_WAIT in any case. This fixes sem_wait()

diff-cpt-kill-external-processes-b-20070515

Patch from Andrey Mirkin <major@openvz.org> 

We have a problem with external processes.
If someone enters to VE forks and does some job w/o exec,
then the process is not considered as external (pids are virtual),
but some of the files (e.g. libs) can be from HN, i.e. external.

Temporary and quick fix for this bug:
On suspend kill processes which have mm->vps_dumpable == 0.

Bug #81722

diff-cpt-prevent-vm-changes-20070510

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] prevent changes of VM after VE was checkpointed 

It is possible that processes' VM is changed after VE is checkpointed
and killed. At the moment it will happen when a process set clear_parent_tid
or robust list pointers. It was not considered a problem, because
VM is about to be destroyed in any case.

But one case was missed: corresponging VM areas could be mapped
to a file. If it is not deleted, the change will reach file system
and migrate. Oops. F.e. shared locked futex will be unlocked after
migration. (glibc tst-robust8 test)

diff-cpt-suspend-cleanup-20070510

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] VE suspend cleanups 

The patch fixes one bug. Sometimes one process  sleeps
in an uninterruptible state waiting for some event depending
on another process, which could be suspended.

I know three such cases:

1. Process did vfork() and waits when child will exec()
2. Thread did exec() and waits when its siblings will die.
3. Thread makes coredump and waits when siblings stop.

We detected case #1 directly by looking at tsk->vfork_done.
In another places suspend timed out and failed, which is obviously
incorrect. It is possible to handle cases #2,3 like we did with vfork,
but it is not necessary. The patch suggests universal solution:
we split suspend to several shorter  rounds: the first round
tries to suspend for 200msec, if it fails, VE is unfreezed
and suspend is retried after some time. We repeat the attempts
with increasing timeout until VE is frozen or major timeout (10sec)
expires.

Besides that, the patch reorders suspend code, so that it becomes
more or less readable.

diff-fairsched-dyn-vcpu-timeslice-20070518

Patch from Alexandr Andreev <aandreev@openvz.org>
[SCHED] optimization: dynamic vcpu_timeslice 

vcpu_timeslice == -1 now has special meaning (and -1 is default value
now). In this case, actual vcpu_timeslice value will depend on number of
VCPU's ready to run:

assume N = ready_vcpus / nr_pcpus

for N <= 1, vcpu_timeslice will be 8
1 < N <= 2, vcpu_timeslice = 4
2 < N <= 3, vcpu_timeslice = 2
3 < N <= 4, vcpu_timeslice = 1
N > 4, vcpu_timeslice = 0

This patch lets significantly improve performance of 'context switch'
test from unixbench-4.1.0-wht-1, when several instances of this test is
running.

On a host with 16 CPU's:

# cd unixbench-4.1.0-wht-1
# echo 0 > /proc/sys/kernel/vcpu_timeslice
# ./Run context1 16
108.4
# echo -1 > /proc/sys/kernel/vcpu_timeslice
# ./Run context1 16
435.3

diff-fairsched-vcpuoff-comp-20070426

Patch from Alexandr Andreev <aandreev@openvz.org>
[SCHED] compilation fix in case CONFIG_SCHED_VCPU=n 

This patch fixes compilation of OVZ kernel with CONFIG_SCHED_VCPU=n

 Note: VE can't be started in any case due to fairsched syscall's returns
 ENOSYS, but I fixed fairsched and checked that VE can be started/stopped
  - it looks like it works )).

diff-ms-cfq-allow-merge-c-20070507

Patch from Vasily Tarasov <vtaras@openvz.org>
[PATCH] merging of async requests was abit incorrectly backported 

patch diff-ms-cfq-allow-merge-b-20070424 was ported a bit incorrectly.
It resulted in wrong async requests merging.

Bug #80857

diff-ms-dcache-fix-quadratic-shrink

Patch from Alexey Dobriyan <adobriyan@openvz.org> 

Backport of
    commit d52b908646b88cb1952ab8c9b2d4423908a23f11
    Author: Miklos Szeredi <mszeredi@suse.cz>
    Date:   Tue May 8 00:23:46 2007 -0700

    fix quadratic behavior of shrink_dcache_parent()

    The time shrink_dcache_parent() takes, grows quadratically with the depth
    of the tree under 'parent'.  This starts to get noticable at about 10,000.

    These kinds of depths don't occur normally, and filesystems which invoke
    shrink_dcache_parent() via d_invalidate() seem to have other depth
    dependent timings, so it's not even easy to expose this problem.

    However with FUSE it's easy to create a deep tree and d_invalidate()
    will also get called.  This can make a syscall hang for a very long
    time.

    This is the original discovery of the problem by Russ Cox:

      http://article.gmane.org/gmane.comp.file-systems.fuse.devel/3826

    The following patch fixes the quadratic behavior, by optionally allowing
    prune_dcache() to prune ancestors of a dentry in one go, instead of doing
    it one at a time.

    Common code in dput() and prune_one_dentry() is extracted into a new helper
    function d_kill().

    shrink_dcache_parent() as well as shrink_dcache_sb() are converted to use
    the ancestry-pruner option.  Only for shrink_dcache_memory() is this
    behavior not desirable, so it keeps using the old algorithm.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Al Viro <viro@zeniv.linux.org.uk>

    Cc: Maneesh Soni <maneesh@in.ibm.com>
    Acked-by: "Paul E. McKenney" <paulmck@us.ibm.com>
    Cc: Dipankar Sarma <dipankar@in.ibm.com>
    Cc: Neil Brown <neilb@suse.de>

    Cc: Trond Myklebust <trond.myklebust@fys.uio.no>

    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Additionally merged:
    commit 24c32d733dd44dbc5b9dcd0b8de58e16fdbeac7
    From: Andrew Morton <akpm@linux-foundation.org>
    Date: Tue, 8 May 2007 07:23:49 +0000 (-0700)
    Subject: mm: shrink parent dentries when shrinking slab
    X-Git-Tag: v2.6.22-rc1~799
    X-Git-Url:
    http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=24c32d733dd44dbc5b9dcd0b8de58e16fdbeac76

    mm: shrink parent dentries when shrinking slab

    Teach the dentry slab shrinker to aggressively shrink parent dentries when
    shrinking the dentry cache.

    This is done to attempt to improve the situation where the dentry slab cache
    gets a lot of internal fragmentation due to pages containing directory
    dentries.  It is expected that this change will cause some of those dentries
    to be reaped earlier, and with less scanning.

    Needs careful testing.

    Cc: Miklos Szeredi <mszeredi@suse.cz>

    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Typical numbers after mkdir("foo")/chdir("foo") done N times and
immediate "time vzctl stop"

Before:
	N=32768

	real    1m14.529s	1m16.602s	1m16.143s
	user    0m0.009s	0m0.014s	0m0.007s
	sys     1m4.569s	1m6.638s	1m7.187s
After:
	real    0m10.078s	0m10.080s	0m10.079s
	user    0m0.007s	0m0.012s	0m0.012s
	sys     0m0.055s	0m0.053s	0m0.054s

Less easy case for this patch is the following configuration

	*--*--*--* ...
	 \  \  \  \
	  *  *  *  *

Speedup for this case is less rosy but significant anyway:

	L	before		after

	4096	11.40s		9.75s
	8192	24.00s		16.80s
	65536	15m39.897s	5m29.738s

Bug #73640

diff-ms-futex-locking-bug-20070510

Patch from Ingo Molnar <mingo@elte.hu>
[PATCH] futex: PI state locking fix 

commit 21778867b1c8e0feb567addb6dc0a7e2ca6ecdec
Author: Ingo Molnar <mingo@elte.hu>
Date:   Fri Mar 16 13:38:31 2007 -0800

[PATCH] futex: PI state locking fix

Testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI
state needs to be locked before we access it.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>

Cc: Chuck Ebbert <cebbert@redhat.com>
Cc: <stable@kernel.org>

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff-ms-futex-oops-20070510

Patch from Alexey Kuznetsov <alexey@openvz.org>
[PATCH] PI futex oops (mainstream) 

Serialization in PI futexes is severely broken, lots of bugs, lots.
But only one is known which crashes kernel.

It is possible that new pi state isadded to pi_state_list
after the task did exit cleanup already. So that, when task
struct is released pi_state list remains in corrupted state.

Locally exploitable.

diff-ms-nfs-rm-warn-20070515

Patch from Neil Brown <neilb@suse.de>
[NFS] Remove warning: VFS is out of sync with lock manager 

But keep it as a dprintk

The message can be generated in a quite normal situation:
 If a 'lock' request is interrupted, then the lock client needs to
  record that the server has the lock, incase it does.
 When we come the unlock, the server might say it doesn't, even
  though we think it does (or might) and this generates the message.

Signed-off-by: Neil Brown <neilb@suse.de>

Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=46bae1a9a767f3ae8e636d96f9b95703df34b398

diff-ms-slab-numa-bind-20070514

Patch from Alexandr Andreev <aandreev@openvz.org>
[SLAB] cache_reap() function must be binded, or take into account vcpus 

it must pass actual (up-to-dated) numa node id to drain_cache() aftre cond-resched.

Bug #81234

diff-sysrq-debug-b-20070511

Patch from Alexandr Andreev <aandreev@openvz.org>
[SYSRQ] show correct sysrq help message. 

Fix sysrq-h help message which was broken by SysRq-debugger patch.

Bug #81612

diff-ubc-cleanup-20070517

Patch from Denis Lunev <den@openvz.org>
[BC] cleanup: remove unused functions 

Cleanup: remove a bit of unused code

diff-ubc-dentry-acentry-20070510

Patch from Alexandr Andreev <aandreev@openvz.org>
[BC] dcache: new style of array_cache entries access 

cosmetics: new style of array_cache entries access

diff-ubc-dentry-free_alien-20070510

Patch from Alexandr Andreev <aandreev@openvz.org>
[BC] dcache: drain alien caches on nodes on dcache acct on 

drain alien caches on nodes on dcache walking through
dentry slabs lists when turning dcache accounting on/off

Bug #81116

diff-ubc-dentry-free_block-20070510

Patch from Alexandr Andreev <aandreev@openvz.org>
[BC] dcache: pass correct node number to kmem_cache_free_block() 

Fix warning in slab_put_obj() in debug kernels due to incorrect
node number passed to kmem_cache_free_block().

Bug #81116

diff-ubc-move-might-sleep-20070517

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[PATCH] dcache: move might_sleep() from under preempt_disable() 

dput() had might_sleep() check in the very beginning.
After renaming to dput_recursive() and adding preempt_disable() call
this check ended up in region with disabled preemption, so with
CONFIG_DEBUG_SPINLOCK_SLEEP=y and preemption on dmesg gets heavily
spammed.

So, do might_sleep() check earlier.

diff-ubc-proc-rework-b-20070515

Patch from Pavel Emelianov <xemul@openvz.org>
[BC] rework /proc/bc code 

Proc files creation suffered from two disadvantages:
1. It was racy in respect to bc remove/create
2. It couldn't correctly show hierarchical beancounters

Rework showing BC info by overriding readdir and lookup
methods for inodes under /proc/bc. The entry layout itself
is kept unchanged.

Plus create new entry names /proc/bc/<id>/debug to show
BC's id, parent credentials and some in-kernel memory
pointers purely for debugging.

Signed-off-by: Pavel Emelianov <xemul@sw.ru>

diff-ubc-top-beancounter-20070515

Patch from Pavel Emelianov <xemul@openvz.org>
[BC] cleanup: introcude top_beancounter helper 

Many resources are accounted to top beancounter only.
Introduce a helper to make code look nicer.

When saving the mapped page's ub need to save top beancounter
as it is done for non-mapped write.

Bug #81224 

Signed-off-by: Pavel Emelianov <xemul@sw.ru>
Signed-off-by: Kirill Korotaev <dev@sw.ru>

diff-ve-cap-bset-20070504

Patch from Vasily Tarasov <vtaras@openvz.org>
[PATCH] sysctl: add VE capability boundary set sysctl 

The user wishes to have virtualized kernel.cap-bound sysctl in order to
use lcap tool to observe capabilities allowed in VE. We have cap_default
field on ve_struct, that can be modified to be used as virtualized
cap_bset. This patch:
- renames cap_default -> ve_cap_bset
- virtualizes cap_bset
- introduces new proc and strategy routines to handle appropriate sysctl

OpenVZ Bug #524

diff-ve-init-signals-20070514

Patch from Denis Lunev <den@openvz.org>
[VE] VE init signal delivery reworked to be similar to host 

Prevent VE init from receiving unexpected signals sent from VE
including *fatal* ones. Signals sent from VE0 are still allowed,
e.g. for fast VE stop.
Fix for sys_reboot called from VE to force VE death
(SIGKILL is sent in the context of VE).

OpenVZ Bug #533

diff-ve-net-bridge-via-phys-dev2-20070514

Patch from Dmitry Mishin <dim@openvz.org>
[BRIDGE] bridge deliver to original eth0 device 

- now packets are input to the local system as they are coming from phys
  device only;
- fixed bunch of bugs with VE <-> HN communications.

diff-ve-nf-ipt6-aliasing-20070515

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[VE] unalias IPv6 iptables bit mask from IPv4 

VE_IP_MANGLE flag is used as mask for both IPv4 and IPv6 modules which
is no-no, because ip6table_mangle can be loaded after VE start.

Split VE_IP_IPTABLES into VE_IP_IPTABLES and VE_IP_IPTABLES6.
Same for VE_IP_FILTER and VE_IP_MANGLE.
Choose numbers to not contradict with vzctl header.

Temporarily mirror VE_IP_IPTABLES into IPv6 mask.
When vzctl will start doing right thing, this mirroring can be dropped.

OpenVZ Bug #561

diff-ve-nfs-abortset-20070504

Patch from Denis Lunev <den@openvz.org>
[NFS] fix NFS auto-umount timeout sysctl 

This patch:
- changes the timeout units from jiffies to seconds
- fixes assignment from userspace (was impossible, since UINT_MAX was treated as negative)

diff-ve-nfs-hostcache-20070510

Patch from Denis Lunev <den@openvz.org>
[NFS] virtualize NLM hosts cache 

This patch virtualizes NLM hosts cache

Bug #74374

diff-ve-nfs-stop-20070502

Patch from Denis Lunev <den@openvz.org>
[NFS] shutdown NFS properly if hanged 

This patch properly shutdown NFS if it is stalled.

diff-ve-nfs-stop-b-20070502

Patch from Kirill Korotaev <dev@openvz.org>
[NFS] Compilation fix for diff-ve-nfs-stop-b-20070502 when built as module 

diff-ve-nfs-stop-20070502 requires some symbols to be exported.

Signed-Off-By: Kirill Korotaev <dev@sw.ru>

diff-ve-pid-nr-fix-20070503

Patch from Pavel Emelianov <xemul@openvz.org>
When setting explicit vpid into ve's pidmap we need to 


When setting explicit vpid into ve's pidmap we need to
dec nr_free counter by one.

This does not fix any BUG, it just make pidmap information
consistent and hels to work faster when pidmap is full.

diff-ve-proc-hash-pid-dentries-20070516

Patch from Pavel Emelianov <xemul@openvz.org>
[PATCH] proc: don't hash task dentries in VE0 

When task dies the proc dentries, that may be hashed are
shrunk with shrink_dcache_parent(). The problem is that
this routine doesn't guarantee that all the entries will
be flushed and thus pid may still have reference from the
appropriate inode.

When we have such dentries in VE0 holding pids from ve
this leads to pid leakage and inability to release the
beancounter after ve stop.

So don't hash such dentries - remove them immediately.

Bug #80025 

Signed-off-by: Pavel Emelianov <xemul@sw.ru>

diff-ve-showmem-locking-20070414

Patch from Denis Lunev <den@openvz.org>
[PATCH] vmalloc info during OOM locking 

vmlist_lock can't be held under any spin_lock which is help with IRQ.
This assumption is always broken for __alloc_pages.

Modified by Kirill: drop vprintstat() from show_mem() at all

Bug #81199

diff-vzdq-ppc32-comp-20070518

Patch from Vasily Tarasov <vtaras@openvz.org>
[PATCH] vzdquota: compilation fix for ppc32 

While compiling on ppc32 the following error appears:

  Building modules, stage 2.
  MODPOST
WARNING: "__cmpdi2" [fs/vzdquota.ko] undefined!
make[2]: *** [__modpost] Error 1

The problem is that switch((long_long_var)) is not
a primitive for ppc32 gcc: libgcc.a is needed,
which is out of the kernel.

The problem was noticed by mbaranzak user at forum
and he found the reason of it.

diff-vzdq-putsuper-20070518

Patch from Denis Lunev <den@openvz.org>
[VZDQ] sb->put_super can be NULL in valid cases 

put_super() superblock operation was not checked for NULL in vzquota
leading to NULL dereference.

OpenVZ Bug #541
Bug #81936

diff-i2o-procread-20070509

Patch from Vasiliy (vvs@):
Fixes oops on read from some i2o proc files. 

Fixes oops on read from some i2o proc files.
Minor issue because i2o_proc module is not used currently.

diff-arch-4gb-xen-20070523

Patch from Evgeny Kravtsunov <emkravts@openvz.org>
[4GB-SPLIT] Fixes required for Xen kernel compilation

diff-cpt-mm-deadlock-20070523

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] Fix possible deadlock in checkpointing of mm 

Learned it wrong once and did not relearn. anon_vma lock
cannot be taken under page table lock. And it is taken and
should be taken in reversed order, cpt_mm even has a special
hack due to wrong understanding: look at chunk converting ugly
spin_trylock to spin_lock.

Difference of previous version: in one case (does not happen normally,
but yet), page table lock could remain locked.

Bug #82785

diff-cpt-wait-fix-20070518

Patch from Andrey Mirkin <major@openvz.org>
While checkpointing due to memory shortage CPT processes 

While checkpointing due to memory shortage CPT processes
can be killed and tmpfs will not be saved.

During restore we will see such errors:

CPT ERR: e0000002ef9c5000,111 :-2 mounting /dev/pts devpts 40000000
CPT ERR: e0000002ef9c5000,111 :rst_namespace: -2

Bug #79854 

This happens as /dev is tmpfs now and its content was not saved during
checkpointing.

We need to check exit status of tar and iptables-save to be sure that they
exited normally.

Changes from v1:
- return -EINVAL in case of error

diff-cpt-xen-ldt-20070523

Patch from Evgeny Kravtsunov <emkravts@openvz.org>
[XEN] Fix LDT handling - There is one chunk LDT data only

diff-ms-cfq-rm-redundant-find-next-req-20070509

Patch from Vasily Tarasov <vtaras@openvz.org>
[PATCH] cfq: remove redundant cfq_find_next_crq() function call 

mainstrem fix. cfq_find_next_crq() will be called later.
This fix is incorporated in
http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=21183b07ee4be405362af8454f3647781c77df1b

diff-ms-fuse-bug-control-fs-20070521

Patch from mainstream, prepared by Dmitry Monakhov <dmonakhov@openvz.org>
[PATCH 5/6] fuse: fix bug in control filesystem mount 

The BUG in fuse_ctl_add_dentry() could be triggered if the control
filesystem was unmounted and mounted again while one or more fuse
filesystems were present.

The fix is to reset the dentry counter in fuse_ctl_kill_sb().

Bug reported by Florent Mertens.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff-ms-fuse-dentry-parent-20070521

Patch from mainstream, prepared by Dmitry Monakhov <dmonakhov@openvz.org>
[PATCH 3/6] fuse: fix dereferencing dentry parent 

There's no locking for ->d_revalidate, so fuse_dentry_revalidate() should use
dget_parent() instead of simply dereferencing ->d_parent.

Due to topology changes in the directory tree the parent could become negative
or be destroyed while being used.  There hasn't been any reports about this
yet.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff-ms-fuse-mknod-of-regular-file-20070521

Patch from mainstream, prepared by Dmitry Monakhov <dmonakhov@openvz.org>
[PATCH] fuse: fix mknod of regular file 

The wrong lookup flag was tested in ->create() causing havoc (error or
Oops) when a regular file was created with mknod() in a fuse
filesystem.

Thanks to J. Cameijo Cerdeira for the report.

Kernels 2.6.18 onward are affected.  Please apply to -stable as well.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

diff-ms-fuse-nlookup-20070521

Patch from mainstream, prepared by Dmitry Monakhov <dmonakhov@openvz.org>
[PATCH 1/6] fuse: locking fix for nlookup 

[PATCH 1/6] fuse: locking fix for nlookup
An inode could be returned by independent parallel lookups, in this case an
update of the lookup counter could be lost resulting in a memory leak in
userspace.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff-ms-fuse-oops-in-lookup-20070521

Patch from mainstream, prepared by Dmitry Monakhov <dmonakhov@openvz.org>
[PATCH 4/6] fuse: fix Oops in lookup 

Fix bug in certain error paths of lookup routines.  The request object was
reused for sending FORGET, which is illegal.  This bug could cause an Oops
in 2.6.18.  In earlier versions it might silently corrupt memory, but this
is very unlikely.

These error paths are never triggered by libfuse, so this wasn't noticed
even with the 2.6.18 kernel, only with a filesystem using the raw kernel
interface.

Thanks to Russ Cox for the bug report and test filesystem.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@kernel.org>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff-ms-fuse-spurious-bug-20070521

Patch from mainstream, prepared by Dmitry Monakhov <dmonakhov@openvz.org>
[PATCH 2/6] fuse: fix spurious BUG 

Fix a spurious BUG in an unlikely race, where at least three parallel lookups
return the same inode, but with different file type.  This has not yet been
observed in real life.

Allowing unlimited retries could delay fuse_iget() indefinitely, but this is
really for the broken userspace filesystem to worry about.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff-ms-fuse-validate-rootmode-20070521

Patch from mainstream, prepared by Dmitry Monakhov <dmonakhov@openvz.org>
[PATCH 6/6] [PATCH] fuse: validate rootmode mount option 

If rootmode isn't valid, we hit the BUG() in fuse_init_inode.  Now
EINVAL is returned.

Signed-off-by: Timo Savola <tsavola@movial.fi>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff-ms-powerpc-compilation-20070523

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] Fix powerpc compilation which was broken in 2.6.18.8 

Christian Kaiser reported broken powerpc compilation due to 2.6.18.8 fix:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.18.y.git;a=commitdiff;h=f102c840f7f72492a83c93fa65396fe0edcf1df6

In file included from drivers/media/video/pwc/pwc-uncompress.c:29:
include/asm/current.h: In function get_current:
include/asm/current.h:23: warning: implicit declaration of function offsetof
include/asm/current.h:23: error: expected expression before struct
make[4]: *** [drivers/media/video/pwc/pwc-uncompress.o] Error 1
make[3]: *** [drivers/media/video/pwc] Error 2
make[2]: *** [drivers/media/video] Error 2
make[1]: *** [drivers/media] Error 2
make: *** [drivers] Error 2

diff-ms-sparc64-compilation-20070523

Patch from Kirill Korotaev <dev@openvz.org>
Fix SBUS compilation on SPARC64. 

asm/unistd.h should be included for _syscallX() define usage.

diff-ubc-dentry-free_alien-b-20070521

Patch from Alexandr Andreev <aandreev@openvz.org>
[BC] dentry_cache: drain alien caches only when CONFIG_NUMA is set 

Fix oops introduced by previous patch diff-ubc-dentry-free_alien-20070510:
We should deal with NUMA only when CONFIG_NUMA is set.

Bug #82721

diff-ubc-ioprio-on-dispatch-check-20070523

Patch from Vasily Tarasov <vtaras@openvz.org>
[BC] ioprio: account for requests in driver 

Previously we didn't take into account beancounter's requests that are
already in driver. Now we consider beancounter as empty
(no requests in it) only if there are no requests in CFQ _and_ in driver.

This patch improves fairness dramatically and fixes bug #81508

Bug #81508

diff-ubc-ioprio-range-prio-20070623

Patch from Vasily Tarasov <vtaras@openvz.org>
[BC] ioprio: range of ioprios were checked incorrectly 

Fix ioprio range check: ioprio range is 0..7

diff-ubc-ioprio-slice-scaling-20070623

Patch from Vasily Tarasov <vtaras@openvz.org>
[BC] ioprio: BC slice scaling fix 

Now slice is CFQ BC timeslice is scaled from X to 2*X ms.

diff-ve-net-veth-addr-macro-20070514

Patch from Evgeny Kravtsunov <emkravts@openvz.org>
[VE] rename local macro ADDR() to avoid conflict with Xen 

Fix redefinition of ADDR in veth.c.
macro with name ADDR is also used by Xen in include/asm/mach-xen/asm/synch_bitops.h.

diff-ve-nfs-abortcorrupt-20070523

Patch from Denis Lunev <den@openvz.org>
Unfortunately, counter on RPC client counts only clones, but not real 

Unfortunately, counter on RPC client counts only clones, but not real
ussage. cl_dead flag leads to client destruction in rpc_release_client
while it is really in use. So, we have to introduce a new flag with the
meaning similar to cl_dead in all places except rpc_release_client.
True recounting is too expensive.

Based on idea from Dmitry Monakhov.

Bug #82764
Bug #82875

diff-ve-nfs-tcpabort-20070522

Patch from Denis Lunev <den@openvz.org>
Add NFS timeout handle for TCP transport

diff-ve-xen-blktapmain-20070514

Patch from Evgeny Kravtsunov <emkravts@openvz.org>
Fixes compilation error in Xen driver

diff-vzdq-aquota-group-len-20070521

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[VZDQ] Trivial fix for vzaquota.group lookup 

"vzaquota.group" was memcmp'd for only 11 symbols,
allowing names like "vzaquota.grouX" to be looked up successfully.

diff-vzdq-atomic-in-buildmntlist-20070521

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[VZDQ] Fix GFP_KERNEL allocation under spin lock in vzdq_aquot_buildmntlist 

Switch allocation from GFP_KERNEL to GFP_ATOMIC under vfsmount_lock
in vzdq_aquot_buildmntlist()

diff-arch-4gb-xen-cleanup-20070528

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] Cleanup 4GB split/Xen modification regarding init_tss

diff-cpt-aux-task-list-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] additional protected VE task list 

Nobody want this. But another ideas are absent until now,
which could mean it is just impossible to do painlessly.

Each task is enlisted on one more list (vetask_auxlist),
which is protected with tasklist_lock and it is its only difference
of normal ve task list, which is accessed by RCU rules.

diff-cpt-check-iptables-modules-20070604

Patch from Andrey Mirkin <major@openvz.org>
[PATCH] CPT: check if ip_talbes are enabled before dumping them 

iptables-save returns error if module ip_tables is not loaded.
So, we just do not need to dump iptables at all if this module is not loaded in VE.
Don't try to dump iptables if they are not enabled in VE.

diff-cpt-compilation-warning-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] fix compilation warning due to cast u64 -> pointer

diff-cpt-compile-warning-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] one more compiler warning

diff-cpt-deleted-ref-20070502

Patch from Andrey Mirkin <major@openvz.org>
[PATCH] CPT: checkpoint inodes with deleted reference 

Consider the following scenario:
1. Create file (file1) and hard link to it (file2)
2. Open file2
3. Unlink file2

After that during checkpointing we will have the following err:
Can not dump VE: Device or resource busy deleted reference to existing inode,
  checkpointing is impossible

The inode in question is not deleted, but it is not foundable
from inside checkpointed process group and not easy foundable on the disk :/

So we are trying to find another dentry with the same inode in 2 common places:
1. In inode->i_dentry alias list
2. In dir in which deleted dentry itself is located

Bug #72540

diff-cpt-ia64-nat-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT][IA64] save/restore NaT values 

This patch closes two remaining holes in IA64 cpt implementation,
both are of no immediate practical value, but neraly impossible to fix
after we freeze layout of cpt image structs.

1. Migration between hosts with different layout of struct thread_info,
   which is possible, if some new bits are added to thread_info in newer
   kernels.
2. NaT bits are acurately saved and restored. This is required only
   when some application uses control speculative loads, current compilers
   are not able to do this, but this can change.

diff-cpt-ia64-unaligned-suppress-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT][IA64] some prctl flags are forgotten 

Some apps do lots of unaligned accesses, know about this
and use prctl(). We did not save/restore those flags and
got flood of warnings after checkpointing.

diff-cpt-improve-align-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] cosmetic fix to match 2.6.9 text 

In 2.6.9 it was a critical bug, image would be corrupted
because of broken alignment if we did not make this.
In 2.6.18 it is just nice.

diff-cpt-inotify-core-b-20070529

Patch from Vasily Tarasov <vtaras@openvz.org>
Rework inotify changes, so that old API is still available 

Rework inotify changes, so that old API is still available
for 3rd party code like aufs.

diff-cpt-namespace-deadlock-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] namespace semaphore possible deadlock 


Old bug. To my shame I knew about this, but ignored.

 Deadlock is possible in two cases:
 1. tar is not a tar, but something maliciously doing mount/unmount
 2. tar is a good tar, but it takes namespace semaphore for read
 f.e. to read /proc/mounts. If someone in system does mount/unmount
 and blocked taking write semaphore, the second read semaphore deadlocks.

The fix is to drop namespace semaphore. We make mntget() on current
mnt, so that it will not disappear from under us. It still can be
unmounted with MNT_DETACH, in this case we cannot proceed with
scanning mnt list and we must not: unmounting something inside
VE while checkpointing is an obvious good reason to fail.

diff-cpt-pids-leak-20070525

Patch from Pavel Emelianov <xemul@openvz.org>
[PATCH] CPT: fix potential pid leak 

When restoring the VE restore_one_signal_struct() can
occasionally leak some pids.

Bug #82895

diff-cpt-restore-deleted-files-20070502

Patch from Andrey Mirkin <major@openvz.org>
[PATCH] CPT: restore deleted files (hardlink case) 

The bug was here all the time, but it was never triggered as we never entered
the following path on checkpointing:

if (!IS_ROOT(d) && d_unhashed(d)) {
        struct file *parent;
        parent = iobj->o_parent;
        if (!parent ||
                        (!IS_ROOT(parent->f_dentry) &&

d_unhashed(parent->f_dentry))) {
                /* Inode is not deleted, but it does not
                 * have references from inside checkpointed
                 * process group. We have options:
                 * A. Fail, abort checkpointing
                 * B. Proceed. File will be cloned.
                 * A is correct, B is more complicated */
                /* Just as a hint where to create deleted file */
                if (ino->i_nlink != 0) {
                        eprintk_ctx("deleted reference to existing inode,
checkpointing is impossible\n");
                        return -EBUSY;
                }
        } else {
<<< HERE
                /* Refer to _another_ file name. */
                err = cpt_dump_filename(parent, 0, ctx);
                if (err)
                        return err;
                if (S_ISREG(ino->i_mode) || S_ISDIR(ino->i_mode))
                        dump_it = 0;
        }
}

So, in image file for deleted file we always had its content and never
a reference to another file.

The fix is straightforward: check the type of the object in the image and
restore file content if needed.

diff-cpt-restore-lastpid-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] restore last pid 

Sigh. I hoped it is not necessary. It is. bash goes insane
when its children get not monotonic pids.

The place where we store saved last pid is unusual.
Violating tradition I extend one of cpt image structs.
This should be ok: migration to older kernels will be prohibited,
migration from old to new ones is OK.

diff-cpt-restore-packet-socket-20070606

Patch from Alexey Kuznetsov <alexey@openvz.org>
[CPT] restore packet socket 

Binding of packet socket was skipped.

One tricky bit: getsockname returns "real" sockaddr length
and bind() does not accept real name, it wants sizeof(struct sockaddr_ll).

Missing bits:
- multicast list, incuding promisc status
- statistics is not restored

Enough for beginning, the rest requires surgery in core.

diff-cpt-rst-file-error-msg-20070601

Patch from Andrey Mirkin <major@openvz.org>
[PATCH] CPT: print file name when fail to open it 

Print file name if we failed to open it.
This information will be usefull for resolving problems.

Bug #83180

diff-cpt-ubc-adjust-on-restore-c-20070601

Patch from Andrey Mirkin <major@openvz.org>
[PATCH] CPT: adjust UBC limits before restoring processes 

Move UBC limit adjustments in more appropriate place,
where it is actually needed.

diff-cpt-wait-fix-c-20070601

Patch from Andrey Mirkin <major@openvz.org>
[PATCH] CPT: fix kernel_thread error code checks 

Some versions of tar return non-zero error code if it was not possible to
write warning message to stderr. So, we need to open /dev/null for it.
But during restore we will face another problem - /dev is stored on tmpfs, so
we are not able to open /dev/null and we need to create it.

Also there is another bug which come to CPT code from mainstream kernel_thread
helper. If our function returns an error (e.g. exec failed) it doesn't place
correct exit code to edi register before calling do_exit.

Bug #83183

diff-fairsched-boot-cpu-20070530

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] sched: boot CPU can have non-zero ID (sparc) 

I was blindly assuming that boot processor ID is always 0,
which was not true on SUN4U machine where boot CPU has ID 1
and 2nd CPU has ID 0. Strange, but it is.
So replace 0 with real processor id in the code.

diff-fairsched-iowait-fix-20070624

Patch from Vasily Tarasov <vtaras@openvz.org>
[PATCH] Fix iowait stats in VE0 

2.6.18 OVZ kernels don't account iowait time,
this value is always displayed as zero:

$ cat /proc/stat  | grep cpu
cpu  1700 5 1818 11790110 0 60 204 0
cpu0 893 4 1020 5894818 0 56 174 0
cpu1 807 1 797 5895291 0 4 29 0

This happens since calculations usually happen in idle context.
Actually there is no good definition of iowait for global VE0 context.
And the whole iowait concept is arguable, but still, let's try to account
as good as possible.

OpenVZ Bug #588

diff-fairsched-ppc-syscalls-fix3-20070525

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] ppc: fix screwed OVZ syscall numbers 

Fix enumeration of OVZ syscall numbers on powerpc

Thanks to Christian Kaiser for noticing this.

diff-fairsched-preempt-20070529

Patch from Vasily Tarasov <vtaras@openvz.org>
[PATCH] Fix debug messages when CONFIG_DEBUG_PREEMPT is used 

If CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT are turned on,
OpenVZ kernels produce a lot of similar messages:

BUG: using smp_processor_id() in preemptible [00000001] code:
<process>/<pid>
caller is io_schedule+0x22/0x53
Call Trace: ...

Two reasons of these messages:
1) we call smp_processor_id() from io_schedule/io_schedule_timeout
   without preemption disabled. minor, raw_smp_processor_id() should be used.
2) task_struct->cpus_allowed has mask of vcpus instead of pcpus.
   Therefore debug_smp_processor_id() function fails to check that the
   process can run only on one current cpu.

The patch fixes both issues.

OpenVZ Bug #577

diff-fairsched-rename-vcpu-info-20070517

Patch from Evgeny Kravtsunov <emkravts@openvz.org>
[PATCH] rename vcpu_info to vcpu_struct due to conflict with Xen 

Rename vcpu_info to vcpu_struct due to conflict with Xen
which uses the same name for its data structure (sigh... globally...)

Thanks to seyko2 for testing OVZ-Xen kernel.

diff-fairsched-tickduration-20070528

Patch from Alexandr Andreev <aandreev@openvz.org>
[PATCH] sched: fix up fairsched tick duration according to VCPU timeslice 

With latest 'vcpu dynamic timeslice' patch we broke
fairsched scheduler logic a bit, which assumed,
that fairsched_schedule() must be called on each timer tick.

New bigger fairsched timeslice was introduced:
this value must be always >= vcpu timeslice

Bug #82969

diff-fairsched-x8664-show-regs-20070528

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] fairsched: fix VCPU info in show regs on x86-64

diff-ms-entropy-fix-a-20070530

Patch from Matt Mackall <mpm@elenic.com>
Add data from zero-entropy random_writes directly to output pools to 

Add data from zero-entropy random_writes directly to output pools to
avoid accounting difficulties on machines without entropy sources.

Tested on lguest with all entropy sources disabled.

Signed-off-by: Matt Mackall <mpm@elenic.com>
Acked-by: "Theodore Ts'o" <tytso@mit.edu>

diff-ms-entropy-fix-b-20070530

Patch from Matt Mackall <mpm@selenic.com>
random: fix seeding with zero entropy 

Add data from zero-entropy random_writes directly to output pools to
avoid accounting difficulties on machines without entropy sources.

Tested on lguest with all entropy sources disabled.

Signed-off-by: Matt Mackall <mpm@selenic.com>
Acked-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=7f397dcdb78d699a20d96bfcfb595a2411a5bbd2

diff-ms-ext3-iread-brelse-20070601

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] ext3: lost brelse in ext3_read_inode() 

One of error path in ext3_read_inode() leaks bh,
since brelse is forgoten.
Move brelese under bad_inode label, so that it is freed.

Signed-Off-By: Kirill Korotaev <dev@openvz.org>

diff-ms-ext3-orhpan-list-corruption-20070531

Patch from Vasily Averin <vvs@openvz.org>
[PATCH] ext3: orphan list corruption on bad inodes 

This patch fixes ext3 orphan list corruption due to bad inodes
created in ext3_read_inode().

Trying to catch orhpan list corruption in OpenVZ we found
the following debug messages in the logs:

May 30 10:39:38 df-rs-l24 kernel:
 EXT3-fs warning (device sda6): ext3_unlink: Deleting nonexistent file (37901290), 0
 Inode 00000101a15b7840: orphan list check failed!
 00000773 6f665f00 74616d72 00000573 65725f00 06737270 66000000 616d726f
...
 Call Trace: [<ffffffff80211ea9>] ext3_destroy_inode+0x79/0x90
  [<ffffffff801a2b16>] sys_unlink+0x126/0x1a0
  [<ffffffff80111479>] error_exit+0x0/0x81
  [<ffffffff80110aba>] system_call+0x7e/0x83

first messages says that unlinked inode has i_nlink=0,
then ext3_unlink() adds this inode into orphan list.

second message means that this inode has not been removed from orphan list, and
inode dump shows that i_fop = &bad_file_ops

Then I've discovered that bad_file_ops can be set only in make_bad_inode().
ext3_read_inode() can call make_bad_inode() without any
error/warning messages in the following case:
...
        if (inode->i_nlink == 0) {
                if (inode->i_mode == 0 ||
                    !(EXT3_SB(inode->i_sb)->s_mount_state & EXT3_ORPHAN_FS)) {
                        /* this inode is deleted */
                        brelse (bh);
                        goto bad_inode;
...

i.e when
   inode->i_nlink == 0
and
   !(EXT3_SB(inode->i_sb)->s_mount_state & EXT3_ORPHAN_FS)

Bad inode can live some time, ext3_unlink can add it to orphan list then,
but ext3_delete_inode() doesn't delete this inode from orphan list,
since inode is bad. As a result we have orphan list corruption
detected in ext3_destroy_inode().

This issue present in rhel4/rhel5/mainstream kernels too.

Bug #83419

diff-ms-ext3-orhpan-list-corruption-b-20070603

Patch from Vasily Averin <vvs@openvz.org>
[PATCH] ext3: orphan list corruption on bad inodes (v2) 

Changes to previous patch:
  instead of fixing ext3_unlink() better fix all the paths
  were bad inode can be found and used, i.e. lookup() and get_parent()

After ext3 orphan list check has been added into ext3_destroy_inode()
(please see my previous patch) the following situation has been detected:
 EXT3-fs warning (device sda6): ext3_unlink: Deleting nonexistent file (37901290), 0
 Inode 00000101a15b7840: orphan list check failed!
 00000773 6f665f00 74616d72 00000573 65725f00 06737270 66000000 616d726f
..
 Call Trace: [<ffffffff80211ea9>] ext3_destroy_inode+0x79/0x90
  [<ffffffff801a2b16>] sys_unlink+0x126/0x1a0
  [<ffffffff80111479>] error_exit+0x0/0x81
  [<ffffffff80110aba>] system_call+0x7e/0x83

First messages said that unlinked inode has i_nlink=0,
then ext3_unlink() adds this inode into orphan list.

Second message means that this inode has not been removed from orphan list.
Inode dump has showed that i_fop = &bad_file_ops and it can be set in
make_bad_inode() only. Then I've found that ext3_read_inode() can call
make_bad_inode() without any error/warning messages,
for example in the following case:
..
        if (inode->i_nlink == 0) {
                if (inode->i_mode == 0 ||
                    !(EXT3_SB(inode->i_sb)->s_mount_state & EXT3_ORPHAN_FS)) {
                        /* this inode is deleted */
                        brelse (bh);
                        goto bad_inode;
..

Bad inode can live some time, ext3_unlink can add it to orphan list, but
ext3_delete_inode() do not deleted this inode from orphan list. As
result we can have orphan list corruption detected in ext3_destroy_inode().

However it is not clear for me how to fix this issue correctly.

As far as i see is_bad_inode() is called after iget() in all places excluding
ext3_lookup() and ext3_get_parent(). I believe it makes sense to add bad inode
check to these functions too and call iput if bad inode detected.

Signed-off-by:  Vasily Averin <vvs@sw.ru>

diff-ms-ia64-nat-ptrace-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[IA64] ptrace returns garbage for NaT bits 

An old bug. Nobody needed those NaT bits, so that it was not noticed.

diff-ms-net-ipv6-privacy-msg-20070605

Patch from Vasily Averin <vvs@openvz.org>
[PATCH] disable "Disabled Privacy Extensions" messages 

Hide annoing useless messages about disabled
IPv6 privacy extensions, which is always triggered by loopback:
"lo: Disabled Privacy Extensions"

Bug #83651

diff-ms-net-settimeout-20070525

Patch from Vasily Averin <vvs@openvz.org>
[NET]: "wrong timeout value" in sk_wait_data() v2 

sys_setsockopt() do not check properly timeout values for
SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout
values. POSIX do not defines behaviour for sys_setsockopt in case negative
timeouts, but requires that setsockopt() shall fail with -EDOM if the send and
receive timeout values are too big to fit into the timeout fields in the socket
structure.
In current implementation negative timeout can lead to error messages like
"schedule_timeout: wrong timeout value".

Proposed patch:
- checks tv_usec and returns -EDOM if it is wrong
- do not allows to set negative timeout values (sets 0 instead) and outputs
ratelimited information message about such attempts.

Signed-off-By: Vasily Averin <vvs@sw.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>

X-Git-Tag: v2.6.22-rc3
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=ba78073e6f70cd9c64a478a9bd901d7c8736cfbc;hp=c883f215a23a9352097b8d17fb8dae22ff134a14

diff-ms-nfs-launder-20070530

Patch from Alexandr Andreev <aandreev@openvz.org>
[PATCH] NFS: Fix race in nfs_release_page() 

invalidate_inode_pages2() may find the dirty bit has been set on a page
owing to the fact that the page may still be mapped after it was locked.
Only after the call to unmap_mapping_range() are we sure that the page
can no longer be dirtied.
In order to fix this, NFS has hooked the releasepage() method and tries
to write the page out between the call to unmap_mapping_range() and the
call to remove_mapping(). This, however leads to deadlocks in the page
reclaim code, where the page may be locked without holding a reference
to the inode or dentry.

Fix is to add a new address_space_operation, launder_page(), which will
attempt to write out a dirty page without releasing the page lock.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

Also, the bare SetPageDirty() can skew all sort of accounting leading to
other nasties.

[akpm@osdl.org: cleanup]
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

From Alexandr:
This 'new' invalidate/release logic also fixes our problem with
mmap/write/read data corruption when several processes use the same
mmaped file on NFS

Bug #81896 

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e3db7691e9f3dff3289f64e3d98583e28afe03db

diff-ms-nfs-odirect-20070529

Patch from Denis Lunev <den@openvz.org>
[PATCH] nfs: oops during LTP over NFS (direct io) 

Problem reported by Denis Lunev and QA, fix from mainstream

incorrect comparison of "int" and "unsigned int" variables is fixed in
nfs_direct_read_schedule and nfs_direct_write_schedule.

Bug #81589

diff-ms-nfs-schedlock-20070530

Patch from Denis Lunev <den@openvz.org>
[PATCH] nfs: AB-BA deadlock on rpc_sched_lock/queue->lock locks 

This patch fixes possible AB-BA deadlock for rpc_sched_lock/queue->lock
in rpc_run_child().

Normal sequence is presented in rpc_set_active:
 - rpc_sched_lock goest first
 - queue->lock is nested.

Bug #82518

diff-ms-nfs-umount-refcnt-leak-20070530

Patch from Trond Myklebust <Trond.Myklebust@netapp.com>
[PATCH] nfs: fix req refcnt leak preventing umount 

Original Denis Lunev analyses:
- nfs_direct_req_alloc creates dreq with dreq->kref->refcount == 2
- on success path the kref_put is called in
      nfs_direct_read_schedule ->  nfs_direct_complete
   and in nfs_direct_wait
- on error path only first put occured
The same problem occures on direct_write path

Mainstream patch version from Trond Myklebust <Trond.Myklebust@netapp.com>:
The current code is leaking a reference to dreq->kref when the calls to
nfs_direct_read_schedule() and nfs_direct_write_schedule() return an
error.

Thanks to Denis V. Lunev for spotting the bug and proposing the original
fix.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

diff-ms-security-cpuset-20070605

Patch from Akinobu Mita <akinobu.mita@gmail.com>
use simple_read_from_buffer in kernel/ 

Cleanup using simple_read_from_buffer() for /dev/cpuset/tasks and
/proc/config.gz.

Cc: Paul Jackson <pj@sgi.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

X-Git-Tag: v2.6.22-rc1
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=85badbdf5120d246ce2bb3f1a7689a805f9c9006

diff-ms-security-sctp-20070604

Patch from Patrick McHardy <kaber@trash.net>
[NETFILTER]: {ip,nf}_conntrack_sctp: fix remotely triggerable NULL ptr dereference 

When creating a new connection by sending an unknown chunk type, we don't
transition to a valid state, causing a NULL pointer dereference in
sctp_packet when accessing sctp_timeouts[SCTP_CONNTRACK_NONE].

Fix by don't creating new conntrack entry if initial state is invalid.

Noticed by Vilmos Nebehaj <vilmos.nebehaj@ramsys.hu>

CC: Kiran Kumar Immidi <immidi_kiran@yahoo.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>

diff-ms-seqfile-seek-20070601

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[PATCH] seqfile: bash can hang in a loop reading from proc file 

Original problem: in some circumstances seq_file interface can present
infinite proc file to the following script when normally said proc file
is finite:

	while read line; do
		[do something with $line]
	done </proc/$FILE

bash, to implement such loop does essentially

	read(0, buf, 128);
	[find \n]
	lseek(0, -difference, SEEK_CUR);

Consider, proc file prints list of objects each of them consists of many
lines, each line is shorter than 128 bytes.

Two objects in list, with ->index'es being 0 and 1. Current one is 1,
as bash prints second object line by line.

Imagine first object being removed right before lseek().
traverse() will be called, because there is negative offset.
traverse() will reset ->index to 0 (!).
traverse() will call ->next() and get NULL in any usual iterate-over-list
code using list_for_each_entry_continue() and such. There is one object in
list now after all...
traverse() will return 0, lseek() will update file position and pretend
everything is OK.

So, what we have now: ->f_pos points to place where second object will be
printed, but ->index is 0. seq_read instead() of returning EOF, will start
printing first line of first object every time it's called, until enough
objects are added to ->f_pos return in bounds.

Fix is to update ->index only after we're sure we saw enough objects down
the road.

Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>

Bug #82819

diff-ubc-proc-rework-c-20070604

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] ubc: fix compilation with CONFIG_UBC_DEBUG_IO=y 

During rework of UBC /proc compilation with UBC_DEBUG_IO was
broken a bit.

diff-ubc-unix-exports-20070604

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] ubc: export ubc helpers for case CONFIG_UNIX=m 

Export ub_sock_getwres_other, since unix sockets can
call it from the module (unix.ko) when CONFIG_UNIX=m.

Thanks to Rafael Isturiz for having non-standart config  :)  and reporting this.

diff-ve-cpustats-20070528

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] VE cpu stats should be exported to user space in clocks 

VE cpu stats should be exported to user space in clocks intead of jiffies.

diff-ve-ip-nat-aliasing-20070605

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[PATCH] Unalias VE_IP_NAT for ip_nat and iptable_nat modules 

If ip_nat and ip_tables modules are loaded before VE start, and
iptable_nat after VE start, on VE stop kernel will crash in
ipt_unregister_table() attempting to unregister NULL table.

Split VE_IN_NAT flag responsible for two modules.

OpenVZ Bug #607

diff-ve-net-arp-set-perms-20070625

Patch from Vasily Tarasov <vtaras@openvz.org>
[PATCH] arp: allow set arp cache entries from VE 

It is secure since later we use __dev_get_by_name() function which is
aware about current context.

http://forum.openvz.org/index.php?t=tree&th=2570&mid=13209&&rev=&reveal=

diff-ve-net-veth-filtering-b-20070605

Patch from Andrey Mirkin <major@openvz.org>
[PATCH] veth: rework VE traffic filtering 

Mac filtering in veth_xmit() was a bit incorrect:
broadcasts and multicasts were allowed from VE.
Rearrange code, make it more clear and assymetric :/

diff-ve-net-veth-multicast-20070604

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] veth: multicasts should be forwarded as well 

Right now veth_xmit passes broadcasts only.
It is a bug. Multicasts should be allowed as well.

Thanks to Daniel Pittman for noticing this.

diff-ve-oom-adjust-20070604

Patch from Denis Lunev <den@openvz.org>
[PATCH] disable OOM_DISABLE inside VE 

Prevent disabling of OOM from inside VE. Basically, it is safe to
allow priority changes inside VE, as in normal case we select UB and a
process inside UB then.

diff-ve-reparent-threaded-init-20070604

Patch from Alexey Kuznetsov <alexey@openvz.org>
[PATCH] VE: reparent threaded init correctly 

If init is multithreaded (yes, imagine, this happens :-)),
its threads are reparented to VE init, so that we get parents
in the same thread group. Nothing especially bad happens,
only checkpointing cannot restore such sick configuration.

diff-ve-setattr-proc-20070524

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[PATCH 1/2] VE: allow proc setattr on local proc entries 

If PDE is local to VE, there is no reason to not allow setattr on it --
changes won't affect corresponding global PDE and other VEs.

OpenVZ Bug #509

diff-ve-setattr-proc-b-20070604

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[PATCH] proc: brown paper bag bug in proc's ->setattr 

->setattr is called for something innocent like mtime updates, so
outright banning of ->setattr on global proc entries was sadistic.

Check if ->setattr is called with mask indicating MODE, UID, GID change
and check for globalness only in this case.

OpenVZ Bug #604
OpenVZ Bug #509

diff-ve-setattr-proc-kmsg-20070524

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[PATCH] VE: make /proc/kmsg to be VE local 

Some people used to doing "chmod g+r /proc/kmsg". Make PDE corresponding
to /proc/kmsg local to VE, so it's possible to setattr it.

OpenVZ Bug #509

diff-ve-syslog-20070601

Patch from Vitaliy Gusev <vgusev@openvz.org>
Fix LTP test failure in syslog test. 

LTP failure is minor and simple: it calls syslog(2) with wrong arguments
and awaiting for an error. But syslog() returns 0 since VE doesn't
have real console and console loglevel.

Thanks Christian Kaiser2 <CKAISER2@de.ibm.com> for noticing this.

diff-ve-vpsdumpable-early-20070604

Patch from Kirill Korotaev <dev@openvz.org>
[PATCH] init vps_dumpable early on exec 

Since CPT uses vps_dumpable flag now for determining
external processes on checkpointing, we need to initialize
it earlier on mm creation on exec. Otherwise it can race.

diff-vzdq-restore-symlinks-under-sem-20070524

Patch from Alexey Dobriyan <adobriyan@openvz.org>
[PATCH] VZDQ: Fix lockdep warning about s_umount dependancy 

Lockdep learns false dependency due to vz_restore_symlink()
and later complains about possible circular locking when quotaon is
done.

Temporarily up ->s_umount semaphore to workaround this.

OpenVZ Bug #585

diff-xen-subarch-changes-20070528

Patch from Evgeny Kravtsunov <emkravts@openvz.org>
[PATCH] Fixes for Xen arch compilation / work

diff-ve-prepare-ve0-tasks-20070608

Patch from Alexandr Andreev <aandreev@openvz.org>
[PATCH] VE: ve0 processes intialization

VE0 processes were initialized twice:

  • in copy_process()
  • in prepare_ve0_process() from init_ve_system()

This is redundant and unneeded. Leading to wrong ve0.pcounter

Retrieved from "https://wiki.openvz.org/index.php?title=Download/kernel/rhel5/028stab035.1/changes&oldid=7766"