aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-07-24ARM: 8110/1: do CPU-specific init for Broadcom Brahma15 coresMarc Carino1-0/+11
Perform any CPU-specific initialization required on the Broadcom Brahma-15 core. Signed-off-by: Marc Carino <[email protected]> Acked-by: Florian Fainelli <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Russell King <[email protected]>
2014-07-24ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAESteven Capper4-22/+35
For LPAE, we have the following means for encoding writable or dirty ptes: L_PTE_DIRTY L_PTE_RDONLY !pte_dirty && !pte_write 0 1 !pte_dirty && pte_write 0 1 pte_dirty && !pte_write 1 1 pte_dirty && pte_write 1 0 So we can't distinguish between writeable clean ptes and read only ptes. This can cause problems with ptes being incorrectly flagged as read only when they are writeable but not dirty. This patch renumbers L_PTE_RDONLY from AP[2] to a software bit #58, and adds additional logic to set AP[2] whenever the pte is read only or not dirty. That way we can distinguish between clean writeable ptes and read only ptes. HugeTLB pages will use this new logic automatically. We need to add some logic to Transparent HugePages to ensure that they correctly interpret the revised pgprot permissions (L_PTE_RDONLY has moved and no longer matches PMD_SECT_AP2). In the process of revising THP, the names of the PMD software bits have been prefixed with L_ to make them easier to distinguish from their hardware bit counterparts. Signed-off-by: Steve Capper <[email protected]> Reviewed-by: Will Deacon <[email protected]> Signed-off-by: Russell King <[email protected]>
2014-07-24ARM: 8108/1: mm: Introduce {pte,pmd}_isset and {pte,pmd}_isclearSteven Capper2-11/+19
Long descriptors on ARM are 64 bits, and some pte functions such as pte_dirty return a bitwise-and of a flag with the pte value. If the flag to be tested resides in the upper 32 bits of the pte, then we run into the danger of the result being dropped if downcast. For example: gather_stats(page, md, pte_dirty(*pte), 1); where pte_dirty(*pte) is downcast to an int. This patch introduces a new macro pte_isset which performs the bitwise and, then performs a double logical invert (where needed) to ensure predictable downcasting. The logical inverse pte_isclear is also introduced. Equivalent pmd functions for Transparent HugePages have also been added. Signed-off-by: Steve Capper <[email protected]> Reviewed-by: Will Deacon <[email protected]> Signed-off-by: Russell King <[email protected]>
2014-07-24hwmon: (smsc47m192) Fix temperature limit and vrm write operationsGuenter Roeck1-1/+3
Temperature limit clamps are applied after converting the temperature from milli-degrees C to degrees C, so either the clamp limit needs to be specified in degrees C, not milli-degrees C, or clamping must happen before converting to degrees C. Use the latter method to avoid overflows. vrm is an u8, so the written value needs to be limited to [0, 255]. Cc: Axel Lin <[email protected]> Cc: [email protected] Signed-off-by: Guenter Roeck <[email protected]> Reviewed-by: Jean Delvare <[email protected]>
2014-07-24Replace NR_VMX_MSR with its definitionPaolo Bonzini1-4/+4
Using ARRAY_SIZE directly makes it easier to read the code. While touching the code, replace the division by a multiplication in the recently added BUILD_BUG_ON. Signed-off-by: Paolo Bonzini <[email protected]>
2014-07-24KVM: x86: Assertions to check no overrun in MSR listsNadav Amit2-0/+3
Currently there is no check whether shared MSRs list overrun the allocated size which can results in bugs. In addition there is no check that vmx->guest_msrs has sufficient space to accommodate all the VMX msrs. This patch adds the assertions. Signed-off-by: Nadav Amit <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2014-07-24Merge tag 'omap-for-v3.16/fixes-rc6' of ↵Arnd Bergmann3-11/+18
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Merge "Two regression fixes for omaps and one fix for device signaling" from Tony Lindgren: - L2 cache regression fix for a warning about trying to access a read-only register - GPMC ECC software fallback regression fix for omap3 - Fix for dra7 pinctrl pull-up direction that causes signal issues for anybody trying to use the internal pull up or down * tag 'omap-for-v3.16/fixes-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable() pinctrl: dra: dt-bindings: Fix pull enable/disable ARM: OMAP2+: l2c: squelch warning dump on power control setting Signed-off-by: Arnd Bergmann <[email protected]>
2014-07-24KVM: x86: set rflags.rf during fault injectionNadav Amit1-0/+30
x86 does not automatically set rflags.rf during event injection. This patch does partial job, setting rflags.rf upon fault injection. It does not handle the setting of RF upon interrupt injection on rep-string instruction. Signed-off-by: Nadav Amit <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2014-07-24KVM: x86: Setting rflags.rf during rep-string emulationNadav Amit1-1/+5
This patch updates RF for rep-string emulation. The flag is set upon the first iteration, and cleared after the last (if emulated). It is intended to make sure that if a trap (in future data/io #DB emulation) or interrupt is delivered to the guest during the rep-string instruction, RF will be set correctly. RF affects whether instruction breakpoint in the guest is masked. Signed-off-by: Nadav Amit <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2014-07-24Merge tag 'renesas-fixes2-for-v3.16' of ↵Arnd Bergmann1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes Merge "Second Round of Renesas ARM Based SoC Fixes for v3.16" from Simon Horman * Fix SD2CKCR register address of r8a7791 (R-Car M2) SoC This corrects a bug introduced in v3.14 by 59e79895b9589286 ("ARM: shmobile: r8a7791: Add clocks"). However, it does not manifest in mainline code until SDHI devices were enabled on the Koelsch board in v3.15 by 2c60a7df72711fb8 ("ARM: shmobile: Add SDHI devices for Koelsch DTS"). It also manifests on the Henninger board when SDHI devices were enabled in v3.16-rc1 by 1299df03d7191ab4 ("ARM: shmobile: henninger: add SDHI0/2 DT support") * tag 'renesas-fixes2-for-v3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: shmobile: r8a7791: Fix SD2CKCR register address Signed-off-by: Arnd Bergmann <[email protected]>
2014-07-24fs: umount on symlink leaks mnt countVasily Averin1-1/+2
Currently umount on symlink blocks following umount: /vz is separate mount # ls /vz/ -al | grep test drwxr-xr-x. 2 root root 4096 Jul 19 01:14 testdir lrwxrwxrwx. 1 root root 11 Jul 19 01:16 testlink -> /vz/testdir # umount -l /vz/testlink umount: /vz/testlink: not mounted (expected) # lsof /vz # umount /vz umount: /vz: device is busy. (unexpected) In this case mountpoint_last() gets an extra refcount on path->mnt Signed-off-by: Vasily Averin <[email protected]> Acked-by: Ian Kent <[email protected]> Acked-by: Jeff Layton <[email protected]> Cc: [email protected] Signed-off-by: Christoph Hellwig <[email protected]>
2014-07-24direct-io: fix uninitialized warning in do_direct_IO()Boaz Harrosh1-7/+7
The following warnings: fs/direct-io.c: In function ‘__blockdev_direct_IO’: fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized] fs/direct-io.c:913:16: note: ‘to’ was declared here fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized] fs/direct-io.c:913:10: note: ‘from’ was declared here are false positive because dio_get_page() either fails, or sets both 'from' and 'to'. Paul Bolle said ... Maybe it's better to move initializing "to" and "from" out of dio_get_page(). That _might_ make it easier for both the the reader and the compiler to understand what's going on. Something like this: Christoph Hellwig said ... The fix of moving the code definitively looks nicer, while I think uninitialized_var is horrible wart that won't get anywhere near my code. Boaz Harrosh: I agree with Christoph and Paul Signed-off-by: Boaz Harrosh <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2014-07-24sched_clock: Avoid corrupting hrtimer tree during suspendStephen Boyd1-1/+3
During suspend we call sched_clock_poll() to update the epoch and accumulated time and reprogram the sched_clock_timer to fire before the next wrap-around time. Unfortunately, sched_clock_poll() doesn't restart the timer, instead it relies on the hrtimer layer to do that and during suspend we aren't calling that function from the hrtimer layer. Instead, we're reprogramming the expires time while the hrtimer is enqueued, which can cause the hrtimer tree to be corrupted. Furthermore, we restart the timer during suspend but we update the epoch during resume which seems counter-intuitive. Let's fix this by saving the accumulated state and canceling the timer during suspend. On resume we can update the epoch and restart the timer similar to what we would do if we were starting the clock for the first time. Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer" Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: John Stultz <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: Ingo Molnar <[email protected]> Cc: stable <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2014-07-24arm64: Fix barriers used for page table modificationsCatalin Marinas3-12/+17
The architecture specification states that both DSB and ISB are required between page table modifications and subsequent memory accesses using the corresponding virtual address. When TLB invalidation takes place, the tlb_flush_* functions already have the necessary barriers. However, there are other functions like create_mapping() for which this is not the case. The patch adds the DSB+ISB instructions in the set_pte() function for valid kernel mappings. The invalid pte case is handled by tlb_flush_* and the user mappings in general have a corresponding update_mmu_cache() call containing a DSB. Even when update_mmu_cache() isn't called, the kernel can still cope with an unlikely spurious page fault by re-executing the instruction. In addition, the set_pmd, set_pud() functions gain an ISB for architecture compliance when block mappings are created. Signed-off-by: Catalin Marinas <[email protected]> Reported-by: Leif Lindholm <[email protected]> Acked-by: Steve Capper <[email protected]> Cc: Will Deacon <[email protected]> Cc: <[email protected]>
2014-07-24crypto: ccp - Remove "select OF" from KconfigTom Lendacky1-1/+0
The addition of the "select OF if ARM64" has led to a Kconfig recursive dependency error when "make ARCH=sh rsk7269_defconfig" was run. Since OF is selected by ARM64 and the of_property_read_bool is defined no matter what, delete the Kconfig line that selects OF. Reported-by: kbuild test robot <[email protected]> Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2014-07-23Merge branch 'master' of ↵David S. Miller2-4/+5
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2014-07-23 Just two fixes this time, both are stable candidates. 1) Fix the dst_entry refcount on socket policy usage. 2) Fix a wrong SPI check that prevents AH SAs from getting installed, dependent on the SPI. From Tobias Brunner. ==================== Signed-off-by: David S. Miller <[email protected]>
2014-07-23Merge branch 'clk-rockchip' into clk-nextMike Turquette16-15/+3338
2014-07-23firmware loader: Fix _request_firmware_load() return val for fw load abortShuah Khan1-1/+3
_request_firmware_load() returns -ENOMEM when fw load is aborted after timeout. Call is_fw_load_aborted() to check if fw load is aborted and if true return -EAGAIN. Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23platform: Remove most references to platform_bus devicePawel Moll19-95/+79
A number of board files in arch/arm and arch/unicore32 explicitly reference platform_bus device as a parent for new platform devices. This is unnecessary, as platform device API guarantees that devices with NULL parent are going to by adopted by the mentioned "root" device. This patch removes or replaces with NULL such references. Signed-off-by: Pawel Moll <[email protected]> Acked-by: Olof Johansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23staging: keucr: remove driverKristina Martšenko23-5367/+3
The driver hasn't been fully cleaned up and it doesn't look like anyone is working on it anymore (including the original author). So remove the driver and all references to it. If someone wants to finish cleaning the driver up and moving it out of staging, this commit can be reverted. Signed-off-by: Kristina Martšenko <[email protected]> Cc: Cho, Yu-Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23tty: serial: msm: Make of_device_id array constKiran Padwal1-1/+1
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Kiran Padwal <[email protected]> Acked-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23tty/n_gsm.c: get gsm->num after gsm_activate_muxxinhui.pan1-2/+2
gsm->num is the index of gsm_mux[], it's invalid before calling gsm_activate_mux. Signed-off-by: xinhui.pan <[email protected]> Acked-by: Alan Cox <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23serial/core: Fix too big allocation for attribute memberYoshihiro YUNOMAE1-1/+1
Current code allocates too much data for tty_groups member of uart_port struct, so fix it. Signed-off-by: Yoshihiro YUNOMAE <[email protected]> Reported-by: Dan Carpenter <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23staging: frontier: remove driverKristina Martšenko10-1971/+0
The driver hasn't been cleaned up and it doesn't look like anyone is working on it anymore (including the original author). So remove the driver from the kernel. If someone wants to work on cleaning it up and moving it out of staging, this commit can be reverted. Signed-off-by: Kristina Martšenko <[email protected]> Cc: David Täht <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23staging: ced1401: remove driverKristina Martšenko13-7734/+0
The state of the driver hasn't improved much since it was added to staging, and no one with the hardware is currently working on it, so remove it. This commit can be reverted if someone wants to clean the driver up and move it to its proper place in the kernel. Signed-off-by: Kristina Martšenko <[email protected]> Cc: Greg Smith <[email protected]> Cc: Alois Schlögl <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23Staging: bcm: nvm.c: Don't pass the indexMatthias Beyer1-4/+3
The variable 'i' does not need to be passed, as we set it to 0 (zero) anyways when starting the iteration here. Suggested-by: Dan Carpenter <[email protected]> Signed-off-by: Matthias Beyer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23Staging: bcm: nvm.c: Fixed variable typeMatthias Beyer1-1/+1
The variable type of the local variable 'j' should be 'int' instead of 'unsigned int'. Suggested-by: Dan Carpenter <[email protected]> Signed-off-by: Matthias Beyer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23staging:bcm:Transmit.c:coding style:line over 80 charSudip Mukherjee1-3/+7
Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23staging: vme: removed useless breaks in vme_user.cTom Jorquera1-4/+0
vme_user.c contained unnecessary breaks after gotos, which increased code size and caused code style warning. This is now fixed. Signed-off-by: Tom Jorquera <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23drivers/staging/bcm/Misc.c: fix a checkAndrey Utkin1-1/+1
The issue was reported by static analysis. The value holding flags was &-ed with 0x02, being compared to 0x01 (TRUE) after that. Such comparsion is always false. Resolution: drop the comparsion to TRUE in the condition. &-ing with 0x02 is right, according to result variable name (reporting_mode) and description in drivers/staging/bcm/target_params.h ("bit 1 = 1: CINR reporting in Idlemode Msg"). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80801 Reported-by: David Binderman <[email protected]> Signed-off-by: Andrey Utkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23staging/goldfish/goldfish_audio: fix a sparse warningRobin Schroer1-1/+1
Fix a pointer check to use NULL instead of 0 Warning: drivers/staging/goldfish/goldfish_audio.c:300:34: warning: Using plain integer as NULL pointer Signed-off-by: Robin Schroer <[email protected]> Acked-by: Alan Cox <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23Merge branch 'for-3.16' of git://linux-nfs.org/~bfields/linuxLinus Torvalds1-1/+3
Pull nfsd bugfix from Bruce Fields: "Another regression from the xdr encoding rewrite" * 'for-3.16' of git://linux-nfs.org/~bfields/linux: NFSD: Fix crash encoding lock reply on 32-bit
2014-07-23Merge tag 'arm64-fixes' of ↵Linus Torvalds1-4/+13
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Fix arm64 regression introduced by limiting the CMA buffer to ZONE_DMA on platforms where RAM starts above 4GB (and ZONE_DMA becoming 0)" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Create non-empty ZONE_DMA when DRAM starts above 4GB
2014-07-23Merge tag 'xtensa-next-20140721' of git://github.com/czankel/xtensa-linuxLinus Torvalds3-25/+139
Pull Xtensa fixes from Chris Zankel: - resolve FIXMEs in double exception handler for window overflow. This fix makes native building of linux on xtensa host possible; - fix sysmem region removal issue introduced in 3.15. * tag 'xtensa-next-20140721' of git://github.com/czankel/xtensa-linux: xtensa: fix sysmem reservation at the end of existing block xtensa: add fixup for double exception raised in window overflow
2014-07-23Merge tag 'pinctrl-v3.16-3' of ↵Linus Torvalds3-1/+8
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Here are three pin control fixes for the v3.16 series. Sorry that some of these arrive late, the summer heat in Sweden makes me slow. - an IRQ handling fix for the STi driver, also for stable - another IRQ fix for the RCAR GPIO driver - a MAINTAINERS entry" * tag 'pinctrl-v3.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: gpio: rcar: Add support for DT IRQ flags MAINTAINERS: Add entry for the Renesas pin controller driver pinctrl: st: Fix irqmux handler
2014-07-23Merge branch 'for-3.16-fixes' of ↵Linus Torvalds2-12/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata Pull libata regression fix from Tejun Heo: "The last libata/for-3.16-fixes pull contained a regression introduced by 1871ee134b73 ("libata: support the ata host which implements a queue depth less than 32") which in turn was a fix for a regression introduced earlier while changing queue tag order to accomodate hard drives which perform poorly if tags are not allocated in circular order (ugh...). The regression happens only for SAS controllers making use of libata to serve ATA devices. They don't fill an ata_host field which is used by the new tag allocation function leading to NULL dereference. This patch adds a new intermediate field ata_host->n_tags which is initialized for both SAS and !SAS cases to fix the issue" * 'for-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: libata: introduce ata_host->n_tags to avoid oops on SAS controllers
2014-07-23drivers/misc/ti-st: Load firmware from ti-connectivity directory.Enric Balletbo i Serra1-2/+3
Looks like the default location for TI firmware is inside the ti-connectivity directory, to be coherent with other firmware request used by TI drivers, load the TIInit firmware from this directory instead of /lib/firmware directly. Signed-off-by: Enric Balletbo i Serra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-23ring-buffer: Use rb_page_size() instead of open coded head_page sizeSteven Rostedt (Red Hat)1-1/+1
There's a helper function to get a ring buffer page size (the number of bytes of data recorded on the page), called rb_page_size(). Use that instead of open coding it. Signed-off-by: Steven Rostedt <[email protected]>
2014-07-23Merge branch 'for-linus' of ↵Linus Torvalds8-27/+41
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input layer fixes from Dmitry Torokhov: "A few fixups for the input subsystem" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: document INPUT_PROP_TOPBUTTONPAD Input: fix defuzzing logic Input: sirfsoc-onkey - fix GPL v2 license string typo Input: st-keyscan - fix 'defined but not used' compiler warnings Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531) Input: i8042 - add Acer Aspire 5710 to nomux blacklist Input: ti_am335x_tsc - warn about incorrect spelling Input: wacom - cleanup multitouch code when touch_max is 2
2014-07-23Merge branch 'merge' of ↵Linus Torvalds7-7/+31
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull powerpc fixes from Ben Herrenschmidt: "Here is a handful of powerpc fixes for 3.16. They are all pretty simple and self contained and should still make this release" * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc: use _GLOBAL_TOC for memmove powerpc/pseries: dynamically added OF nodes need to call of_node_init powerpc: subpage_protect: Increase the array size to take care of 64TB powerpc: Fix bugs in emulate_step() powerpc: Disable doorbells on Power8 DD1.x
2014-07-23Merge tag 'urgent-slab-fix' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull slab fix from Mike Snitzer: "This fixes the broken duplicate slab name check in kmem_cache_sanity_check() that has been repeatedly reported (as recently as today against Fedora rawhide). Pekka seemed to have it staged for a late 3.15-rc in his 'slab/urgent' branch but never sent a pull request, see: https://lkml.org/lkml/2014/5/23/648" * tag 'urgent-slab-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: slab_common: fix the check for duplicate slab names
2014-07-23Merge branch 'akpm' (patches from Andrew Morton)Linus Torvalds11-55/+117
Merge fixes from Andrew Morton: "10 fixes" * emailed patches from Andrew Morton <[email protected]>: mm: hugetlb: fix copy_hugetlb_page_range() simple_xattr: permit 0-size extended attributes mm/fs: fix pessimization in hole-punching pagecache shmem: fix splicing from a hole while it's punched shmem: fix faulting into a hole, not taking i_mutex mm: do not call do_fault_around for non-linear fault sh: also try passing -m4-nofpu for SH2A builds zram: avoid lockdep splat by revalidate_disk mm/rmap.c: fix pgoff calculation to handle hugepage correctly coredump: fix the setting of PF_DUMPCORE
2014-07-23mm: hugetlb: fix copy_hugetlb_page_range()Naoya Horiguchi1-0/+1
Commit 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry") changed the order of huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage in some workloads like hugepage-backed heap allocation via libhugetlbfs. This patch fixes it. The test program for the problem is shown below: $ cat heap.c #include <unistd.h> #include <stdlib.h> #include <string.h> #define HPS 0x200000 int main() { int i; char *p = malloc(HPS); memset(p, '1', HPS); for (i = 0; i < 5; i++) { if (!fork()) { memset(p, '2', HPS); p = malloc(HPS); memset(p, '3', HPS); free(p); return 0; } } sleep(1); free(p); return 0; } $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap ./heap Fixes 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry"), so is applicable to -stable kernels which include it. Signed-off-by: Naoya Horiguchi <[email protected]> Reported-by: Guillaume Morin <[email protected]> Suggested-by: Guillaume Morin <[email protected]> Acked-by: Hugh Dickins <[email protected]> Cc: <[email protected]> [2.6.37+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-07-23simple_xattr: permit 0-size extended attributesHugh Dickins1-1/+1
If a filesystem uses simple_xattr to support user extended attributes, LTP setxattr01 and xfstests generic/062 fail with "Cannot allocate memory": simple_xattr_alloc()'s wrap-around test mistakenly excludes values of zero size. Fix that off-by-one (but apparently no filesystem needs them yet). Signed-off-by: Hugh Dickins <[email protected]> Cc: Al Viro <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Aristeu Rozanski <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-07-23mm/fs: fix pessimization in hole-punching pagecacheHugh Dickins1-3/+8
I wanted to revert my v3.1 commit d0823576bf4b ("mm: pincer in truncate_inode_pages_range"), to keep truncate_inode_pages_range() in synch with shmem_undo_range(); but have stepped back - a change to hole-punching in truncate_inode_pages_range() is a change to hole-punching in every filesystem (except tmpfs) that supports it. If there's a logical proof why no filesystem can depend for its own correctness on the pincer guarantee in truncate_inode_pages_range() - an instant when the entire hole is removed from pagecache - then let's revisit later. But the evidence is that only tmpfs suffered from the livelock, and we have no intention of extending hole-punch to ramfs. So for now just add a few comments (to match or differ from those in shmem_undo_range()), and fix one silliness noticed in d0823576bf4b... Its "index == start" addition to the hole-punch termination test was incomplete: it opened a way for the end condition to be missed, and the loop go on looking through the radix_tree, all the way to end of file. Fix that pessimization by resetting index when detected in inner loop. Note that it's actually hard to hit this case, without the obsessive concurrent faulting that trinity does: normally all pages are removed in the initial trylock_page() pass, and this loop finds nothing to do. I had to "#if 0" out the initial pass to reproduce bug and test fix. Signed-off-by: Hugh Dickins <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Lukas Czerner <[email protected]> Cc: Dave Jones <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-07-23shmem: fix splicing from a hole while it's punchedHugh Dickins1-9/+15
shmem_fault() is the actual culprit in trinity's hole-punch starvation, and the most significant cause of such problems: since a page faulted is one that then appears page_mapped(), needing unmap_mapping_range() and i_mmap_mutex to be unmapped again. But it is not the only way in which a page can be brought into a hole in the radix_tree while that hole is being punched; and Vlastimil's testing implies that if enough other processors are busy filling in the hole, then shmem_undo_range() can be kept from completing indefinitely. shmem_file_splice_read() is the main other user of SGP_CACHE, which can instantiate shmem pagecache pages in the read-only case (without holding i_mutex, so perhaps concurrently with a hole-punch). Probably it's silly not to use SGP_READ already (using the ZERO_PAGE for holes): which ought to be safe, but might bring surprises - not a change to be rushed. shmem_read_mapping_page_gfp() is an internal interface used by drivers/gpu/drm GEM (and next by uprobes): it should be okay. And shmem_file_read_iter() uses the SGP_DIRTY variant of SGP_CACHE, when called internally by the kernel (perhaps for a stacking filesystem, which might rely on holes to be reserved): it's unclear whether it could be provoked to keep hole-punch busy or not. We could apply the same umbrella as now used in shmem_fault() to shmem_file_splice_read() and the others; but it looks ugly, and use over a range raises questions - should it actually be per page? can these get starved themselves? The origin of this part of the problem is my v3.1 commit d0823576bf4b ("mm: pincer in truncate_inode_pages_range"), once it was duplicated into shmem.c. It seemed like a nice idea at the time, to ensure (barring RCU lookup fuzziness) that there's an instant when the entire hole is empty; but the indefinitely repeated scans to ensure that make it vulnerable. Revert that "enhancement" to hole-punch from shmem_undo_range(), but retain the unproblematic rescanning when it's truncating; add a couple of comments there. Remove the "indices[0] >= end" test: that is now handled satisfactorily by the inner loop, and mem_cgroup_uncharge_start()/end() are too light to be worth avoiding here. But if we do not always loop indefinitely, we do need to handle the case of swap swizzled back to page before shmem_free_swap() gets it: add a retry for that case, as suggested by Konstantin Khlebnikov; and for the case of page swizzled back to swap, as suggested by Johannes Weiner. Signed-off-by: Hugh Dickins <[email protected]> Reported-by: Sasha Levin <[email protected]> Suggested-by: Vlastimil Babka <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Lukas Czerner <[email protected]> Cc: Dave Jones <[email protected]> Cc: <[email protected]> [3.1+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-07-23shmem: fix faulting into a hole, not taking i_mutexHugh Dickins1-26/+52
Commit f00cdc6df7d7 ("shmem: fix faulting into a hole while it's punched") was buggy: Sasha sent a lockdep report to remind us that grabbing i_mutex in the fault path is a no-no (write syscall may already hold i_mutex while faulting user buffer). We tried a completely different approach (see following patch) but that proved inadequate: good enough for a rational workload, but not good enough against trinity - which forks off so many mappings of the object that contention on i_mmap_mutex while hole-puncher holds i_mutex builds into serious starvation when concurrent faults force the puncher to fall back to single-page unmap_mapping_range() searches of the i_mmap tree. So return to the original umbrella approach, but keep away from i_mutex this time. We really don't want to bloat every shmem inode with a new mutex or completion, just to protect this unlikely case from trinity. So extend the original with wait_queue_head on stack at the hole-punch end, and wait_queue item on the stack at the fault end. This involves further use of i_lock to guard against the races: lockdep has been happy so far, and I see fs/inode.c:unlock_new_inode() holds i_lock around wake_up_bit(), which is comparable to what we do here. i_lock is more convenient, but we could switch to shmem's info->lock. This issue has been tagged with CVE-2014-4171, which will require commit f00cdc6df7d7 and this and the following patch to be backported: we suggest to 3.1+, though in fact the trinity forkbomb effect might go back as far as 2.6.16, when madvise(,,MADV_REMOVE) came in - or might not, since much has changed, with i_mmap_mutex a spinlock before 3.0. Anyone running trinity on 3.0 and earlier? I don't think we need care. Signed-off-by: Hugh Dickins <[email protected]> Reported-by: Sasha Levin <[email protected]> Tested-by: Sasha Levin <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Lukas Czerner <[email protected]> Cc: Dave Jones <[email protected]> Cc: <[email protected]> [3.1+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-07-23mm: do not call do_fault_around for non-linear faultKonstantin Khlebnikov1-1/+2
Ingo Korb reported that "repeated mapping of the same file on tmpfs using remap_file_pages sometimes triggers a BUG at mm/filemap.c:202 when the process exits". He bisected the bug to d7c1755179b8 ("mm: implement ->map_pages for shmem/tmpfs"), although the bug was actually added by commit 8c6e50b0290c ("mm: introduce vm_ops->map_pages()"). The problem is caused by calling do_fault_around for a _non-linear_ fault. In this case pgoff is shifted and might become negative during calculation. Faulting around non-linear page-fault makes no sense and breaks the logic in do_fault_around because pgoff is shifted. Signed-off-by: Konstantin Khlebnikov <[email protected]> Reported-by: Ingo Korb <[email protected]> Tested-by: Ingo Korb <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Dave Jones <[email protected]> Cc: Ning Qu <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: <[email protected]> [3.15.x] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-07-23sh: also try passing -m4-nofpu for SH2A buildsGeert Uytterhoeven1-1/+2
When compiling a SH2A kernel (e.g. se7206_defconfig or rsk7203_defconfig) using sh4-linux-gcc, linking fails with: net/built-in.o: In function `__sk_run_filter': net/core/filter.c:566: undefined reference to `__fpscr_values' net/core/filter.c:269: undefined reference to `__fpscr_values' ... net/built-in.o:net/core/filter.c:580: more undefined references to `__fpscr_values' follow This happens because sh4-linux-gcc doesn't support the "-m2a-nofpu", which is thus filtered out by "$(call cc-option, ...)". As compiling using sh4-linux-gcc is useful for compile coverage, also try passing "-m4-nofpu" (which is presumably filtered out when using a real sh2a-linux toolchain) to disable the generation of FPU instructions and references to __fpscr_values[]. Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Tony Breeds <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Fengguang Wu <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Magnus Damm <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-07-23zram: avoid lockdep splat by revalidate_diskMinchan Kim1-4/+18
Sasha reported lockdep warning [1] introduced by [2]. It could be fixed by doing disk revalidation out of the init_lock. It's okay because disk capacity change is protected by init_lock so that revalidate_disk always sees up-to-date value so there is no race. [1] https://lkml.org/lkml/2014/7/3/735 [2] zram: revalidate disk after capacity change Fixes 2e32baea46ce ("zram: revalidate disk after capacity change"). Signed-off-by: Minchan Kim <[email protected]> Reported-by: Sasha Levin <[email protected]> Cc: "Alexander E. Patrakov" <[email protected]> Cc: Nitin Gupta <[email protected]> Cc: Jerome Marchand <[email protected]> Cc: Sergey Senozhatsky <[email protected]> CC: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>