aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-04-08arm64: Fix DMA range invalidation for cache line unaligned buffersCatalin Marinas1-4/+11
If the buffer needing cache invalidation for inbound DMA does start or end on a cache line aligned address, we need to use the non-destructive clean&invalidate operation. This issue was introduced by commit 7363590d2c46 (arm64: Implement coherent DMA API based on swiotlb). Signed-off-by: Catalin Marinas <[email protected]> Reported-by: Jon Medhurst (Tixy) <[email protected]>
2014-04-08cpuidle: sysfs: Export target residency informationDaniel Lezcano1-0/+3
From user space, there is no way to know the target residency for each idle state. If we want to write tools to measure the accuracy of the idle state selection from the governor, we need this info. As the exit latency is exported through sysfs, exporting the target residency in the same place makes sense. Signed-off-by: Daniel Lezcano <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-08cpufreq: ppc: Remove duplicate inclusion of fsl_soc.hSachin Kamat1-1/+0
fsl_soc.h was included twice. Signed-off-by: Sachin Kamat <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-08ALSA: hda - Do not assign streams in reverse orderAnssi Hannula1-4/+5
Currently stream numbers are assigned in reverse order. Unfortunately commit 7546abfb8e1f9933b5 ("ALSA: hda - Increment default stream numbers for AMD HDMI controllers") assumed this was not the case (specifically, it had the "old cards had single device only" => "extra unused stream numbers do not matter" assumption), causing non-working audio regressions for AMD Radeon HDMI users. Change the stream numbers to be assigned in forward order. The benefit is that regular audio playback will still work even if the assumed stream count is too high, downside is that a too high stream count may remain hidden. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77002 Reported-by: Christian Güdel <[email protected]> Signed-off-by: Anssi Hannula <[email protected]> Tested-by: Christian Güdel <[email protected]> # 3.14 Cc: Alex Deucher <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-04-08ALSA: hda/realtek - Add eapd shutup to ALC283Kailang Yang1-0/+1
Add eapd shutup function to alc283_shutup. It could avoid pop noise from speaker. Signed-off-by: Kailang Yang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-04-08ALSA: hda/realtek - Change model name alias for ChromeOSKailang Yang1-1/+1
Chrome OS was use model name of alc283-dac-wcaps for loading model as default. Change the model name to same as model name of Chrome OS for future support. Signed-off-by: Kailang Yang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-04-07mmc: sdhci-acpi: Intel SDIO has broken card detectAdrian Hunter1-0/+1
Intel SDIO has broken card detect so add a quirk to reflect that. Signed-off-by: Adrian Hunter <[email protected]> Acked-by: Ulf Hansson <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2014-04-08thermal: rcar-thermal: update thermal zone only when temperature changesPatrick Titiano1-1/+6
Avoid updating the thermal zone in case an IRQ was triggered but the temperature didn't effectively change. Note this is not a driver issue. Below is a captured debug trace illustrating the purpose of this patch: out of 8 thermal zone updates, only 2 are actually necessary. [ 41.120000] rcar_thermal_work(): cctemp=25000 [ 41.120000] rcar_thermal_work(): nctemp=30000 [ 41.120000] rcar_thermal_work(): temp is now 30000C, update thermal zone [ 58.990000] rcar_thermal_work(): cctemp=30000 [ 58.990000] rcar_thermal_work(): nctemp=30000 [ 58.990000] rcar_thermal_work(): same temp, do not update thermal zone [ 59.290000] rcar_thermal_work(): cctemp=30000 [ 59.290000] rcar_thermal_work(): nctemp=30000 [ 59.290000] rcar_thermal_work(): same temp, do not update thermal zone [ 59.590000] rcar_thermal_work(): cctemp=30000 [ 59.590000] rcar_thermal_work(): nctemp=30000 [ 59.590000] rcar_thermal_work(): same temp, do not update thermal zone [ 59.890000] rcar_thermal_work(): cctemp=30000 [ 59.890000] rcar_thermal_work(): nctemp=30000 [ 59.890000] rcar_thermal_work(): same temp, do not update thermal zone [ 60.190000] rcar_thermal_work(): cctemp=30000 [ 60.190000] rcar_thermal_work(): nctemp=30000 [ 60.190000] rcar_thermal_work(): same temp, do not update thermal zone [ 60.490000] rcar_thermal_work(): cctemp=30000 [ 60.490000] rcar_thermal_work(): nctemp=30000 [ 60.490000] rcar_thermal_work(): same temp, do not update thermal zone [ 60.790000] rcar_thermal_work(): cctemp=30000 [ 60.790000] rcar_thermal_work(): nctemp=35000 [ 60.790000] rcar_thermal_work(): temp is now 35000C, update thermal zone I suspect this may be due to sensor sampling accuracy / fluctuation, but no formal proof. Signed-off-by: Patrick Titiano <[email protected]> Acked-by: Kuninori Morimoto <[email protected]> Signed-off-by: Zhang Rui <[email protected]>
2014-04-08thermal: rcar-thermal: fix same mask applied twicePatrick Titiano1-1/+1
Mask is already applied preceding the if statement. Remove the second mask. Signed-off-by: Patrick Titiano <[email protected]> Acked-by: Kuninori Morimoto <[email protected]> Signed-off-by: Zhang Rui <[email protected]>
2014-04-08thermal: ti-soc-thermal: Use SIMPLE_DEV_PM_OPS macroJingoo Han1-4/+2
Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler. Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: Zhang Rui <[email protected]>
2014-04-08thermal: imx: update formula for thermal sensorAnson Huang1-13/+26
Thermal sensor used to need two calibration points which are in fuse map to get a slope for converting thermal sensor's raw data to real temperature in degree C. Due to the chip calibration limitation, hardware team provides an universal formula to get real temperature from internal thermal sensor raw data: Slope = 0.4297157 - (0.0015976 * 25C fuse); Update the formula, as there will be no hot point calibration data in fuse map from now on. Signed-off-by: Anson Huang <[email protected]> Acked-by: Shawn Guo <[email protected]> Signed-off-by: Zhang Rui <[email protected]>
2014-04-07Merge branch 'for_linus' of ↵Linus Torvalds14-83/+51
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull ext3 improvements, cleanups, reiserfs fix from Jan Kara: "various cleanups for ext2, ext3, udf, isofs, a documentation update for quota, and a fix of a race in reiserfs readdir implementation" * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: reiserfs: fix race in readdir ext2: acl: remove unneeded include of linux/capability.h ext3: explicitly remove inode from orphan list after failed direct io fs/isofs/inode.c add __init to init_inodecache() ext3: Speedup WB_SYNC_ALL pass fs/quota/Kconfig: Update filesystems ext3: Update outdated comment before ext3_ordered_writepage() ext3: Update PF_MEMALLOC handling in ext3_write_inode() ext2/3: use prandom_u32() instead of get_random_bytes() ext3: remove an unneeded check in ext3_new_blocks() ext3: remove unneeded check in ext3_ordered_writepage() fs: Mark function as static in ext3/xattr_security.c fs: Mark function as static in ext3/dir.c fs: Mark function as static in ext2/xattr_security.c ext3: Add __init macro to init_inodecache ext2: Add __init macro to init_inodecache udf: Add __init macro to init_inodecache fs: udf: parse_options: blocksize check
2014-04-07Merge branch 'kbuild' of ↵Linus Torvalds5-30/+16
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild changes from Michal Marek: - cleanups in the main Makefiles and Documentation/DocBook/Makefile - make O=... directory is automatically created if needed - mrproper/distclean removes the old include/linux/version.h to make life easier when bisecting across the commit that moved the version.h file * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: kbuild: docbook: fix the include error when executing "make help" kbuild: create a build directory automatically for out-of-tree build kbuild: remove redundant '.*.cmd' pattern from make distclean kbuild: move "quote" to Kbuild.include to be consistent kbuild: docbook: use $(obj) and $(src) rather than specific path kbuild: unconditionally clobber include/linux/version.h on distclean kbuild: docbook: specify KERNELDOC dependency correctly kbuild: docbook: include cmd files more simply kbuild: specify build_docproc as a phony target
2014-04-07Merge tag 'arc-v3.15-rc1' of ↵Linus Torvalds21-115/+114
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC changes from Vineet Gupta: - Support for external initrd from Noam - Fix broken serial console in nsimosci Virtual Platform - Reuse of ENTRY/END assembler macros across hand asm code - Other minor fixes here and there * tag 'arc-v3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: [nsimosci] Unbork console ARC: [nsimosci] Change .dts to use generic 8250 UART ARC: [SMP] General Fixes ARC: Remove unused DT template file ARC: [clockevent] simplify timer ISR ARC: [clockevent] can't be SoC specific ARC: Remove ARC_HAS_COH_RTSC ARC: switch to generic ENTRY/END assembler annotations ARC: support external initrd ARC: add uImage to .gitignore ARC: [arcfpga] Fix __initconst data const-correctness
2014-04-08DRM: armada: fix corruption while loading cursorsRussell King1-0/+1
Loading cursors to the LCD controller's SRAM can be corrupted when the configured pixel clock is relatively slow. This seems to be caused when we write back-to-back to the SRAM registers. There doesn't appear to be any status register we can read to check when an access has completed. Inserting a dummy read between the writes appears to fix the problem. Cc: <[email protected]> # 3.13 Signed-off-by: Russell King <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2014-04-07Merge tag 'stable/for-linus-3.15-tag2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull Xen build fix from David Vrabel: "Fix arm build of drivers/xen/events/ The merge of irq-core-for-linus branch broke it" * tag 'stable/for-linus-3.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: Xen: do hv callback accounting only on x86
2014-04-07Merge branch 'akpm' (incoming from Andrew)Linus Torvalds233-2012/+3714
Merge second patch-bomb from Andrew Morton: - the rest of MM - zram updates - zswap updates - exit - procfs - exec - wait - crash dump - lib/idr - rapidio - adfs, affs, bfs, ufs - cris - Kconfig things - initramfs - small amount of IPC material - percpu enhancements - early ioremap support - various other misc things * emailed patches from Andrew Morton <[email protected]>: (156 commits) MAINTAINERS: update Intel C600 SAS driver maintainers fs/ufs: remove unused ufs_super_block_third pointer fs/ufs: remove unused ufs_super_block_second pointer fs/ufs: remove unused ufs_super_block_first pointer fs/ufs/super.c: add __init to init_inodecache() doc/kernel-parameters.txt: add early_ioremap_debug arm64: add early_ioremap support arm64: initialize pgprot info earlier in boot x86: use generic early_ioremap mm: create generic early_ioremap() support x86/mm: sparse warning fix for early_memremap lglock: map to spinlock when !CONFIG_SMP percpu: add preemption checks to __this_cpu ops vmstat: use raw_cpu_ops to avoid false positives on preemption checks slub: use raw_cpu_inc for incrementing statistics net: replace __this_cpu_inc in route.c with raw_cpu_inc modules: use raw_cpu_write for initialization of per cpu refcount. mm: use raw_cpu ops for determining current NUMA node percpu: add raw_cpu_ops slub: fix leak of 'name' in sysfs_slab_add ...
2014-04-07MAINTAINERS: update Intel C600 SAS driver maintainersLukasz Dorau1-2/+1
Signed-off-by: Lukasz Dorau <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Maciej Patelczyk <[email protected]> Cc: Artur Paszkiewicz <[email protected]> Cc: James Bottomley <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07fs/ufs: remove unused ufs_super_block_third pointerChristian Engelmayer1-2/+0
Pointer 'usb3' to struct ufs_super_block_third acquired via ubh_get_usb_third() is never used in function ufs_read_cylinder_structures(). Thus remove it. Detected by Coverity: CID 139939. Signed-off-by: Christian Engelmayer <[email protected]> Cc: Evgeniy Dushistov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07fs/ufs: remove unused ufs_super_block_second pointerChristian Engelmayer1-2/+0
Pointer 'usb2' to struct ufs_super_block_second acquired via ubh_get_usb_second() is never used in function ufs_statfs(). Thus remove it. Detected by Coverity: CID 139940. Signed-off-by: Christian Engelmayer <[email protected]> Cc: Evgeniy Dushistov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07fs/ufs: remove unused ufs_super_block_first pointerChristian Engelmayer3-18/+0
Remove occurences of unused pointers to struct ufs_super_block_first that were acquired via ubh_get_usb_first(). Detected by Coverity: CID 139929 - CID 139936, CID 139940. Signed-off-by: Christian Engelmayer <[email protected]> Cc: Evgeniy Dushistov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07fs/ufs/super.c: add __init to init_inodecache()Fabian Frederick1-1/+1
init_inodecache is only called by __init init_ufs_fs. Signed-off-by: Fabian Frederick <[email protected]> Cc: Evgeniy Dushistov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07doc/kernel-parameters.txt: add early_ioremap_debugMark Salter1-0/+5
Add description of early_ioremap_debug kernel parameter. Signed-off-by: Mark Salter <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Young <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Will Deacon <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07arm64: add early_ioremap supportMark Salter11-52/+169
Add support for early IO or memory mappings which are needed before the normal ioremap() is usable. This also adds fixmap support for permanent fixed mappings such as that used by the earlyprintk device register region. Signed-off-by: Mark Salter <[email protected]> Acked-by: Catalin Marinas <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Young <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Will Deacon <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07arm64: initialize pgprot info earlier in bootMark Salter3-2/+4
Presently, paging_init() calls init_mem_pgprot() to initialize pgprot values used by macros such as PAGE_KERNEL, PAGE_KERNEL_EXEC, etc. The new fixmap and early_ioremap support also needs to use these macros before paging_init() is called. This patch moves the init_mem_pgprot() call out of paging_init() and into setup_arch() so that pgprot_default gets initialized in time for fixmap and early_ioremap. Signed-off-by: Mark Salter <[email protected]> Acked-by: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Young <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07x86: use generic early_ioremapMark Salter6-240/+13
Move x86 over to the generic early ioremap implementation. Signed-off-by: Mark Salter <[email protected]> Acked-by: H. Peter Anvin <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Young <[email protected]> Cc: Will Deacon <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07mm: create generic early_ioremap() supportMark Salter4-0/+291
This patch creates a generic implementation of early_ioremap() support based on the existing x86 implementation. early_ioremp() is useful for early boot code which needs to temporarily map I/O or memory regions before normal mapping functions such as ioremap() are available. Some architectures have optional MMU. In the no-MMU case, the remap functions simply return the passed in physical address and the unmap functions do nothing. Signed-off-by: Mark Salter <[email protected]> Acked-by: Catalin Marinas <[email protected]> Acked-by: H. Peter Anvin <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Young <[email protected]> Cc: Will Deacon <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07x86/mm: sparse warning fix for early_memremapDave Young2-4/+9
This patch series takes the common bits from the x86 early ioremap implementation and creates a generic implementation which may be used by other architectures. The early ioremap interfaces are intended for situations where boot code needs to make temporary virtual mappings before the normal ioremap interfaces are available. Typically, this means before paging_init() has run. This patch (of 6): There's a lot of sparse warnings for code like below: void *a = early_memremap(phys_addr, size); early_memremap intend to map kernel memory with ioremap facility, the return pointer should be a kernel ram pointer instead of iomem one. For making the function clearer and supressing sparse warnings this patch do below two things: 1. cast to (__force void *) for the return value of early_memremap 2. add early_memunmap function and pass (__force void __iomem *) to iounmap From Boris: "Ingo told me yesterday, it makes sense too. I'd guess we can try it. FWIW, all callers of early_memremap use the memory they get remapped as normal memory so we should be safe" Signed-off-by: Dave Young <[email protected]> Signed-off-by: Mark Salter <[email protected]> Acked-by: H. Peter Anvin <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07lglock: map to spinlock when !CONFIG_SMPJosh Triplett2-1/+18
When the system has only one CPU, lglock is effectively a spinlock; map it directly to spinlock to eliminate the indirection and duplicate code. In addition to removing overhead, this drops 1.6k of code with a defconfig modified to have !CONFIG_SMP, and 1.1k with a minimal config. Signed-off-by: Josh Triplett <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Michal Marek <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: David Howells <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Nick Piggin <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07percpu: add preemption checks to __this_cpu opsChristoph Lameter2-14/+43
We define a check function in order to avoid trouble with the include files. Then the higher level __this_cpu macros are modified to invoke the preemption check. [[email protected]: coding-style fixes] Signed-off-by: Christoph Lameter <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Tejun Heo <[email protected]> Tested-by: Grygorii Strashko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07vmstat: use raw_cpu_ops to avoid false positives on preemption checksChristoph Lameter1-2/+6
vm counters are allowed to be racy. Use raw_cpu_ops to avoid the local_irq_disable overhead and to avoid preemption checks which will be added to the __this_cpu operations. [[email protected]: Add comment. Again.] Signed-off-by: Christoph Lameter <[email protected]> Reported-by: Sergey Senozhatsky <[email protected]> Cc: Dave Chinner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07slub: use raw_cpu_inc for incrementing statisticsChristoph Lameter1-1/+5
Statistics are not critical to the operation of the allocation but should also not cause too much overhead. When __this_cpu_inc is altered to check if preemption is disabled this triggers. Use raw_cpu_inc to avoid the checks. Using this_cpu_ops may cause interrupt disable/enable sequences on various arches which may significantly impact allocator performance. [[email protected]: add comment] Signed-off-by: Christoph Lameter <[email protected]> Cc: Fengguang Wu <[email protected]> Cc: Pekka Enberg <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07net: replace __this_cpu_inc in route.c with raw_cpu_incChristoph Lameter1-1/+1
The RT_CACHE_STAT_INC macro triggers the new preemption checks for __this_cpu ops. I do not see any other synchronization that would allow the use of a __this_cpu operation here however in commit dbd2915ce87e ("[IPV4]: RT_CACHE_STAT_INC() warning fix") Andrew justifies the use of raw_smp_processor_id() here because "we do not care" about races. In the past we agreed that the price of disabling interrupts here to get consistent counters would be too high. These counters may be inaccurate due to race conditions. The use of __this_cpu op improves the situation already from what commit dbd2915ce87e did since the single instruction emitted on x86 does not allow the race to occur anymore. However, non x86 platforms could still experience a race here. Trace: __this_cpu_add operation in preemptible [00000000] code: avahi-daemon/1193 caller is __this_cpu_preempt_check+0x38/0x60 CPU: 1 PID: 1193 Comm: avahi-daemon Tainted: GF 3.12.0-rc4+ #187 Call Trace: check_preemption_disabled+0xec/0x110 __this_cpu_preempt_check+0x38/0x60 __ip_route_output_key+0x575/0x8c0 ip_route_output_flow+0x27/0x70 udp_sendmsg+0x825/0xa20 inet_sendmsg+0x85/0xc0 sock_sendmsg+0x9c/0xd0 ___sys_sendmsg+0x37c/0x390 __sys_sendmsg+0x49/0x90 SyS_sendmsg+0x12/0x20 tracesys+0xe1/0xe6 Signed-off-by: Christoph Lameter <[email protected]> Acked-by: David S. Miller <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07modules: use raw_cpu_write for initialization of per cpu refcount.Christoph Lameter1-1/+1
The initialization of a structure is not subject to synchronization. The use of __this_cpu would trigger a false positive with the additional preemption checks for __this_cpu ops. So simply disable the check through the use of raw_cpu ops. Trace: __this_cpu_write operation in preemptible [00000000] code: modprobe/286 caller is __this_cpu_preempt_check+0x38/0x60 CPU: 3 PID: 286 Comm: modprobe Tainted: GF 3.12.0-rc4+ #187 Call Trace: dump_stack+0x4e/0x82 check_preemption_disabled+0xec/0x110 __this_cpu_preempt_check+0x38/0x60 load_module+0xcfd/0x2650 SyS_init_module+0xa6/0xd0 tracesys+0xe1/0xe6 Signed-off-by: Christoph Lameter <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Rusty Russell <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07mm: use raw_cpu ops for determining current NUMA nodeChristoph Lameter1-2/+2
With the preempt checking logic for __this_cpu_ops we will get false positives from locations in the code that use numa_node_id. Before the __this_cpu ops where introduced there were no checks for preemption present either. smp_raw_processor_id() was used. See http://www.spinics.net/lists/linux-numa/msg00641.html Therefore we need to use raw_cpu_read here to avoid false postives. Note that this issue has been discussed in prior years. If the process changes nodes after retrieving the current numa node then that is acceptable since most uses of numa_node etc are for optimization and not for correctness. There were suggestions to implement a raw_numa_node_id in order to do preempt checks for numa_node_id as well. But I think we better defer that to another patch since that would mean investigating how numa_node_id() is used throughout the kernel which would increase the scope of this patchset significantly. After all preemption was never checked before when numa_node_id() was used. Some sample traces: __this_cpu_read operation in preemptible [00000000] code: login/1456 caller is __this_cpu_preempt_check+0x2b/0x2d CPU: 0 PID: 1456 Comm: login Not tainted 3.12.0-rc4-cl-00062-g2fe80d3-dirty #185 Call Trace: dump_stack+0x4e/0x82 check_preemption_disabled+0xc5/0xe0 __this_cpu_preempt_check+0x2b/0x2d get_task_policy+0x1d/0x49 get_vma_policy+0x14/0x76 alloc_pages_vma+0x35/0xff handle_mm_fault+0x290/0x73b __do_page_fault+0x3fe/0x44d do_page_fault+0x9/0xc page_fault+0x22/0x30 generic_file_aio_read+0x38e/0x624 do_sync_read+0x54/0x73 vfs_read+0x9d/0x12a SyS_read+0x47/0x7e cstar_dispatch+0x7/0x23 caller is __this_cpu_preempt_check+0x2b/0x2d CPU: 0 PID: 1456 Comm: login Not tainted 3.12.0-rc4-cl-00062-g2fe80d3-dirty #185 Call Trace: dump_stack+0x4e/0x82 check_preemption_disabled+0xc5/0xe0 __this_cpu_preempt_check+0x2b/0x2d alloc_pages_current+0x8f/0xbc __page_cache_alloc+0xb/0xd __do_page_cache_readahead+0xf4/0x219 ra_submit+0x1c/0x20 ondemand_readahead+0x28c/0x2b4 page_cache_sync_readahead+0x38/0x3a generic_file_aio_read+0x261/0x624 do_sync_read+0x54/0x73 vfs_read+0x9d/0x12a SyS_read+0x47/0x7e cstar_dispatch+0x7/0x23 Signed-off-by: Christoph Lameter <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Alex Shi <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07percpu: add raw_cpu_opsChristoph Lameter4-198/+260
The kernel has never been audited to ensure that this_cpu operations are consistently used throughout the kernel. The code generated in many places can be improved through the use of this_cpu operations (which uses a segment register for relocation of per cpu offsets instead of performing address calculations). The patch set also addresses various consistency issues in general with the per cpu macros. A. The semantics of __this_cpu_ptr() differs from this_cpu_ptr only because checks are skipped. This is typically shown through a raw_ prefix. So this patch set changes the places where __this_cpu_ptr() is used to raw_cpu_ptr(). B. There has been the long term wish by some that __this_cpu operations would check for preemption. However, there are cases where preemption checks need to be skipped. This patch set adds raw_cpu operations that do not check for preemption and then adds preemption checks to the __this_cpu operations. C. The use of __get_cpu_var is always a reference to a percpu variable that can also be handled via a this_cpu operation. This patch set replaces all uses of __get_cpu_var with this_cpu operations. D. We can then use this_cpu RMW operations in various places replacing sequences of instructions by a single one. E. The use of this_cpu operations throughout will allow other arches than x86 to implement optimized references and RMV operations to work with per cpu local data. F. The use of this_cpu operations opens up the possibility to further optimize code that relies on synchronization through per cpu data. The patch set works in a couple of stages: I. Patch 1 adds the additional raw_cpu operations and raw_cpu_ptr(). Also converts the existing __this_cpu_xx_# primitive in the x86 code to raw_cpu_xx_#. II. Patch 2-4 use the raw_cpu operations in places that would give us false positives once they are enabled. III. Patch 5 adds preemption checks to __this_cpu operations to allow checking if preemption is properly disabled when these functions are used. IV. Patches 6-20 are patches that simply replace uses of __get_cpu_var with this_cpu_ptr. They do not depend on any changes to the percpu code. No preemption tests are skipped if they are applied. V. Patches 21-46 are conversion patches that use this_cpu operations in various kernel subsystems/drivers or arch code. VI. Patches 47/48 (not included in this series) remove no longer used functions (__this_cpu_ptr and __get_cpu_var). These should only be applied after all the conversion patches have made it and after we have done additional passes through the kernel to ensure that none of the uses of these functions remain. This patch (of 46): The patches following this one will add preemption checks to __this_cpu ops so we need to have an alternative way to use this_cpu operations without preemption checks. raw_cpu_ops will be the basis for all other ops since these will be the operations that do not implement any checks. Primitive operations are renamed by this patch from __this_cpu_xxx to raw_cpu_xxxx. Also change the uses of the x86 percpu primitives in preempt.h. These depend directly on asm/percpu.h (header #include nesting issue). Signed-off-by: Peter Zijlstra <[email protected]> Signed-off-by: Christoph Lameter <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Tejun Heo <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Alex Shi <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Bryan Wu <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chris Metcalf <[email protected]> Cc: Daniel Lezcano <[email protected]> Cc: David Daney <[email protected]> Cc: David Miller <[email protected]> Cc: David S. Miller <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: Dipankar Sarma <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Haavard Skinnemoen <[email protected]> Cc: Hans-Christian Egtvedt <[email protected]> Cc: Hedi Berriche <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Helge Deller <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Cc: James Hogan <[email protected]> Cc: Jens Axboe <[email protected]> Cc: John Stultz <[email protected]> Cc: Martin Schwidefsky <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Matt Turner <[email protected]> Cc: Mike Frysinger <[email protected]> Cc: Mike Travis <[email protected]> Cc: Neil Brown <[email protected]> Cc: Nicolas Pitre <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Paul Mundt <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Richard Henderson <[email protected]> Cc: Robert Richter <[email protected]> Cc: Russell King <[email protected]> Cc: Russell King <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tony Luck <[email protected]> Cc: Will Deacon <[email protected]> Cc: Wim Van Sebroeck <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07slub: fix leak of 'name' in sysfs_slab_addDave Jones1-14/+15
The failure paths of sysfs_slab_add don't release the allocation of 'name' made by create_unique_id() a few lines above the context of the diff below. Create a common exit path to make it more obvious what needs freeing. [[email protected]: free the name only if !unmergeable] Signed-off-by: Dave Jones <[email protected]> Signed-off-by: Vladimir Davydov <[email protected]> Cc: Pekka Enberg <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07slub: rework sysfs layout for memcg cachesVladimir Davydov2-1/+28
Currently, we try to arrange sysfs entries for memcg caches in the same manner as for global caches. Apart from turning /sys/kernel/slab into a mess when there are a lot of kmem-active memcgs created, it actually does not work properly - we won't create more than one link to a memcg cache in case its parent is merged with another cache. For instance, if A is a root cache merged with another root cache B, we will have the following sysfs setup: X A -> X B -> X where X is some unique id (see create_unique_id()). Now if memcgs M and N start to allocate from cache A (or B, which is the same), we will get: X X:M X:N A -> X B -> X A:M -> X:M A:N -> X:N Since B is an alias for A, we won't get entries B:M and B:N, which is confusing. It is more logical to have entries for memcg caches under the corresponding root cache's sysfs directory. This would allow us to keep sysfs layout clean, and avoid such inconsistencies like one described above. This patch does the trick. It creates a "cgroup" kset in each root cache kobject to keep its children caches there. Signed-off-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Glauber Costa <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07slub: adjust memcg caches when creating cache aliasVladimir Davydov1-0/+13
Otherwise, kzalloc() called from a memcg won't clear the whole object. Signed-off-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Glauber Costa <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07memcg, slab: do not destroy children caches if parent has aliasesVladimir Davydov3-37/+57
Currently we destroy children caches at the very beginning of kmem_cache_destroy(). This is wrong, because the root cache will not necessarily be destroyed in the end - if it has aliases (refcount > 0), kmem_cache_destroy() will simply decrement its refcount and return. In this case, at best we will get a bunch of warnings in dmesg, like this one: kmem_cache_destroy kmalloc-32:0: Slab cache still has objects CPU: 1 PID: 7139 Comm: modprobe Tainted: G B W 3.13.0+ #117 Call Trace: dump_stack+0x49/0x5b kmem_cache_destroy+0xdf/0xf0 kmem_cache_destroy_memcg_children+0x97/0xc0 kmem_cache_destroy+0xf/0xf0 xfs_mru_cache_uninit+0x21/0x30 [xfs] exit_xfs_fs+0x2e/0xc44 [xfs] SyS_delete_module+0x198/0x1f0 system_call_fastpath+0x16/0x1b At worst - if kmem_cache_destroy() will race with an allocation from a memcg cache - the kernel will panic. This patch fixes this by moving children caches destruction after the check if the cache has aliases. Plus, it forbids destroying a root cache if it still has children caches, because each children cache keeps a reference to its parent. Signed-off-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Glauber Costa <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07memcg, slab: unregister cache from memcg before starting to destroy itVladimir Davydov2-7/+8
Currently, memcg_unregister_cache(), which deletes the cache being destroyed from the memcg_slab_caches list, is called after __kmem_cache_shutdown() (see kmem_cache_destroy()), which starts to destroy the cache. As a result, one can access a partially destroyed cache while traversing a memcg_slab_caches list, which can have deadly consequences (for instance, cache_show() called for each cache on a memcg_slab_caches list from mem_cgroup_slabinfo_read() will dereference pointers to already freed data). To fix this, let's move memcg_unregister_cache() before the cache destruction process beginning, issuing memcg_register_cache() on failure. Signed-off-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Glauber Costa <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07memcg, slab: separate memcg vs root cache creation pathsVladimir Davydov4-95/+111
Memcg-awareness turned kmem_cache_create() into a dirty interweaving of memcg-only and except-for-memcg calls. To clean this up, let's move the code responsible for memcg cache creation to a separate function. Signed-off-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Glauber Costa <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07memcg, slab: cleanup memcg cache creationVladimir Davydov3-51/+52
This patch cleans up the memcg cache creation path as follows: - Move memcg cache name creation to a separate function to be called from kmem_cache_create_memcg(). This allows us to get rid of the mutex protecting the temporary buffer used for the name formatting, because the whole cache creation path is protected by the slab_mutex. - Get rid of memcg_create_kmem_cache(). This function serves as a proxy to kmem_cache_create_memcg(). After separating the cache name creation path, it would be reduced to a function call, so let's inline it. Signed-off-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Glauber Costa <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07memcg, slab: never try to merge memcg cachesVladimir Davydov3-30/+18
When a kmem cache is created (kmem_cache_create_memcg()), we first try to find a compatible cache that already exists and can handle requests from the new cache, i.e. has the same object size, alignment, ctor, etc. If there is such a cache, we do not create any new caches, instead we simply increment the refcount of the cache found and return it. Currently we do this procedure not only when creating root caches, but also for memcg caches. However, there is no point in that, because, as every memcg cache has exactly the same parameters as its parent and cache merging cannot be turned off in runtime (only on boot by passing "slub_nomerge"), the root caches of any two potentially mergeable memcg caches should be merged already, i.e. it must be the same root cache, and therefore we couldn't even get to the memcg cache creation, because it already exists. The only exception is boot caches - they are explicitly forbidden to be merged by setting their refcount to -1. There are currently only two of them - kmem_cache and kmem_cache_node, which are used in slab internals (I do not count kmalloc caches as their refcount is set to 1 immediately after creation). Since they are prevented from merging preliminary I guess we should avoid to merge their children too. So let's remove the useless code responsible for merging memcg caches. Signed-off-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Glauber Costa <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07asm/system.h: um: arch_align_stack() moved to asm/exec.hDavid Howells1-1/+1
arch_align_stack() moved to asm/exec.h, so change the comment referring to asm/system.h which no longer exists. Signed-off-by: David Howells <[email protected]> Cc: Jeff Dike <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07asm/system.h: clean asm/system.h from docsDavid Howells3-9/+2
Clean asm/system.h from docs as nothing should refer to that header anymore. Signed-off-by: David Howells <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07kernel: use macros from compiler.h instead of __attribute__((...))Gideon Israel Dsouza13-21/+34
To increase compiler portability there is <linux/compiler.h> which provides convenience macros for various gcc constructs. Eg: __weak for __attribute__((weak)). I've replaced all instances of gcc attributes with the right macro in the kernel subsystem. Signed-off-by: Gideon Israel Dsouza <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07Kconfig: rename HAS_IOPORT to HAS_IOPORT_MAPUwe Kleine-König41-59/+59
If the renamed symbol is defined lib/iomap.c implements ioport_map and ioport_unmap and currently (nearly) all platforms define the port accessor functions outb/inb and friend unconditionally. So HAS_IOPORT_MAP is the better name for this. Consequently NO_IOPORT is renamed to NO_IOPORT_MAP. The motivation for this change is to reintroduce a symbol HAS_IOPORT that signals if outb/int et al are available. I will address that at least one merge window later though to keep surprises to a minimum and catch new introductions of (HAS|NO)_IOPORT. The changes in this commit were done using: $ git grep -l -E '(NO|HAS)_IOPORT' | xargs perl -p -i -e 's/\b((?:CONFIG_)?(?:NO|HAS)_IOPORT)\b/$1_MAP/' Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07ipc: use device_initcallDavidlohr Bueso3-3/+3
... since __initcall is now deprecated. Signed-off-by: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-04-07ipc/compat.c: remove sc_semopm macroDavidlohr Bueso1-3/+0
This macro appears to have been introduced back in the 2.5 era for semtimedop32 backward compatibility on ia32: https://lkml.org/lkml/2003/4/28/78 Nowadays, this syscall in compat just defaults back to the code found in sem.c, so it is no longer used and can thus be removed: long compat_sys_semtimedop(int semid, struct sembuf __user *tsems, unsigned nsops, const struct compat_timespec __user *timeout) { struct timespec __user *ts64; if (compat_convert_timespec(&ts64, timeout)) return -EFAULT; return sys_semtimedop(semid, tsems, nsops, ts64); } Furthermore, there are no users in compat.c. After this change, kernel builds just fine with both CONFIG_SYSVIPC_COMPAT and CONFIG_SYSVIPC. Signed-off-by: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>