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