aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-11-20btrfs: Use trace condition for get_extent tracepointSteven Rostedt2-3/+4
Doing an if statement to test some condition to know if we should trigger a tracepoint is pointless when tracing is disabled. This just adds overhead and wastes a branch prediction. This is why the TRACE_EVENT_CONDITION() was created. It places the check inside the jump label so that the branch does not happen unless tracing is enabled. That is, instead of doing: if (em) trace_btrfs_get_extent(root, em); Which is basically this: if (em) if (static_key(trace_btrfs_get_extent)) { Using a TRACE_EVENT_CONDITION() we can just do: trace_btrfs_get_extent(root, em); And the condition trace event will do: if (static_key(trace_btrfs_get_extent)) { if (em) { ... The static key is a non conditional jump (or nop) that is faster than having to check if em is NULL or not. Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20btrfs: fix typo in the log messageAnand Jain1-1/+1
Signed-off-by: Anand Jain <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: fix list delete warning when removing ordered root from the listMiao Xie1-0/+1
Commit b02441999efcc6152b87cd58e7970bb7843f76cf "Btrfs: don't wait for the completion of all the ordered extents" introduced a bug that broke the ordered root list: WARNING: CPU: 1 PID: 7119 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98() It is because we forgot to return the roots in the splice list to the ordered list of the fs. Fix it. Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: print bytenr instead of page pointer in check-intStefan Behrens1-8/+17
The page pointer information was useless. The bytenr is what you want when you search for submitted write bios. Additionally, a new bit in the print mask is added that allows to selectively enable the check-int submit_bio verbose mode. Before, the global verbose mode had to be enabled leading to many million useless lines in the kernel log. And a comment is added that explains that LOG_BUF_SHIFT needs to be set to a really high value. Signed-off-by: Stefan Behrens <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: remove dead codes from ctree.hWang Shilong1-6/+0
These two functions are only stated but undefined. Signed-off-by: Wang Shilong <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: don't wait for ordered data outside desired rangeFilipe David Borba Manana1-1/+1
In btrfs_wait_ordered_range(), if we found an extent to the left of the start of our desired wait range and the last byte of that extent is 1 less than the desired range's start, we would would wait for the IO completion of that extent unnecessarily. Signed-off-by: Filipe David Borba Manana <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: fix lockdep error in async commitLiu Bo1-2/+2
Lockdep complains about btrfs's async commit: [ 2372.462171] [ BUG: bad unlock balance detected! ] [ 2372.462191] 3.12.0+ #32 Tainted: G W [ 2372.462209] ------------------------------------- [ 2372.462228] ceph-osd/14048 is trying to release lock (sb_internal) at: [ 2372.462275] [<ffffffffa022cb10>] btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462305] but there are no more locks to release! [ 2372.462324] [ 2372.462324] other info that might help us debug this: [ 2372.462349] no locks held by ceph-osd/14048. [ 2372.462367] [ 2372.462367] stack backtrace: [ 2372.462386] CPU: 2 PID: 14048 Comm: ceph-osd Tainted: G W 3.12.0+ #32 [ 2372.462414] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 11/09/2011 [ 2372.462455] ffffffffa022cb10 ffff88007490fd28 ffffffff816f094a ffff8800378aa320 [ 2372.462491] ffff88007490fd50 ffffffff810adf4c ffff8800378aa320 ffff88009af97650 [ 2372.462526] ffffffffa022cb10 ffff88007490fd88 ffffffff810b01ee ffff8800898c0000 [ 2372.462562] Call Trace: [ 2372.462584] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462619] [<ffffffff816f094a>] dump_stack+0x45/0x56 [ 2372.462642] [<ffffffff810adf4c>] print_unlock_imbalance_bug+0xec/0x100 [ 2372.462677] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462710] [<ffffffff810b01ee>] lock_release+0x18e/0x210 [ 2372.462742] [<ffffffffa022cb36>] btrfs_commit_transaction_async+0x1d6/0x2a0 [btrfs] [ 2372.462783] [<ffffffffa025a7ce>] btrfs_ioctl_start_sync+0x3e/0xc0 [btrfs] [ 2372.462822] [<ffffffffa025f1d3>] btrfs_ioctl+0x4c3/0x1f70 [btrfs] [ 2372.462849] [<ffffffff812c0321>] ? avc_has_perm+0x121/0x1b0 [ 2372.462873] [<ffffffff812c0224>] ? avc_has_perm+0x24/0x1b0 [ 2372.462897] [<ffffffff8107ecc8>] ? sched_clock_cpu+0xa8/0x100 [ 2372.462922] [<ffffffff8117b145>] do_vfs_ioctl+0x2e5/0x4e0 [ 2372.462946] [<ffffffff812c19e6>] ? file_has_perm+0x86/0xa0 [ 2372.462969] [<ffffffff8117b3c1>] SyS_ioctl+0x81/0xa0 [ 2372.462991] [<ffffffff817045a4>] tracesys+0xdd/0xe2 ==================================================== It's because that we don't do the right thing when checking if it's ok to tell lockdep that we're trying to release the rwsem. If the trans handle's type is TRANS_ATTACH, we won't acquire the freeze rwsem, but as TRANS_ATTACH fits the check (trans < TRANS_JOIN_NOLOCK), we'll release the freeze rwsem, which makes lockdep complains a lot. Reported-by: Ma Jianpeng <[email protected]> Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: avoid heavy operations in btrfs_commit_superLiu Bo1-20/+1
The 'git blame' history shows that, the old transaction commit code has to do twice to ensure roots are updated and we have to flush metadata and super block manually, however, right now all of these can be handled well inside the transaction commit code without extra efforts. And the error handling part remains same with the current code, -- 'return to caller once we get error'. This saves us a transaction commit and a flush of super block, which are both heavy operations according to ftrace output analysis. Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: fix __btrfs_start_workers retvalIlya Dryomov1-0/+1
__btrfs_start_workers returns 0 in case it raced with btrfs_stop_workers and lost the race. This is wrong because worker in this case is not allowed to start and is in fact destroyed. Return -EINVAL instead. Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: disable online raid-repair on ro mountsIlya Dryomov1-3/+8
This disables the "if needed, write the good copy back before the read is completed" part of the read sequence for read-only mounts. Cc: Jan Schmidt <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: do not inc uncorrectable_errors counter on ro scrubsIlya Dryomov1-2/+4
Currently if we discover an error when scrubbing in ro mode we a) blindly increment the uncorrectable_errors counter, and b) spam the dmesg with the 'unable to fixup (regular) error at ...' message, even though a) we haven't tried to determine if the error is correctable or not, and b) we haven't tried to fixup anything. Fix this. Cc: Stefan Behrens <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: only drop modified extents if we logged the whole inodeJosef Bacik1-1/+1
If we fsync, seek and write, rename and then fsync again we will lose the modified hole extent because the rename will drop all of the modified extents since we didn't do the fast search. We need to only drop the modified extents if we didn't do the fast search and we were logging the entire inode as we don't need them anymore, otherwise this is being premature. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: make sure to copy everything if we renameJosef Bacik1-1/+2
If we rename a file that is already in the log and we fsync again we will lose the new name. This is because we just log the inode update and not the new ref. To fix this we just need to check if we are logging the new name of the inode and copy all the metadata instead of just updating the inode itself. With this patch my testcase now passes. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20Btrfs: don't BUG_ON() if we get an error walking backrefsJosef Bacik1-1/+2
We can just return false for this so we stop doing the snapshot aware defrag stuff. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-11-20x86, wmi fix modalias_show return valuesPrarit Bhargava1-2/+4
I just fixed this same bug in arch/powerpc/kernel/vio.c and took a quick look for other similar errors in the kernel. modalias_show() should return an empty string on error, not errno. Signed-off-by: Prarit Bhargava <[email protected]> Cc: Matthew Garrett <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20ipc: Added support for IPC interrupt modeKuppuswamy Sathyanarayanan1-3/+45
This patch adds support for ipc command interrupt mode. Also added platform data option to select 'irq_mode' irq_mode = 1: configure the driver to receive IOC interrupt for each successful ipc_command. irq_mode = 0: makes driver use polling method to track the command completion status. Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: David Cohen <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-21ACPI / sleep: clean up compiler warning about uninitialized fieldAl Stone1-1/+1
Initialize pwr_btn_status as disabled which (a) makes sure it is in a proper state to start, and (b) cleans up a compiler warning about an uninitialized variable. Signed-off-by: Al Stone <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-11-20ipc: Handle error conditions in ipc commandKuppuswamy Sathyanarayanan1-3/+5
Handle error conditions in intel_scu_ipc_command() and pwr_reg_rdwr(). Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: David Cohen <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20ipc: Enabled ipc support for additional intel platformsKuppuswamy Sathyanarayanan1-0/+24
Enabled ipc support for penwell, clovertrail & tangier platforms. Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: David Cohen <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20ipc: Added platform data structureKuppuswamy Sathyanarayanan1-8/+29
Since the same ipc driver can be used by many platforms, using macros for defining ipc_base and i2c_base addresses is not a scalable approach. So added a platform data structure to pass this information. Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Acked-by: Alan Cox <[email protected]> Cc: David Cohen <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20thinkpad_acpi: Fix build error when CONFIG_SND_MAX_CARDS > 32Takashi Iwai1-1/+6
SNDRV_CARDS can be specified via Kconfig since 3.11 kernel, so this can be over 32bit integer range, which leads to a build error. Cc: <[email protected]> [v3.11+] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20platform: add chrome platform directoryOlof Johansson8-12/+37
It makes sense to split out the Chromebook/Chromebox hardware platform drivers to a separate subdirectory, since some of it will be shared between ARM and x86. This moves over the existing chromeos_laptop driver without making any other changes, and adds appropriate Kconfig entries for the new directory. It also adds a MAINTAINERS entry for the new subdir. Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20hp-wmi: detect "2009 BIOS or later" flag by WMI 0x0d for wireless cmdAlex Hung1-1/+13
Some HP BIOS has dummy WMI 0x05 cmd and it causes wireless set cmd to fail. This patch fixes the problem by detecting "2009 BIOS or later" flag which determines whether WMI 0x1b is supported and is used to replace WMI 0x05. Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-wmi: Add KEY_MICMUTE to bios_to_linux_keycodeAlex Hung1-3/+4
Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20platform:x86: Remove OOM message after input_allocate_deviceJoe Perches8-23/+8
Emitting an OOM message isn't necessary after input_allocate_device as there's a generic OOM and a dump_stack already done. Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20sony-laptop: fixe typos in sony_laptop_input_keycode_mapStephen Gildea1-2/+2
Signed-off-by: Stephen Gildea <[email protected]> Signed-off-by: Mattia Dongili <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20sony-laptop: warn on multiple KBD backlight handlesMattia Dongili1-4/+12
Some BIOS versions/Vaio models apparently ship with two nearly identical functions to handle backlight related controls. The only difference seems to be: If (LEqual (BUF1, 0x40)) { Store (0x40, P80H) Store (BUF2, Local0) - And (Local0, One, Local0) + And (Local0, 0x03, Local0) Store (Local0, ^^H_EC.KLPC) } Avoid erroring out on initialization and messing things up on cleanup for now since we never call into these methods with anything different than 1 or 0. This issue was found on a Sony VPCSE1V9E/BIOS R2087H4. Cc: Marco Krüger <[email protected]> Signed-off-by: Mattia Dongili <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Only enable rfkill functionality on laptops with a hw killswitchHans de Goede1-3/+10
All my testing has been on laptops with a hw killswitch, so to be on the safe side disable rfkill functionality on models without a hw killswitch for now. Once we gather some feedback on laptops without a hw killswitch this decision maybe reconsidered. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Add a force_rfkill module parameterHans de Goede1-1/+5
Setting force_rfkill will cause the dell-laptop rfkill code to skip its whitelist checks, this will allow individual users to override the whitelist, as well as to gather info from users to improve the checks. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Wait less long before updating rfkill after an rfkill keypressHans de Goede1-1/+1
Some time is needed for the BIOS to do its work, but 250ms should be plenty. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Do not skip setting blocked bit rfkill_set while hw-blockedHans de Goede1-3/+2
Instead when hw-blocked always write 1 to the blocked bit for the radio in question. This is necessary to properly set all the blocked bits for hw-switch controlled radios to 1 after power-on and resume. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Sync current block state to BIOS on hw switch changeHans de Goede1-3/+11
This is necessary for 3 reasons: 1) To apply sw_state changes made while hw-blocked 2) To set all the blocked bits for hw-switch controlled radios to 1 when the switch gets changed to off, this is necessary on some models to actually turn the radio status LEDs off. 3) On some models non hw-switch controlled radios will have their block bit cleared (potentially undoing a soft-block) on hw-switch toggle, this restores the sw-block in this case. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Allow changing the sw_state while the radio is blocked by hwHans de Goede1-5/+2
This makes dell-laptop's rfkill code consistent with other drivers which allow sw_state changes while hw blocked. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Don't read-back sw_state on machines with a hardware switchHans de Goede1-1/+4
On machines with a hardware switch, the blocking settings can not be changed through a Fn + wireless-key combo, so there is no reason to read back the blocking state from the BIOS. Reading back is not only not necessary it is actually harmful, since on some machines the blocking state will be cleared to all 0 after a wireless switch toggle, even for radios not controlled by the hw-switch (yeah firmware bugs). This causes "magic" changes to the sw_state. This is inconsistent with other rfkill drivers which preserve the sw_state over a hw kill on / off. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Don't set sw_state from the query callbackHans de Goede1-8/+19
The query callback should only update the hw_state, see the comment in net/rfkill/core.c in rfkill_set_block, which is its only caller. rfkill_set_block will modify the sw_state directly after calling query so calling set_sw_state is an expensive NOP. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Only get status from BIOS once when updatingHans de Goede1-9/+19
Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: If there is no hwswitch, then clear all hw-controlled bitsHans de Goede1-0/+3
To ensure we don't enter any hw-switch related code paths on machines without a hw-switch. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20dell-laptop: Only enable rfkill on LatitudesHans de Goede1-50/+7
The rfkill functionality was removed from the dell-laptop driver because it was causing problems on various non Latitude models, and the blacklist kept growing and growing. In the thread discussing this Dell mentioned that they only QA the rfkill acpi interface on Latitudes and indeed there have been no blacklist entries for Latitudes. Note that the blacklist contained no Vostros either, and most Vostros have a hardware switch too, so we could consider supporting Vostros with a hardware switch too. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-20Revert "dell-laptop: Remove rfkill code"Hans de Goede1-0/+289
Without rfkill functionality in dell-laptop I have the following problems: -If the hardware radio switch is set to disable the radio, then userspace will still think it can use wireless and bluetooth. -The wwan / 3g modem cannot be soft blocked without the dell-laptop rfkill functionality I know the rfkill functionality was removed from the dell-laptop driver because it caused more problems then it fixed, and the blacklist for it was growing out of control. But in the thread discussing this Dell mentioned that they only QA the rfkill acpi interface on Latitudes and indeed there have been no blacklist entries for Latitudes. Therefor I would like to bring the rfkill functionality back only for Latitudes. This patch is a straight-forward revert. The next patch in this set will drop the blacklist and replace it with a Latitude check. This reverts commit a6c2390cd6d2083d27a2359658e08f2d3df375ac. Conflicts: drivers/platform/x86/dell-laptop.c Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2013-11-21powerpc/signals: Mark VSX not saved with small contextsMichael Neuling1-1/+9
The VSX MSR bit in the user context indicates if the context contains VSX state. Currently we set this when the process has touched VSX at any stage. Unfortunately, if the user has not provided enough space to save the VSX state, we can't save it but we currently still set the MSR VSX bit. This patch changes this to clear the MSR VSX bit when the user doesn't provide enough space. This indicates that there is no valid VSX state in the user context. This is needed to support get/set/make/swapcontext for applications that use VSX but only provide a small context. For example, getcontext in glibc provides a smaller context since the VSX registers don't need to be saved over the glibc function call. But since the program calling getcontext may have used VSX, the kernel currently says the VSX state is valid when it's not. If the returned context is then used in setcontext (ie. a small context without VSX but with MSR VSX set), the kernel will refuse the context. This situation has been reported by the glibc community. Based on patch from Carlos O'Donell. Tested-by: Haren Myneni <[email protected]> Signed-off-by: Michael Neuling <[email protected]> Cc: [email protected] Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc/pseries: Fix SMP=n build of rng.cMichael Ellerman1-0/+1
In commit a489043 "Implement arch_get_random_long() based on H_RANDOM" I broke the SMP=n build. We were getting plpar_wrappers.h via spinlock.h which breaks when SMP=n. Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc: Make cpu_to_chip_id() available when SMP=nMichael Ellerman4-17/+22
Up until now we have only used cpu_to_chip_id() in the topology code, which is only used on SMP builds. However my recent commit a4da0d5 "Implement arch_get_random_long/int() for powernv" added a usage when SMP=n, breaking the build. Move cpu_to_chip_id() into prom.c so it is available for SMP=n builds. We would move the extern to prom.h, but that breaks the include in topology.h. Instead we leave it in smp.h, but move it out of the CONFIG_SMP #ifdef. We also need to include asm/smp.h in rng.c, because the linux version skips asm/smp.h on UP. What a mess. Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc/vio: Fix a dma_mask issue of vioLi Zhong1-1/+1
I encountered following issue: [ 0.283035] ibmvscsi 30000015: couldn't initialize event pool [ 5.688822] ibmvscsi: probe of 30000015 failed with error -1 which prevents the storage from being recognized, and the machine from booting. After some digging, it seems that it is caused by commit 4886c399da as dma_mask pointer in viodev->dev is not set, so in dma_set_mask_and_coherent(), dma_set_coherent_mask() is not called because dma_set_mask(), which is dma_set_mask_pSeriesLP() returned EIO. While before the commit, dma_set_coherent_mask() is always called. I tried to replace dma_set_mask_and_coherent() with dma_coerce_mask_and_coherent(), and the machine could boot again. Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc: booke: Fix build failuresAneesh Kumar K.V7-0/+9
arch/powerpc/platforms/wsp/wsp.c: In function ‘wsp_probe_devices’: arch/powerpc/platforms/wsp/wsp.c:76:3: error: implicit declaration of function ‘of_address_to_resource’ [-Werror=implicit-function-declaration] Signed-off-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc: ppc64 address space capped at 32TB, mmap randomisation disabledAnton Blanchard1-1/+1
Commit fba2369e6ceb (mm: use vm_unmapped_area() on powerpc architecture) has a bug in slice_scan_available() where we compare an unsigned long (high_slices) against a shifted int. As a result, comparisons against the top 32 bits of high_slices (representing the top 32TB) always returns 0 and the top of our mmap region is clamped at 32TB This also breaks mmap randomisation since the randomised address is always up near the top of the address space and it gets clamped down to 32TB. Cc: [email protected] # v3.10+ Signed-off-by: Anton Blanchard <[email protected]> Acked-by: Michel Lespinasse <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc: Only print PACATMSCRATCH in oops when TM is activeAnton Blanchard1-1/+2
If TM is not active there is no need to print PACATMSCRATCH so we can save ourselves a line. Signed-off-by: Anton Blanchard <[email protected]> Acked-by: Michael Neuling <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc/pseries: Duplicate dtl entries sometimes sent to userspaceAnton Blanchard1-2/+2
When reading from the dispatch trace log (dtl) userspace interface, I sometimes see duplicate entries. One example: # hexdump -C dtl.out 00000000 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000010 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000020 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 00000030 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000040 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000050 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 The problem is in scan_dispatch_log() where we call dtl_consumer() but bail out before incrementing the index. To fix this I moved dtl_consumer() after the timebase comparison. Signed-off-by: Anton Blanchard <[email protected]> Cc: [email protected] Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc: Remove a few lines of oops outputAnton Blanchard1-9/+9
We waste quite a few lines in our oops output: ... MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28044024 XER: 00000000 SOFTE: 0 CFAR: 0000000000009088 DAR: 000000000000001c, DSISR: 40000000 GPR00: c0000000000c74f0 c00000037cc1b010 c000000000d2bb30 0000000000000000 ... We can do a better job here and remove 3 lines: MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28044024 XER: 00000000 CFAR: 0000000000009088 DAR: 0000000000000010, DSISR: 40000000 SOFTE: 1 GPR00: c0000000000e3d10 c00000037cc2fda0 c000000000d2c3a8 0000000000000001 Also move PACATMSCRATCH up, it doesn't really belong in the stack trace section. Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc: Print DAR and DSISR on machine check oopsesAnton Blanchard1-1/+1
Machine check exceptions set DAR and DSISR, so print them in our oops output. Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2013-11-21powerpc: Fix __get_user_pages_fast() irq handlingHeiko Carstens1-2/+3
__get_user_pages_fast() may be called with interrupts disabled (see e.g. get_futex_key() in kernel/futex.c) and therefore should use local_irq_save() and local_irq_restore() instead of local_irq_disable()/enable(). Signed-off-by: Heiko Carstens <[email protected]> CC: <[email protected]> [v3.12] Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.