summaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel/kgdb.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2016-04-06i40iw: avoid potential uninitialized variable useArnd Bergmann1-7/+3
gcc finds that the i40iw_make_cm_node() function in the recently added i40iw driver uses an uninitilized variable as an index into an array if CONFIG_IPV6 is disabled and the driver uses IPv6 mode: drivers/infiniband/hw/i40iw/i40iw_cm.c: In function 'i40iw_make_cm_node': drivers/infiniband/hw/i40iw/i40iw_cm.c:2206:52: error: 'arpindex' may be used uninitialized in this function [-Werror=maybe-uninitialized] ether_addr_copy(cm_node->rem_mac, iwdev->arp_table[arpindex].mac_addr); As far as I can tell, this code path can not be used because the ipv4 variable is always set with CONFIG_IPV6 is disabled, but it's better to be sure and prevent the undefined behavior, as well as shut up that warning in a proper way. This adds an 'else' clause for the case we get the warning about, causing the function to return an error in a controlled way. To avoid adding extra mess with combined io()/#ifdef clauses, I'm also converting the existing #ifdef into a more readable if(IS_ENABLED()) check. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: f27b4746f378 ("i40iw: add connection management code") Acked-by: Mustafa Ismail <Mustafa.ismail@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2016-04-06IB/mlx5: fix VFs callback function prototypesArnd Bergmann1-9/+9
The previous patch that added a couple of callback functions put the declarations inside of an #ifdef CONFIG_INFINIBAND_ON_DEMAND_PAGING, which causes the build to fail if that option is disabled: drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_add': drivers/infiniband/hw/mlx5/main.c:2358:31: error: 'mlx5_ib_get_vf_config' undeclared (first use in this function) This moves the four declarations below the #ifdef section so they are always available. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: eff901d30e6c ("IB/mlx5: Implement callbacks for manipulating VFs") Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Eli Cohen <eli@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2016-04-05compiler-gcc: disable -ftracer for __noclone functionsPaolo Bonzini1-1/+1
-ftracer can duplicate asm blocks causing compilation to fail in noclone functions. For example, KVM declares a global variable in an asm like asm("2: ... \n .pushsection data \n .global vmx_return \n vmx_return: .long 2b"); and -ftracer causes a double declaration. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable@vger.kernel.org Cc: kvm@vger.kernel.org Reported-by: Linda Walsh <lkml@tlinx.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-04-05kvm: x86: make lapic hrtimer pinnedLuiz Capitulino1-4/+4
When a vCPU runs on a nohz_full core, the hrtimer used by the lapic emulation code can be migrated to another core. When this happens, it's possible to observe milisecond latency when delivering timer IRQs to KVM guests. The huge latency is mainly due to the fact that apic_timer_fn() expects to run during a kvm exit. It sets KVM_REQ_PENDING_TIMER and let it be handled on kvm entry. However, if the timer fires on a different core, we have to wait until the next kvm exit for the guest to see KVM_REQ_PENDING_TIMER set. This problem became visible after commit 9642d18ee. This commit changed the timer migration code to always attempt to migrate timers away from nohz_full cores. While it's discussable if this is correct/desirable (I don't think it is), it's clear that the lapic emulation code has a requirement on firing the hrtimer in the same core where it was started. This is achieved by making the hrtimer pinned. Lastly, note that KVM has code to migrate timers when a vCPU is scheduled to run in different core. However, this forced migration may fail. When this happens, we can have the same problem. If we want 100% correctness, we'll have to modify apic_timer_fn() to cause a kvm exit when it runs on a different core than the vCPU. Not sure if this is possible. Here's a reproducer for the issue being fixed: 1. Set all cores but core0 to be nohz_full cores 2. Start a guest with a single vCPU 3. Trace apic_timer_fn() and kvm_inject_apic_timer_irqs() You'll see that apic_timer_fn() will run in core0 while kvm_inject_apic_timer_irqs() runs in a different core. If you get both on core0, try running a program that takes 100% of the CPU and pin it to core0 to force the vCPU out. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-04-05s390/mm/kvm: fix mis-merge in gmap handlingChristian Borntraeger1-2/+2
commit 1e133ab296f3 ("s390/mm: split arch/s390/mm/pgtable.c") dropped some changes from commit a3a92c31bf0b ("KVM: s390: fix mismatch between user and in-kernel guest limit") - this breaks KVM for some memory sizes (kvm-s390: failed to commit memory region) like exactly 2GB. Cc: Dominik Dingel <dingel@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-04-04gma500: remove annoying deprecation warningLinus Torvalds1-1/+1
In commit e45708976aea ("drm/dp-helper: Move the legacy helpers to gma500") the legacy i2c helpers were moved to the only remaining user of them, the gma500 driver. Together with that move, i2c_dp_aux_add_bus() was marked deprecated and started warning about its remaining use. It's now been a year and a half of annoying warning, and apparently nobody cares enough about gma500 to try to move it along to the more modern models. Get rid of the warning - if even the gma500 people don't care enough, then they should certainly not spam other innocent developers with a warning that might hide other, much more real issues. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-04mm: drop PAGE_CACHE_* and page_cache_{get,release} definitionKirill A. Shutemov1-15/+0
All users gone. We can remove these macros. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-04mm, fs: remove remaining PAGE_CACHE_* and page_cache_{get,release} usageKirill A. Shutemov65-135/+120
Mostly direct substitution with occasional adjustment or removing outdated comments. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-04mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macrosKirill A. Shutemov381-2721/+2722
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago with promise that one day it will be possible to implement page cache with bigger chunks than PAGE_SIZE. This promise never materialized. And unlikely will. We have many places where PAGE_CACHE_SIZE assumed to be equal to PAGE_SIZE. And it's constant source of confusion on whether PAGE_CACHE_* or PAGE_* constant should be used in a particular case, especially on the border between fs and mm. Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much breakage to be doable. Let's stop pretending that pages in page cache are special. They are not. The changes are pretty straight-forward: - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN}; - page_cache_get() -> get_page(); - page_cache_release() -> put_page(); This patch contains automated changes generated with coccinelle using script below. For some reason, coccinelle doesn't patch header files. I've called spatch for them manually. The only adjustment after coccinelle is revert of changes to PAGE_CAHCE_ALIGN definition: we are going to drop it later. There are few places in the code where coccinelle didn't reach. I'll fix them manually in a separate patch. Comments and documentation also will be addressed with the separate patch. virtual patch @@ expression E; @@ - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT) + E @@ expression E; @@ - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) + E @@ @@ - PAGE_CACHE_SHIFT + PAGE_SHIFT @@ @@ - PAGE_CACHE_SIZE + PAGE_SIZE @@ @@ - PAGE_CACHE_MASK + PAGE_MASK @@ expression E; @@ - PAGE_CACHE_ALIGN(E) + PAGE_ALIGN(E) @@ expression E; @@ - page_cache_get(E) + get_page(E) @@ expression E; @@ - page_cache_release(E) + put_page(E) Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-04MIPS: traps.c: Verify the ISA for microMIPS RDHWR emulationMaciej W. Rozycki1-13/+13
Make sure it's the microMIPS rather than MIPS16 ISA before emulating microMIPS RDHWR. Mostly needed as an optimisation for configurations where `cpu_has_mmips' is hardcoded to 0 and also a good measure in case we add further microMIPS instructions to emulate in the future, as the corresponding MIPS16 encoding is ADDIUSP, not supposed to trap. Signed-off-by: Maciej W. Rozycki <macro@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12282/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-04MIPS: BMIPS: Fix gisb-arb compatible string for 7435Florian Fainelli1-1/+1
The SUN GISB arbiter was added with the wrong compatible string, leading to using the wrong register layout, use the correct compatible string for this chip: brcm,bcm7435-gisb-arb. Fixes: 8394968be4c7 ("MIPS: BMIPS: Add BCM7435 dtsi") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Cc: blogic@openwrt.org Cc: cernekee@gmail.com Cc: jogo@openwrt.org Cc: jaedon.shin@gmail.com Cc: pgynther@google.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12285/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-04MAINTAINERS: xen: Konrad to step down and Juergen to pick upKonrad Rzeszutek Wilk1-1/+1
I've lately been concentrating on other projects and haven't been doing much of Xen core maintainership for the last year. I am quite thrilled that Juergen is willing to help out! P.S. I am still the maintainer of Xen-SWIOTLB, Xen PCI-[front|backend], and co-maintainer of Xen block-[front|backend]; amongst others. Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
2016-04-04xen/events: Mask a moving irqBoris Ostrovsky1-4/+24
Moving an unmasked irq may result in irq handler being invoked on both source and target CPUs. With 2-level this can happen as follows: On source CPU: evtchn_2l_handle_events() -> generic_handle_irq() -> handle_edge_irq() -> eoi_pirq(): irq_move_irq(data); /***** WE ARE HERE *****/ if (VALID_EVTCHN(evtchn)) clear_evtchn(evtchn); If at this moment target processor is handling an unrelated event in evtchn_2l_handle_events()'s loop it may pick up our event since target's cpu_evtchn_mask claims that this event belongs to it *and* the event is unmasked and still pending. At the same time, source CPU will continue executing its own handle_edge_irq(). With FIFO interrupt the scenario is similar: irq_move_irq() may result in a EVTCHNOP_unmask hypercall which, in turn, may make the event pending on the target CPU. We can avoid this situation by moving and clearing the event while keeping event masked. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: David Vrabel <david.vrabel@citrix.com>
2016-04-03Linux 4.6-rc2v4.6-rc2Linus Torvalds1-1/+1
2016-04-03v4l2-mc: avoid warning about unused variableLinus Torvalds1-1/+1
Commit 840f5b0572ea ("media: au0828 disable tuner to demod link in au0828_media_device_register()") removed all uses of the 'dtv_demod', but left the variable itself around. Remove it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-03MIPS: Bail on unsupported module relocsPaul Burton2-6/+32
When an unsupported reloc is encountered in a module, we currently blindly branch to whatever would be at its entry in the reloc handler function pointer arrays. This may be NULL, or if the unsupported reloc has a type greater than that of the supported reloc with the highest type then we'll dereference some value after the function pointer array & branch to that. The result is at best a kernel oops. Fix this by checking that the reloc type has an entry in the function pointer array (ie. is less than the number of items in the array) and that the handler is non-NULL, returning an error code to fail the module load if no handler is found. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12432/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: dts: qca: ar9132_tl_wr1043nd_v1.dts: use "ref" for reference clock nameAntony Pavlov1-1/+1
Current ath79 clock.c code does not read reference clock and pll setup from devicetree. The ar724x_clocks_init() function recreates the clocks from scratch so devicetree clock information is dropped. After adding the code which picked up reference clock from devicetree I have found that kernel does not boot anymore. The SPI and UART drivers can't get clk; here are the bootlog error messages: of_serial: probe of 18020000.uart failed with error -22 ath79-spi: probe of 1f000000.spi failed with error -22 The problem is that clock code assumes that reference clock name is "ref" but current dts-file uses another name: "oscillator". This patch fixes the problem by changing external oscillator dt node name to "ref". Please note that there is an alternative solution for the problem: > --- a/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts > +++ b/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts > @@ -16,6 +16,7 @@ > > extosc: oscillator { > compatible = "fixed-clock"; > + clock-output-names = "ref"; > #clock-cells = <0>; > clock-frequency = <40000000>; > }; Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com> Cc: Alban Bedel <albeu@free.fr> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-clk@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12874/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: ath79: Fix the ar913x reference clock rateAlban Bedel1-37/+1
The reference clock on ar913x is at 40MHz and not 5MHz. The current implementation use the wrong reference rate because it doesn't take the PLL divider in account. But if we fix the code to use the divider it becomes identical with the implementation for ar724x, so just drop the broken ar913x implementation. Signed-off-by: Alban Bedel <albeu@free.fr> Tested-by: Antony Pavlov <antonynpavlov@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12871/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: ath79: Fix the ar724x clock calculationWeijie Gao1-3/+3
According to the AR7242 datasheet section 2.8, AR724X CPUs use a 40MHz input clock as the REF_CLK instead of 5MHz. The correct CPU PLL calculation procedure is as follows: CPU_PLL = (FB * REF_CLK) / REF_DIV / 2. This patch is compatible with the current calculation procedure with default FB and REF_DIV values. Tested on AR7240, AR7241 and AR7242. Signed-off-by: Weijie Gao <hackpascal@gmail.com> Signed-off-by: Alban Bedel <albeu@free.fr> (Fixed the commit log message) Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12870/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03dt-bindings: clock: qca,ath79-pll: fix copy-paste typosAntony Pavlov2-4/+4
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Cc: Alban Bedel <albeu@free.fr> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12869/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: traps: Correct the SIGTRAP debug ABI in `do_watch' and `do_trap_or_bp'Maciej W. Rozycki3-12/+20
Follow our own rules set in <asm/siginfo.h> for SIGTRAP signals issued from `do_watch' and `do_trap_or_bp' by setting the signal code to TRAP_HWBKPT and TRAP_BRKPT respectively, for Watch exceptions and for those Breakpoint exceptions whose originating BREAK instruction's code does not have a special meaning. Keep Trap exceptions unaffected as these are not debug events. No existing user software is expected to examine signal codes for these signals as SI_KERNEL has been always used here. This change makes the MIPS port more like other Linux ports, which reduces the complexity and provides for performance improvement in GDB. Signed-off-by: Maciej W. Rozycki <macro@imgtec.com> Cc: Pedro Alves <palves@redhat.com> Cc: Luis Machado <lgustavo@codesourcery.com> Cc: linux-mips@linux-mips.org Cc: gdb@sourceware.org Patchwork: https://patchwork.linux-mips.org/patch/12758/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03FIRMWARE: Broadcom: Fix grammar of warning messages in bcm47xx_sprom.c.Ralf Baechle1-2/+2
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: ci20: Enable NAND and UBIFS support in defconfig.Harvey Hunt1-5/+9
Update the Ci20's defconfig to enable the JZ4780's NAND driver and therefore access to the UBIFS rootfs. Signed-off-by: Harvey Hunt <harvey.hunt@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12699/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: Fix misspellings in comments.Adam Buchbinder32-52/+52
Signed-off-by: Adam Buchbinder <adam.buchbinder@gmail.com> Cc: linux-mips@linux-mips.org Cc: trivial@kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12617/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: tlb-r4k: panic if the MMU doesn't support PAGE_SIZEPaul Burton1-0/+5
After writing the appropriate mask to the cop0 PageMask register, read the register back & check it matches what we want. If it doesn't then the MMU does not support the page size the kernel is configured for and we're better off bailing than continuing to do odd things with TLB exceptions. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10691/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: zboot: Remove copied source files on cleanAlban Bedel1-0/+1
The copied source files must be added to the extra-y list to have them removed on clean. Signed-off-by: Alban Bedel <albeu@free.fr> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Alex Smith <alex.smith@imgtec.com> Cc: Wu Zhangjin <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12233/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: zboot: Fix the build with XZ compression on older GCC versionsAlban Bedel1-3/+3
Some older GCC version (at least 4.6) emits calls to __bswapsi2() when building the XZ decompressor. The link of the compressed image then fails with the following error: arch/mips/boot/compressed/decompress.o: In function '__fswab32': include/uapi/linux/swab.h:60: undefined reference to '__bswapsi2' Add bswapsi.o to the link to fix the build with these versions. Signed-off-by: Alban Bedel <albeu@free.fr> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Alex Smith <alex.smith@imgtec.com> Cc: Wu Zhangjin <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12232/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03MIPS: Wire up preadv2 and pwrite2 syscalls.Ralf Baechle5-6/+20
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-03Convert straggling drivers to new six-argument get_user_pages()Linus Torvalds2-3/+2
Commit d4edcf0d5695 ("mm/gup: Switch all callers of get_user_pages() to not pass tsk/mm") switched get_user_pages() callers to the simpler model where they no longer pass in the thread and mm pointer. But since then we've merged changes to a few drivers that re-introduce use of the old interface. Let's fix them up. They continued to work fine (thanks to the truly disgusting macros introduced in commit cde70140fed8: "mm/gup: Overload get_user_pages() functions"), but cause unnecessary build noise. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02.mailmap: add Christophe RicardChristophe Ricard1-0/+1
Different computers had different settings in the mail client. Some contributions appear as Christophe Ricard, others as Christophe RICARD. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02Make CONFIG_FHANDLE default yAndi Kleen1-1/+2
Newer Fedora and OpenSUSE didn't boot with my standard configuration. It took me some time to figure out why, in fact I had to write a script to try different config options systematically. The problem is that something (systemd) in dracut depends on CONFIG_FHANDLE, which adds open by file handle syscalls. While it is set in defconfigs it is very easy to miss when updating older configs because it is not default y. Make it default y and also depend on EXPERT, as dracut use is likely widespread. Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Richard Weinberger <richard.weinberger@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02mm/page_isolation.c: fix the function commentsNeil Zhang1-1/+1
Commit fea85cff11de ("mm/page_isolation.c: return last tested pfn rather than failure indicator") changed the meaning of the return value. Let's change the function comments as well. Signed-off-by: Neil Zhang <neilzhang1123@hotmail.com> Cc: Joonsoo Kim <js1304@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02oom, oom_reaper: do not enqueue task if it is on the oom_reaper_list headMichal Hocko1-1/+5
Commit bb29902a7515 ("oom, oom_reaper: protect oom_reaper_list using simpler way") has simplified the check for tasks already enqueued for the oom reaper by checking tsk->oom_reaper_list != NULL. This check is not sufficient because the tsk might be the head of the queue without any other tasks queued and then we would simply lockup looping on the same task. Fix the condition by checking for the head as well. Fixes: bb29902a7515 ("oom, oom_reaper: protect oom_reaper_list using simpler way") Signed-off-by: Michal Hocko <mhocko@suse.com> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02mm/page_isolation: fix tracepoint to mirror check function behaviorLucas Stach1-1/+1
Page isolation has not failed if the fin pfn extends beyond the end pfn and test_pages_isolated checks this correctly. Fix the tracepoint to report the same result as the actual check function. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Joonsoo Kim <js1304@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02mm/rmap: batched invalidations should use existing apiNadav Amit3-28/+8
The recently introduced batched invalidations mechanism uses its own mechanism for shootdown. However, it does wrong accounting of interrupts (e.g., inc_irq_stat is called for local invalidations), trace-points (e.g., TLB_REMOTE_SHOOTDOWN for local invalidations) and may break some platforms as it bypasses the invalidation mechanisms of Xen and SGI UV. This patch reuses the existing TLB flushing mechnaisms instead. We use NULL as mm to indicate a global invalidation is required. Fixes 72b252aed506b8 ("mm: send one IPI per CPU to TLB flush all entries after unmapping pages") Signed-off-by: Nadav Amit <namit@vmware.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02x86/mm: TLB_REMOTE_SEND_IPI should count pagesNadav Amit1-3/+9
TLB_REMOTE_SEND_IPI was recently introduced, but it counts bytes instead of pages. In addition, it does not report correctly the case in which flush_tlb_page flushes a page. Fix it to be consistent with other TLB counters. Fixes: 5b74283ab251b9d ("x86, mm: trace when an IPI is about to be sent") Signed-off-by: Nadav Amit <namit@vmware.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02mm: fix invalid node in alloc_migrate_target()Xishi Qiu1-4/+4
It is incorrect to use next_node to find a target node, it will return MAX_NUMNODES or invalid node. This will lead to crash in buddy system allocation. Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Signed-off-by: Xishi Qiu <qiuxishi@huawei.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Joonsoo Kim <js1304@gmail.com> Cc: David Rientjes <rientjes@google.com> Cc: "Laura Abbott" <lauraa@codeaurora.org> Cc: Hui Zhu <zhuhui@xiaomi.com> Cc: Wang Xiaoqiang <wangxq10@lzu.edu.cn> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02include/linux/huge_mm.h: return NULL instead of false for pmd_trans_huge_lock()Chen Gang1-1/+1
The return value of pmd_trans_huge_lock() is a pointer, not a boolean value, so use NULL instead of false as the return value. Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02mm, kasan: fix compilation for CONFIG_SLABAlexander Potapenko1-1/+1
Add the missing argument to set_track(). Fixes: cd11016e5f52 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB") Signed-off-by: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <adech.fo@gmail.com> Cc: Christoph Lameter <cl@linux.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Konstantin Serebryany <kcc@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-02MAINTAINERS: orangefs mailing list is subscribers-onlyJoe Perches1-1/+1
So update MAINTAINERS to say so. Signed-off-by: Joe Perches <joe@perches.com> Cc: Mike Marshall <hubcap@omnibond.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-01net: mvneta: fix changing MTU when using per-cpu processingMarcin Wojtas1-14/+16
After enabling per-cpu processing it appeared that under heavy load changing MTU can result in blocking all port's interrupts and transmitting data is not possible after the change. This commit fixes above issue by disabling percpu interrupts for the time, when TXQs and RXQs are reconfigured. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01stmmac: fix MDIO settingsGiuseppe CAVALLARO4-48/+73
Initially the phy_bus_name was added to manipulate the driver name but it was recently just used to manage the fixed-link and then to take some decision at run-time. So the patch uses the is_pseudo_fixed_link and removes the phy_bus_name variable not necessary anymore. The driver can manage the mdio registration by using phy-handle, dwmac-mdio and own parameter e.g. snps,phy-addr. This patch takes care about all these possible configurations and fixes the mdio registration in case of there is a real transceiver or a switch (that needs to be managed by using fixed-link). Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Reviewed-by: Andreas Färber <afaerber@suse.de> Tested-by: Frank Schäfer <fschaefer.oss@googlemail.com> Cc: Gabriel Fernandez <gabriel.fernandez@linaro.org> Cc: Dinh Nguyen <dinh.linux@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: Phil Reid <preid@electromag.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01Revert "stmmac: Fix 'eth0: No PHY found' regression"Giuseppe CAVALLARO3-10/+11
This reverts commit 88f8b1bb41c6208f81b6a480244533ded7b59493. due to problems on GeekBox and Banana Pi M1 board when connected to a real transceiver instead of a switch via fixed-link. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Gabriel Fernandez <gabriel.fernandez@linaro.org> Cc: Andreas Färber <afaerber@suse.de> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Cc: Dinh Nguyen <dinh.linux@gmail.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01stmmac: fix TX normal DESCGiuseppe CAVALLARO1-8/+8
This patch fixs a regression raised when test on chips that use the normal descriptor layout. In fact, no len bits were set for the TDES1 and no OWN bit inside the TDES0. Signed-off-by: Giuseppe CAVALLARO <peppe.cavallaro@st.com> Tested-by: Andreas Färber <afaerber@suse.de> Cc: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01net: mvneta: use cache_line_size() to get cacheline sizeJisheng Zhang1-1/+1
L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size to determine the cacheline size in runtime. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Suggested-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01net: mvpp2: use cache_line_size() to get cacheline sizeJisheng Zhang1-1/+1
L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size to determine the cacheline size in runtime. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Suggested-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01net: mvpp2: fix maybe-uninitialized warningJisheng Zhang1-1/+3
This is to fix the following maybe-uninitialized warning: drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01tun, bpf: fix suspicious RCU usage in tun_{attach, detach}_filterDaniel Borkmann3-15/+30
Sasha Levin reported a suspicious rcu_dereference_protected() warning found while fuzzing with trinity that is similar to this one: [ 52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage! [ 52.765688] other info that might help us debug this: [ 52.765695] rcu_scheduler_active = 1, debug_locks = 1 [ 52.765701] 1 lock held by a.out/1525: [ 52.765704] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff816a64b7>] rtnl_lock+0x17/0x20 [ 52.765721] stack backtrace: [ 52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264 [...] [ 52.765768] Call Trace: [ 52.765775] [<ffffffff813e488d>] dump_stack+0x85/0xc8 [ 52.765784] [<ffffffff810f2fa5>] lockdep_rcu_suspicious+0xd5/0x110 [ 52.765792] [<ffffffff816afdc2>] sk_detach_filter+0x82/0x90 [ 52.765801] [<ffffffffa0883425>] tun_detach_filter+0x35/0x90 [tun] [ 52.765810] [<ffffffffa0884ed4>] __tun_chr_ioctl+0x354/0x1130 [tun] [ 52.765818] [<ffffffff8136fed0>] ? selinux_file_ioctl+0x130/0x210 [ 52.765827] [<ffffffffa0885ce3>] tun_chr_ioctl+0x13/0x20 [tun] [ 52.765834] [<ffffffff81260ea6>] do_vfs_ioctl+0x96/0x690 [ 52.765843] [<ffffffff81364af3>] ? security_file_ioctl+0x43/0x60 [ 52.765850] [<ffffffff81261519>] SyS_ioctl+0x79/0x90 [ 52.765858] [<ffffffff81003ba2>] do_syscall_64+0x62/0x140 [ 52.765866] [<ffffffff817d563f>] entry_SYSCALL64_slow_path+0x25/0x25 Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH, DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices. Since the fix in f91ff5b9ff52 ("net: sk_{detach|attach}_filter() rcu fixes") sk_attach_filter()/sk_detach_filter() now dereferences the filter with rcu_dereference_protected(), checking whether socket lock is held in control path. Since its introduction in 994051625981 ("tun: socket filter support"), tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the sock_owned_by_user(sk) doesn't apply in this specific case and therefore triggers the false positive. Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair that is used by tap filters and pass in lockdep_rtnl_is_held() for the rcu_dereference_protected() checks instead. Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-01Revert "Revert "pinctrl: lantiq: Implement gpio_chip.to_irq""Linus Walleij1-0/+17
This reverts commit 446f59acb70b70a425ea4105277a71eb615327cd.
2016-04-01ALSA: timer: Use mod_timer() for rearming the system timerTakashi Iwai1-2/+2
ALSA system timer backend stops the timer via del_timer() without sync and leaves del_timer_sync() at the close instead. This is because of the restriction by the design of ALSA timer: namely, the stop callback may be called from the timer handler, and calling the sync shall lead to a hangup. However, this also triggers a kernel BUG() when the timer is rearmed immediately after stopping without sync: kernel BUG at kernel/time/timer.c:966! Call Trace: <IRQ> [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0 [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0 [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290 [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120 [<ffffffff81296b72>] call_timer_fn+0x162/0x520 [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520 [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0 .... It's the place where add_timer() checks the pending timer. It's clear that this may happen after the immediate restart without sync in our cases. So, the workaround here is just to use mod_timer() instead of add_timer(). This looks like a band-aid fix, but it's a right move, as snd_timer_interrupt() takes care of the continuous rearm of timer. Reported-by: Jiri Slaby <jslaby@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>