commit 88626272549b94310975932a9970d11a9b362a16 Merge: 5ae1d95 9307f6b Author: Linus Torvalds Date: Tue Feb 16 12:22:15 2010 -0800 Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm * git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm: dm: sysfs revert add empty release function to avoid debug warning dm mpath: fix stall when requeueing io dm raid1: fix null pointer dereference in suspend dm raid1: fail writes if errors are not handled and log fails dm log: userspace fix overhead_size calcuations dm snapshot: persistent annotate work_queue as on stack dm stripe: avoid divide by zero with invalid stripe count commit 5ae1d95568f647f890167877287fc4f54b7bdb2b Merge: 11557b2 22208ac Author: Linus Torvalds Date: Tue Feb 16 11:59:01 2010 -0800 Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] preserve personality flag bits across exec commit 9307f6b19ac4f5887552b5b2992f391b866f7633 Author: Alasdair G Kergon Date: Tue Feb 16 18:43:04 2010 +0000 dm: sysfs revert add empty release function to avoid debug warning Revert commit d2bb7df8cac647b92f51fb84ae735771e7adbfa7 at Greg's request. Author: Milan Broz Date: Thu Dec 10 23:51:53 2009 +0000 dm: sysfs add empty release function to avoid debug warning This patch just removes an unnecessary warning: kobject: 'dm': does not have a release() function, it is broken and must be fixed. The kobject is embedded in mapped device struct, so code does not need to release memory explicitly here. Cc: Greg KH Signed-off-by: Alasdair G Kergon commit 9eef87da2a8ea4920e0d913ff977cac064b68ee0 Author: Kiyoshi Ueda Date: Tue Feb 16 18:43:01 2010 +0000 dm mpath: fix stall when requeueing io This patch fixes the problem that system may stall if target's ->map_rq returns DM_MAPIO_REQUEUE in map_request(). E.g. stall happens on 1 CPU box when a dm-mpath device with queue_if_no_path bounces between all-paths-down and paths-up on I/O load. When target's ->map_rq returns DM_MAPIO_REQUEUE, map_request() requeues the request and returns to dm_request_fn(). Then, dm_request_fn() doesn't exit the I/O dispatching loop and continues processing the requeued request again. This map and requeue loop can be done with interrupt disabled, so 1 CPU system can be stalled if this situation happens. For example, commands below can stall my 1 CPU box within 1 minute or so: # dmsetup table mp mp: 0 2097152 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 2 8:144 1 1 # while true; do dd if=/dev/mapper/mp of=/dev/null bs=1M count=100; done & # while true; do \ > dmsetup message mp 0 "fail_path 8:144" \ > dmsetup suspend --noflush mp \ > dmsetup resume mp \ > dmsetup message mp 0 "reinstate_path 8:144" \ > done To fix the problem above, this patch changes dm_request_fn() to exit the I/O dispatching loop once if a request is requeued in map_request(). Signed-off-by: Kiyoshi Ueda Signed-off-by: Jun'ichi Nomura Cc: stable@kernel.org Signed-off-by: Alasdair G Kergon commit 558569aa9d83e016295bac77d900342908d7fd85 Author: Takahiro Yasui Date: Tue Feb 16 18:42:58 2010 +0000 dm raid1: fix null pointer dereference in suspend When suspending a failed mirror, bios are completed by mirror_end_io() and __rh_lookup() in dm_rh_dec() returns NULL where a non-NULL return value is required by design. Fix this by not changing the state of the recovery failed region from DM_RH_RECOVERING to DM_RH_NOSYNC in dm_rh_recovery_end(). Issue On 2.6.33-rc1 kernel, I hit the bug when I suspended the failed mirror by dmsetup command. BUG: unable to handle kernel NULL pointer dereference at 00000020 IP: [] dm_rh_dec+0x35/0xa1 [dm_region_hash] ... EIP: 0060:[] EFLAGS: 00010046 CPU: 0 EIP is at dm_rh_dec+0x35/0xa1 [dm_region_hash] EAX: 00000286 EBX: 00000000 ECX: 00000286 EDX: 00000000 ESI: eff79eac EDI: eff79e80 EBP: f6915cd4 ESP: f6915cc4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process dmsetup (pid: 2849, ti=f6914000 task=eff03e80 task.ti=f6914000) ... Call Trace: [] ? mirror_end_io+0x53/0x1b1 [dm_mirror] [] ? clone_endio+0x4d/0xa2 [dm_mod] [] ? mirror_end_io+0x0/0x1b1 [dm_mirror] [] ? clone_endio+0x0/0xa2 [dm_mod] [] ? bio_endio+0x28/0x2b [] ? hold_bio+0x2d/0x62 [dm_mirror] [] ? mirror_presuspend+0xeb/0xf7 [dm_mirror] [] ? vmap_page_range+0xb/0xd [] ? suspend_targets+0x2d/0x3b [dm_mod] [] ? dm_table_presuspend_targets+0xe/0x10 [dm_mod] [] ? dm_suspend+0x4d/0x150 [dm_mod] [] ? dev_suspend+0x55/0x18a [dm_mod] [] ? _copy_from_user+0x42/0x56 [] ? dm_ctl_ioctl+0x22c/0x281 [dm_mod] [] ? dev_suspend+0x0/0x18a [dm_mod] [] ? dm_ctl_ioctl+0x0/0x281 [dm_mod] [] ? vfs_ioctl+0x22/0x85 [] ? do_vfs_ioctl+0x4cb/0x516 [] ? sys_ioctl+0x40/0x5a [] ? sysenter_do_call+0x12/0x28 Analysis When recovery process of a region failed, dm_rh_recovery_end() function changes the state of the region from RM_RH_RECOVERING to DM_RH_NOSYNC. When recovery_complete() is executed between dm_rh_update_states() and dm_writes() in do_mirror(), bios are processed with the region state, DM_RH_NOSYNC. However, the region data is freed without checking its pending count when dm_rh_update_states() is called next time. When bios are finished by mirror_end_io(), __rh_lookup() in dm_rh_dec() returns NULL even though a valid return value are expected. Solution Remove the state change of the recovery failed region from DM_RH_RECOVERING to DM_RH_NOSYNC in dm_rh_recovery_end(). We can remove the state change because: - If the region data has been released by dm_rh_update_states(), a new region data is created with the state of DM_RH_NOSYNC, and bios are processed according to the DM_RH_NOSYNC state. - If the region data has not been released by dm_rh_update_states(), a state of the region is DM_RH_RECOVERING and bios are put in the delayed_bio list. The flag change from DM_RH_RECOVERING to DM_RH_NOSYNC in dm_rh_recovery_end() was added in the following commit: dm raid1: handle resync failures author Jonathan Brassow Thu, 12 Jul 2007 16:29:04 +0000 (17:29 +0100) http://git.kernel.org/linus/f44db678edcc6f4c2779ac43f63f0b9dfa28b724 Signed-off-by: Takahiro Yasui Reviewed-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon commit 5528d17de1cf1462f285c40ccaf8e0d0e4c64dc0 Author: Mikulas Patocka Date: Tue Feb 16 18:42:55 2010 +0000 dm raid1: fail writes if errors are not handled and log fails If the mirror log fails when the handle_errors option was not selected and there is no remaining valid mirror leg, writes return success even though they weren't actually written to any device. This patch completes them with EIO instead. This code path is taken: do_writes: bio_list_merge(&ms->failures, &sync); do_failures: if (!get_valid_mirror(ms)) (false) else if (errors_handled(ms)) (false) else bio_endio(bio, 0); The logic in do_failures is based on presuming that the write was already tried: if it succeeded at least on one leg (without handle_errors) it is reported as success. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=555197 Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon commit ebfd32bba9b518d684009d9d21a56742337ca1b3 Author: Jonathan Brassow Date: Tue Feb 16 18:42:53 2010 +0000 dm log: userspace fix overhead_size calcuations This patch fixes two bugs that revolve around the miscalculation and misuse of the variable 'overhead_size'. 'overhead_size' is the size of the various header structures used during communication. The first bug is the use of 'sizeof' with the pointer of a structure instead of the structure itself - resulting in the wrong size being computed. This is then used in a check to see if the payload (data_size) would be to large for the preallocated structure. Since the bug produces a smaller value for the overhead, it was possible for the structure to be breached. (Although the current users of the code do not currently send enough data to trigger this bug.) The second bug is that the 'overhead_size' value is used to compute how much of the preallocated space should be cleared before populating it with fresh data. This should have simply been 'sizeof(struct cn_msg)' not overhead_size. The fact that 'overhead_size' was computed incorrectly made this problem "less bad" - leaving only a pointer's worth of space at the end uncleared. Thus, this bug was never producing a bad result, but still needs to be fixed - especially now that the value is computed correctly. Cc: stable@kernel.org Signed-off-by: Jonathan Brassow commit 55f67f2dedec1e3049abc30b6d82b999a14cafb7 Author: Mike Snitzer Date: Tue Feb 16 18:42:51 2010 +0000 dm snapshot: persistent annotate work_queue as on stack chunk_io() declares its 'struct mdata_req' on the stack and then initializes its 'struct work_struct' member. Annotate the initialization of this workqueue with INIT_WORK_ON_STACK to suppress a debugobjects warning seen when CONFIG_DEBUG_OBJECTS_WORK is enabled. Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon commit 781248c1b50c776a9ef4be1130f84ced1cba42fe Author: Nikanth Karthikesan Date: Tue Feb 16 18:42:47 2010 +0000 dm stripe: avoid divide by zero with invalid stripe count If a table containing zero as stripe count is passed into stripe_ctr the code attempts to divide by zero. This patch changes DM_TABLE_LOAD to return -EINVAL if the stripe count is zero. We now get the following error messages: device-mapper: table: 253:0: striped: Invalid stripe count device-mapper: ioctl: error adding target to table Signed-off-by: Nikanth Karthikesan Cc: stable@kernel.org Signed-off-by: Alasdair G Kergon commit 11557b24fdec13cb1c3d5f681688401a651ed54e Author: Oleg Nesterov Date: Tue Feb 16 15:24:01 2010 +0100 x86: ELF_PLAT_INIT() shouldn't worry about TIF_IA32 The 64-bit version of ELF_PLAT_INIT() clears TIF_IA32, but at this point it has already been cleared by SET_PERSONALITY == set_personality_64bit. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds commit 1252f238db48ec419f40c1bdf30fda649860eed9 Author: Oleg Nesterov Date: Tue Feb 16 15:02:13 2010 +0100 x86: set_personality_ia32() misses force_personality32 05d43ed8a "x86: get rid of the insane TIF_ABI_PENDING bit" forgot about force_personality32. Fix. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds commit 0813e22d4e0d618eac9b47bec942bf856adca4c5 Merge: 382640b 3f6fae9 Author: Linus Torvalds Date: Mon Feb 15 19:56:21 2010 -0800 Merge git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable * git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable: Btrfs: btrfs_mark_extent_written uses the wrong slot commit 382640b3372405c40b7646c68a50ca91358027e4 Merge: d277993 7f51a10 Author: Linus Torvalds Date: Mon Feb 15 19:54:54 2010 -0800 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: ohci: retransmit isochronous transmit packets on cycle loss firewire: net: fix panic in fwnet_write_complete commit d277993f78b8a5376477c487208d82bc4fecab95 Merge: 65d2695 0a27fcf Author: Linus Torvalds Date: Mon Feb 15 19:54:18 2010 -0800 Merge branch 'fix/hda' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 * 'fix/hda' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6: ALSA: hda - Correct ASUA blacklist for MSI brokenness commit 65d269538a1129495ac45a14a777cd11cfe881d8 Author: Chuck Lever Date: Mon Feb 15 12:19:53 2010 -0500 NFS: Too many GETATTR and ACCESS calls after direct I/O The cached read and write paths initialize fattr->time_start in their setup procedures. The value of fattr->time_start is propagated to read_cache_jiffies by nfs_update_inode(). Subsequent calls to nfs_attribute_timeout() will then use a good time stamp when computing the attribute cache timeout, and squelch unneeded GETATTR calls. Since the direct I/O paths erroneously leave the inode's fattr->time_start field set to zero, read_cache_jiffies for that inode is set to zero after any direct read or write operation. This triggers an otw GETATTR or ACCESS call to update the file's attribute and access caches properly, even when the NFS READ or WRITE replies have usable post-op attributes. Make sure the direct read and write setup code performs the same fattr initialization as the cached I/O paths to prevent unnecessary GETATTR calls. This was likely introduced by commit 0e574af1 in 2.6.15, which appears to add new nfs_fattr_init() call sites in the cached read and write paths, but not in the equivalent places in fs/nfs/direct.c. A subsequent commit in the same series, 33801147, introduces the fattr->time_start field. Interestingly, the direct write reschedule path already has a call to nfs_fattr_init() in the right place. Reported-by: Quentin Barnes Signed-off-by: Chuck Lever Cc: stable@kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Linus Torvalds commit 7d0bab9dfecb3717f7e704b60a9f11631cb6636e Merge: 0aa2ca9a b9c3032 Author: Linus Torvalds Date: Mon Feb 15 19:52:12 2010 -0800 Merge branch 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: hrtimer, softirq: Fix hrtimer->softirq trampoline commit 0aa2ca9ae1e08d11661abb00ae6e75ff885448d6 Merge: 76212a8 175359f Author: Linus Torvalds Date: Mon Feb 15 19:51:45 2010 -0800 Merge branch 'reiserfs/kill-bkl' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing * 'reiserfs/kill-bkl' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing: reiserfs: Fix softlockup while waiting on an inode commit 76212a840f6edc2b89865f09464f3bd90125896d Merge: e04984c e803e8b Author: Linus Torvalds Date: Mon Feb 15 19:51:15 2010 -0800 Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 * 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm/radeon/kms: make sure retry count increases. drm/radeon/kms/atom: use get_unaligned_le32() for ctx->ps drm/ttm: Fix a bug occuring when validating a buffer object in a range. drm: Fix a bug in the range manager. commit e04984c8394b17bab85c28956ada6aba81cdf746 Merge: 627a9a1 4b505db Author: Linus Torvalds Date: Mon Feb 15 19:50:34 2010 -0800 Merge branch 'sh/for-2.6.33' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 * 'sh/for-2.6.33' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: sh64: fix tracing of signals. commit 627a9a194d6b29d345d99ef806171395bc6e3e38 Merge: 3d8b4bd a9bb18f Author: Linus Torvalds Date: Mon Feb 15 19:47:59 2010 -0800 Merge branch 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: tracing/kprobes: Fix probe parsing tracing: Fix circular dead lock in stack trace commit 3d8b4bdef7e7c9d36ce90e563788c10051a91c34 Merge: 724e6d3 1a72cfa Author: Linus Torvalds Date: Mon Feb 15 19:47:48 2010 -0800 Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: perf top: Fix help text alignment perf: Fix hypervisor sample reporting perf: Make bp_len type to u64 generic across the arch commit 0a27fcfaaf61108d94f0377f91bed81b2dd35f52 Author: Takashi Iwai Date: Mon Feb 15 17:05:28 2010 +0100 ALSA: hda - Correct ASUA blacklist for MSI brokenness The MSI blacklist entry for ASUS mobo added in the commit 8ce28d6abff34886d3797b25324c940471b99164 was based on the alsa-info output wrongly posted. Fix the id to the right one now. Reported-by: Sid Boyce Signed-off-by: Takashi Iwai commit e803e8b2628f3e9a42f45c5b7bb1f9821b08352c Author: Dave Airlie Date: Mon Feb 15 15:24:48 2010 +1000 drm/radeon/kms: make sure retry count increases. In testing I've never seen it go past 1 retry anyways but better safe than sorry. Reported by Droste on irc. Signed-off-by: Dave Airlie commit 4b505db9c4c72dbd2a8e66b8d681640101325af6 Author: Paul Mundt Date: Mon Feb 15 14:17:45 2010 +0900 sh64: fix tracing of signals. This follows the parisc change to ensure that tracehook_signal_handler() is aware of when we are single-stepping in order to ptrace_notify() appropriately. While this was implemented for 32-bit SH, sh64 neglected to make use of TIF_SINGLESTEP when it was folded in with the 32-bit code, resulting in ptrace_notify() never being called. As sh64 uses all of the other abstractions already, this simply plugs in the thread flag in the appropriate enable/disable paths and fixes up the tracehook notification accordingly. With this in place, sh64 is brought in line with what 32-bit is already doing. Reported-by: Mike Frysinger Signed-off-by: Paul Mundt commit ce36f00d599e0f988c2a1b7b276d9184ee9c5d82 Author: Matt Turner Date: Sat Feb 13 20:20:19 2010 -0500 drm/radeon/kms/atom: use get_unaligned_le32() for ctx->ps Noticed on a DEC Alpha. Start up into console mode caused 15 unaligned accesses, and starting X caused another 48. Signed-off-by: Matt Turner CC: Jerome Glisse CC: Alex Deucher Signed-off-by: Dave Airlie commit e22238ea37a870f70e34668a4992bde0c92bba8d Author: Thomas Hellstrom Date: Fri Feb 12 00:18:00 2010 +0100 drm/ttm: Fix a bug occuring when validating a buffer object in a range. If the buffer object was already in the requested memory type, but outside of the requested range it was never moved into the requested range. Signed-off-by: Thomas Hellstrom Signed-off-by: Dave Airlie commit 775c67090c98780b44c4f95d5c05565df715b8bd Author: Thomas Hellstrom Date: Fri Feb 12 00:17:59 2010 +0100 drm: Fix a bug in the range manager. When searching for free space in a range, the function could return a node extending outside of the given range. Signed-off-by: Thomas Hellstrom Signed-off-by: Dave Airlie commit 175359f89df39f4faed663c8cfd6ee0222d2fa1e Author: Frederic Weisbecker Date: Thu Feb 11 13:13:10 2010 +0100 reiserfs: Fix softlockup while waiting on an inode When we wait for an inode through reiserfs_iget(), we hold the reiserfs lock. And waiting for an inode may imply waiting for its writeback. But the inode writeback path may also require the reiserfs lock, which leads to a deadlock. We just need to release the reiserfs lock from reiserfs_iget() to fix this. Reported-by: Alexander Beregalov Signed-off-by: Frederic Weisbecker Tested-by: Christian Kujau Cc: Chris Mason commit 7f51a100bba517196ac4bdf29408d20ee1c771e8 Author: Clemens Ladisch Date: Mon Feb 8 08:30:03 2010 +0100 firewire: ohci: retransmit isochronous transmit packets on cycle loss In isochronous transmit DMA descriptors, link the skip address pointer back to the descriptor itself. When a cycle is lost, the controller will send the packet in the next cycle, instead of terminating the entire DMA program. There are two reasons for this: * This behaviour is compatible with the old IEEE1394 stack. Old applications would not expect the DMA program to stop in this case. * Since the OHCI driver does not report any uncompleted packets, the context would stop silently; clients would not have any chance to detect and handle this error without a watchdog timer. Signed-off-by: Clemens Ladisch Pieter Palmers notes: "The reason I added this retry behavior to the old stack is because some cards now and then fail to send a packet (e.g. the o2micro card in my dell laptop). I couldn't figure out why exactly this happens, my best guess is that the card cannot fetch the payload data on time. This happens much more frequently when sending large packets, which leads me to suspect that there are some contention issues with the DMA that fills the transmit FIFO. In the old stack it was a pretty critical issue as it resulted in a freeze of the userspace application. The omission of a packet doesn't necessarily have to be an issue. E.g. in IEC61883 streams the DBC field can be used to detect discontinuities in the stream. So as long as the other side doesn't bail when no [packet] is present in a cycle, there is not really a problem. I'm not convinced though that retrying is the proper solution, but it is simple and effective for what it had to do. And I think there are no reasons not to do it this way. Userspace can still detect this by checking the cycle the descriptor was sent in." Signed-off-by: Stefan Richter (changelog, comment) commit 1a72cfa6856e7d58e049c42c6e6a789669478479 Author: Kirill Smelkov Date: Fri Feb 12 19:20:59 2010 +0300 perf top: Fix help text alignment Print this: Mapped keys: [d] display refresh delay. (2) [e] display entries (lines). (46) [f] profile display filter (count). (5) [F] annotate display filter (percent). (5%) [s] annotate symbol. (NULL) [S] stop annotation. [K] hide kernel_symbols symbols. (no) [U] hide user symbols. (no) [z] toggle sample zeroing. (0) [qQ] quit. instead of: Mapped keys: [d] display refresh delay. (2) [e] display entries (lines). (46) [f] profile display filter (count). (5) [F] annotate display filter (percent). (5%) [s] annotate symbol. (NULL) [S] stop annotation. [K] hide kernel_symbols symbols. (no) [U] hide user symbols. (no) [z] toggle sample zeroing. (0) [qQ] quit. Signed-off-by: Kirill Smelkov Acked-by: Arnaldo Carvalho de Melo Cc: Peter Zijlstra Cc: Mike Galbraith Cc: Paul Mackerras Cc: Frederic Weisbecker LKML-Reference: <20100212162059.GA30041@landau.phys.spbu.ru> Signed-off-by: Ingo Molnar commit a9bb18f36c8056f0712fb28c52c0f85d98438dfb Author: Heiko Carstens Date: Wed Feb 10 17:23:47 2010 +0100 tracing/kprobes: Fix probe parsing Trying to add a probe like: echo p:myprobe 0x10000 > /sys/kernel/debug/tracing/kprobe_events will fail since the wrong pointer is passed to strict_strtoul when trying to convert the address to an unsigned long. Signed-off-by: Heiko Carstens Acked-by: Masami Hiramatsu Cc: Frederic Weisbecker Cc: Steven Rostedt LKML-Reference: <20100210162346.GA6933@osiris.boeblingen.de.ibm.com> Signed-off-by: Ingo Molnar commit 3f6fae9559225741c91f1320090b285da1413290 Author: Shaohua Li Date: Thu Feb 11 07:43:00 2010 +0000 Btrfs: btrfs_mark_extent_written uses the wrong slot My test do: fallocate a big file and do write. The file is 512M, but after file write is done btrfs-debug-tree shows: item 6 key (257 EXTENT_DATA 0) itemoff 3516 itemsize 53 extent data disk byte 1103101952 nr 536870912 extent data offset 0 nr 399634432 ram 536870912 extent compression 0 Looks like a regression introducted by 6c7d54ac87f338c479d9729e8392eca3f76e11e1, where we set wrong slot. Signed-off-by: Shaohua Li Acked-by: Yan Zheng Signed-off-by: Chris Mason commit 22208ac586f2e456c49e927b90ded50e923b6aee Author: Tony Luck Date: Fri Feb 12 08:17:58 2010 -0800 [IA64] preserve personality flag bits across exec In its ia64 defines SET_PERSONALITY in a way that unconditionally sets the personality of the current process to PER_LINUX, losing any flag bits from the upper 3 bytes of current->personality. This is wrong. Those bits are intended to be inherited across exec (other code takes care of ensuring that security sensitive bits like ADDR_NO_RANDOMIZE are not passed to unsuspecting setuid/setgid applications). Signed-off-by: Tony Luck commit 7fbfc683f1cc4051aa095ebe48d9d1e8b015682d Author: Anton Blanchard Date: Tue Feb 9 14:43:05 2010 +1100 perf: Fix hypervisor sample reporting cpumode bits are defined as such: #define PERF_RECORD_MISC_KERNEL (1 << 0) #define PERF_RECORD_MISC_USER (2 << 0) #define PERF_RECORD_MISC_HYPERVISOR (3 << 0) We need to compare against the complete value of cpumode, otherwise hypervisor samples get incorrectly attributed as userspace. Signed-off-by: Anton Blanchard Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: fweisbec@gmail.com LKML-Reference: <20100209034304.GA3702@kryten> Signed-off-by: Ingo Molnar commit cd757645fbdc34a8343c04bb0e74e06fccc2cb10 Author: Mahesh Salgaonkar Date: Sat Jan 30 10:25:18 2010 +0530 perf: Make bp_len type to u64 generic across the arch Change 'bp_len' type to __u64 to make it work across archs as the s390 architecture watch point length can be upto 2^64. reference: http://lkml.org/lkml/2010/1/25/212 This is an ABI change that is not backward compatible with the previous hardware breakpoint info layout integrated in this development cycle, a rebuilt of perf tools is necessary for versions based on 2.6.33-rc1 - 2.6.33-rc6 to work with a kernel based on this patch. Signed-off-by: Mahesh Salgaonkar Acked-by: Peter Zijlstra Cc: Ananth N Mavinakayanahalli Cc: "K. Prasad" Cc: Maneesh Soni Cc: Heiko Carstens Cc: Martin LKML-Reference: <20100130045518.GA20776@in.ibm.com> Signed-off-by: Frederic Weisbecker commit b9c3032277f756e73f6c673419dc414155e04e46 Author: Peter Zijlstra Date: Wed Feb 3 18:08:52 2010 +0100 hrtimer, softirq: Fix hrtimer->softirq trampoline hrtimers callbacks are always done from hardirq context, either the jiffy tick interrupt or the hrtimer device interrupt. [ there is currently one exception that can still call a hrtimer callback from softirq, but even in that case this will still work correctly. ] Reported-by: Wei Yongjun Signed-off-by: Peter Zijlstra Cc: Yury Polyanskiy Tested-by: Wei Yongjun Acked-by: David S. Miller LKML-Reference: <1265120401.24455.306.camel@laptop> Signed-off-by: Thomas Gleixner commit 4f48f8b7fd18c44f8478174f9925cc3c059c6ce4 Author: Lai Jiangshan Date: Tue Feb 2 15:32:09 2010 +0800 tracing: Fix circular dead lock in stack trace When we cat /tracing/stack_trace, we may cause circular lock: sys_read() t_start() arch_spin_lock(&max_stack_lock); t_show() seq_printf(), vsnprintf() .... /* they are all trace-able, when they are traced, max_stack_lock may be required again. */ The following script can trigger this circular dead lock very easy: #!/bin/bash echo 1 > /proc/sys/kernel/stack_tracer_enabled mount -t debugfs xxx /mnt > /dev/null 2>&1 ( # make check_stack() zealous to require max_stack_lock for ((; ;)) { echo 1 > /mnt/tracing/stack_max_size } ) & for ((; ;)) { cat /mnt/tracing/stack_trace > /dev/null } To fix this bug, we increase the percpu trace_active before require the lock. Reported-by: Li Zefan Signed-off-by: Lai Jiangshan LKML-Reference: <4B67D4F9.9080905@cn.fujitsu.com> Signed-off-by: Steven Rostedt commit 110f82d7a2e0ff5a17617a9672f1ccb7e44bc0c6 Author: Stefan Richter Date: Mon Jan 18 22:36:49 2010 +0100 firewire: net: fix panic in fwnet_write_complete In the transmit path of firewire-net (IPv4 over 1394), the following race condition may occur: - The networking soft IRQ inserts a datagram into the 1394 async request transmit DMA. - The 1394 async transmit completion tasklet runs to finish cleaning up (unlink datagram from list of pending ones, release skb and outbound 1394 transaction object) --- before the networking soft IRQ had a chance to proceed and add the datagram to the list of pending datagrams. This caused a panic in the 1394 async transmit completion tasklet when it dereferenced unitialized list heads: http://bugzilla.kernel.org/show_bug.cgi?id=15077 The fix is to add checks in the tx soft IRQ and in the tasklet to determine which of these two is the last referrer to the transaction object. Then handle the cleanup of the object by the last referrer rather than assuming that the tasklet is always the last one. There is another similar race: Between said tasklet and fwnet_close, i.e. at ifdown. However, that race is much less likely to occur in practice and shall be fixed in a separate update. Reported-by: Илья Басин Signed-off-by: Stefan Richter