aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-07-16mmc: pxamci: remove pxa-mmc, gpio-power from devicetree bindingsDaniel Mack2-4/+1
Devicetree-enabled boards should use proper regulators to control the power of cards, not GPIOs, so let's remove this property. The regulator properties are supported by the MMC core and are described in the generic MMC document: Documentation/devicetree/bindings/mmc/mmc.txt Note that devicetree support for PXA platforms hasn't fully landed yet, so this binding does not have any users at this point. Signed-off-by: Daniel Mack <daniel@zonque.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: pxamci: call mmc_of_parse()Daniel Mack2-13/+15
Call into mmc_of_parse() from pxamci_of_init(). As it needs a pointer to a struct mmc_host, refactor the code a bit. This allows all generic MMC properties to be set that are described in Documentation/devicetree/bindings/mmc/mmc.txt. Reword the documentation a bit to make that clear. The "cd" and "wp" gpio lookups are removed as the lookup will now be done by mmc_of_parse(). Signed-off-by: Daniel Mack <daniel@zonque.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: pxamci: fix indentingDaniel Mack1-10/+10
pxamci_of_init() had some weird indenting. Signed-off-by: Daniel Mack <daniel@zonque.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: pxamci: remove dead code from pxamci_remove()Daniel Mack1-6/+1
These gpio assignments don't make sense, as they are not used anywhere. Remove the dead code. Signed-off-by: Daniel Mack <daniel@zonque.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: pxamci: remove dma resources from private contextDaniel Mack1-4/+0
These members are no longer in use, so let's remove them. Signed-off-by: Daniel Mack <daniel@zonque.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: pxamci: remove irq from private contextDaniel Mack1-3/+1
This seems to be a left-over from times before the IRQ was handled by devm functions. Remove it. Signed-off-by: Daniel Mack <daniel@zonque.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: sdhci-esdhc-imx: get rid of support_vselStefan Agner2-8/+2
The field support_vsel is currently only used in the device tree case. Get rid of it. No change in behavior. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: sdhci-esdhc-imx: support eMMC DDR mode when running at 3.3VStefan Agner1-1/+1
The uSDHC supports DDR modes for eMMC devices running at 3.3V. This allows to run eMMC with 3.3V signaling voltage at DDR52 mode: # cat /sys/kernel/debug/mmc1/ios clock: 52000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 8 (mmc DDR52) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: core: Drop the unused mmc_power_save|restore_host()Ulf Hansson4-52/+0
The last user of mmc_power_save|restore_host() APIs is gone, hence let's drop them. Drop also the corresponding bus_ops callback, ->power_save|restore() as those becomes redundant. Cc: Tony Lindgren <tony@atomide.com> Cc: Eyal Reizer <eyalreizer@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: sdhci-of-esdhc: modify the sd clock in of_match_node wayyinbo.zhu1-28/+57
Convert to use of_match_node method to fix up eSDHC clock for ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a according to its datasheet. The maxmum speed for ls1021a eSDHC high speed mode is 46.5MHz. Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: sdhci-of-arasan: Add quirk for unstable clocksHelmut Grohne1-0/+16
Some controllers immediately report SDHCI_CLOCK_INT_STABLE after enabling the clock even when the clock is not stable. When used in conjunction with older/slower cards, this can result in: mmc0: error -84 whilst initialising SD card When the stable reporting is known to be broken, we simply wait for the maximum stabilization period. Signed-off-by: Helmut Grohne <h.grohne@intenta.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16dt-bindings: mmc: broken clock stable indicator on arasan controllersHelmut Grohne1-0/+2
Some controllers immediately report that their internal clock is stable after activating it even when the clock is not stable. When used in conjunction with older/slower cards, this can result in: mmc0: error -84 whilst initialising SD card This flag allows documenting and thus working around such a hardware defect. Signed-off-by: Helmut Grohne <h.grohne@intenta.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: sdhci-pci: Add support for Intel ICPAdrian Hunter2-0/+4
Add PCI Ids for Intel ICP. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: host: Register changes for sdcc V5Sayali Lokhande1-126/+221
Add support to use the new compatible string "qcom,sdhci-msm-v5". Based on the msm variant, pick the relevant variant data and use it for register read/write to msm specific registers. Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16Documentation: sdhci-msm: Add new compatible string for SDCC v5Sayali Lokhande1-1/+6
For SDCC version 5.0.0 and higher, new compatible string "qcom,sdhci-msm-v5" is added. Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: sdhci-msm: Add msm version specific ops and data structuresVijay Viswanath1-0/+75
In addition to offsets of certain registers changing, the registers in core_mem have been shifted to HC mem as well. To access these registers, define msm version specific functions. These functions can be loaded into the function pointers at the time of probe based on the msm version detected. Also defind new data structure to hold version specific Ops and register addresses. Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: sdhci-msm: Define new Register address mapSayali Lokhande1-0/+89
For SDCC version 5.0.0, MCI registers are removed from SDCC interface and some registers are moved to HC. Define a new data structure where we can statically define the address offsets for the registers in different SDCC versions. Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org> Reviewed-by: Evan Green <evgreen@chromium.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: renesas_sdhi: add eMMC HS400 mode supportMasaharu Hayakawa3-26/+138
This patch adds processing for selecting HS400 mode. Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: tmio: add eMMC HS400 mode supportMasaharu Hayakawa3-2/+54
This patch adds processing for selecting HS400 mode. Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: core: more fine-grained hooks for HS400 tuningSimon Horman2-0/+17
This adds two new HS400 tuning operations: * hs400_downgrade * hs400_complete These supplement the existing HS400 operation: * prepare_hs400_tuning This is motivated by a requirement of Renesas SDHI for the following: 1. Disabling SCC before selecting to HS if selection of HS400 has occurred. This can be done in an implementation of prepare_hs400_tuning_downgrade 2. Updating registers after switching to HS400 This can be done in an implementation of complete_hs400_tuning If hs400_downgrade or hs400_complete are not implemented then they are not called. Thus means there should be no affect for existing drivers as none implemt these ops. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: dw_mmc-exynos: fix potential external abort in resume_noirq()Marek Szyprowski1-9/+24
dw_mci_exynos_resume_noirq() performs DWMMC register access without ensuring that respective clocks are enabled. This might cause external abort on some systems (observed on Exynos5433 based boards). Fix this by forcing a PM runtime active state before register access. Using SET_NOIRQ_SYSTEM_SLEEP_PM_OPS allows also to cleanup conditional code a bit. Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: tegra: Use sdhci_pltfm_clk_get_max_clockAapo Vienamo1-13/+2
The sdhci get_max_clock callback is set to sdhci_pltfm_clk_get_max_clock and tegra_sdhci_get_max_clock is removed. It appears that the shdci-tegra specific callback was originally introduced due to the requirement that the host clock has to be twice the bus clock on DDR50 mode. As far as I can tell the only effect the removal has on DDR50 mode is in cases where the parent clock is unable to supply the requested clock rate, causing the DDR50 mode to run at a lower frequency. Currently the DDR50 mode isn't enabled on any of the SoCs and would also require configuring the SDHCI clock divider register to function properly. The problem with tegra_sdhci_get_max_clock is that it divides the clock rate by two and thus artificially limits the maximum frequency of faster signaling modes which don't have the host-bus frequency ratio requirement of DDR50 such as SDR104 and HS200. Furthermore, the call to clk_round_rate() may return an error which isn't handled by tegra_sdhci_get_max_clock. Signed-off-by: Aapo Vienamo <avienamo@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-16mmc: core: Adjust and reuse the macro of R1_STATUS(x)Shawn Lin3-3/+3
R1_STATUS(x) now is only used by ioctl_rpmb_card_status_poll(), which checks all bits as possible. But according to the spec, bit 17 and bit 18 should be ignored, as well bit 14 which is reserved(must be set to 0) quoting from the spec and these rule apply to all places checking the device status. So change its checking from 0xFFFFE000 to 0xFFF9A000. As a bonus, we reuse it for mmc_do_erase() as well as mmc_switch_status_error(). (1) Currently mmc_switch_status_error() doesn't check bit 25, but it means device is locked but not unlocked by CMD42 prior to any operations which need check busy, which is also not allowed. (2) mmc_do_erase() also forgot to to check bit 15, WP_ERASE_SKIP. The spec says "Only partial address space was erased due to existing write protected blocks.", which obviously means we should fail this I/O. Otherwise, the partial erased data stored in nonvalatile flash violates the data integrity from the view of I/O owner, which probably confuse it when further used. So reusing R1_STATUS for them not only improve the readability but also slove real problems. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-07-15Linux 4.18-rc5Linus Torvalds1-1/+1
2018-07-14reiserfs: fix buffer overflow with long warning messagesEric Biggers1-60/+81
ReiserFS prepares log messages into a 1024-byte buffer with no bounds checks. Long messages, such as the "unknown mount option" warning when userspace passes a crafted mount options string, overflow this buffer. This causes KASAN to report a global-out-of-bounds write. Fix it by truncating messages to the buffer size. Link: http://lkml.kernel.org/r/20180707203621.30922-1-ebiggers3@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+b890b3335a4d8c608963@syzkaller.appspotmail.com Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14checkpatch: fix duplicate invalid vsprintf pointer extension '%p<foo>' messagesJoe Perches1-3/+3
Multiline statements with invalid %p<foo> uses produce multiple warnings. Fix that. e.g.: $ cat t_block.c void foo(void) { MY_DEBUG(drv->foo, "%pk", foo->boo); } $ ./scripts/checkpatch.pl -f t_block.c WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #1: FILE: t_block.c:1: +void foo(void) WARNING: Invalid vsprintf pointer extension '%pk' #3: FILE: t_block.c:3: + MY_DEBUG(drv->foo, + "%pk", + foo->boo); WARNING: Invalid vsprintf pointer extension '%pk' #3: FILE: t_block.c:3: + MY_DEBUG(drv->foo, + "%pk", + foo->boo); total: 0 errors, 3 warnings, 6 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. t_block.c has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Link: http://lkml.kernel.org/r/9e8341bbe4c9877d159cb512bb701043cbfbb10b.camel@perches.com Signed-off-by: Joe Perches <joe@perches.com> Cc: "Tobin C. Harding" <me@tobin.cc> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: do not bug_on on incorrect length in __mm_populate()Michal Hocko2-19/+12
syzbot has noticed that a specially crafted library can easily hit VM_BUG_ON in __mm_populate kernel BUG at mm/gup.c:1242! invalid opcode: 0000 [#1] SMP CPU: 2 PID: 9667 Comm: a.out Not tainted 4.18.0-rc3 #644 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 RIP: 0010:__mm_populate+0x1e2/0x1f0 Code: 55 d0 65 48 33 14 25 28 00 00 00 89 d8 75 21 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 75 18 f1 ff 0f 0b e8 6e 18 f1 ff <0f> 0b 31 db eb c9 e8 93 06 e0 ff 0f 1f 00 55 48 89 e5 53 48 89 fb Call Trace: vm_brk_flags+0xc3/0x100 vm_brk+0x1f/0x30 load_elf_library+0x281/0x2e0 __ia32_sys_uselib+0x170/0x1e0 do_fast_syscall_32+0xca/0x420 entry_SYSENTER_compat+0x70/0x7f The reason is that the length of the new brk is not page aligned when we try to populate the it. There is no reason to bug on that though. do_brk_flags already aligns the length properly so the mapping is expanded as it should. All we need is to tell mm_populate about it. Besides that there is absolutely no reason to to bug_on in the first place. The worst thing that could happen is that the last page wouldn't get populated and that is far from putting system into an inconsistent state. Fix the issue by moving the length sanitization code from do_brk_flags up to vm_brk_flags. The only other caller of do_brk_flags is brk syscall entry and it makes sure to provide the proper length so t here is no need for sanitation and so we can use do_brk_flags without it. Also remove the bogus BUG_ONs. [osalvador@techadventures.net: fix up vm_brk_flags s@request@len@] Link: http://lkml.kernel.org/r/20180706090217.GI32658@dhcp22.suse.cz Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: syzbot <syzbot+5dcb560fe12aa5091c06@syzkaller.appspotmail.com> Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Oscar Salvador <osalvador@suse.de> Cc: Zi Yan <zi.yan@cs.rutgers.edu> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Huang, Ying" <ying.huang@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm/memblock.c: do not complain about top-down allocations for !MEMORY_HOTREMOVEMichal Hocko1-1/+2
Mike Rapoport is converting architectures from bootmem to nobootmem allocator. While doing so for m68k Geert has noticed that he gets a scary looking warning: WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 memblock_find_in_range_node+0x11c/0x1be memblock: bottom-up allocation failed, memory hotunplug may be affected Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7 Call Trace: __warn+0xa8/0xc2 kernel_pg_dir+0x0/0x1000 netdev_lower_get_next+0x2/0x22 warn_slowpath_fmt+0x2e/0x36 memblock_find_in_range_node+0x11c/0x1be memblock_find_in_range_node+0x11c/0x1be memblock_find_in_range_node+0x0/0x1be vprintk_func+0x66/0x6e memblock_virt_alloc_internal+0xd0/0x156 netdev_lower_get_next+0x2/0x22 netdev_lower_get_next+0x2/0x22 kernel_pg_dir+0x0/0x1000 memblock_virt_alloc_try_nid_nopanic+0x58/0x7a netdev_lower_get_next+0x2/0x22 kernel_pg_dir+0x0/0x1000 kernel_pg_dir+0x0/0x1000 EXPTBL+0x234/0x400 EXPTBL+0x234/0x400 alloc_node_mem_map+0x4a/0x66 netdev_lower_get_next+0x2/0x22 free_area_init_node+0xe2/0x29e EXPTBL+0x234/0x400 paging_init+0x430/0x462 kernel_pg_dir+0x0/0x1000 printk+0x0/0x1a EXPTBL+0x234/0x400 setup_arch+0x1b8/0x22c start_kernel+0x4a/0x40a _sinittext+0x344/0x9e8 The warning is basically saying that a top-down allocation can break memory hotremove because memblock allocation is not movable. But m68k doesn't even support MEMORY_HOTREMOVE so there is no point to warn about it. Make the warning conditional only to configurations that care. Link: http://lkml.kernel.org/r/20180706061750.GH32658@dhcp22.suse.cz Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Sam Creasey <sammy@sammy.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14fs, elf: make sure to page align bss in load_elf_libraryOscar Salvador1-3/+2
The current code does not make sure to page align bss before calling vm_brk(), and this can lead to a VM_BUG_ON() in __mm_populate() due to the requested lenght not being correctly aligned. Let us make sure to align it properly. Kees: only applicable to CONFIG_USELIB kernels: 32-bit and configured for libc5. Link: http://lkml.kernel.org/r/20180705145539.9627-1-osalvador@techadventures.net Signed-off-by: Oscar Salvador <osalvador@suse.de> Reported-by: syzbot+5dcb560fe12aa5091c06@syzkaller.appspotmail.com Tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Acked-by: Kees Cook <keescook@chromium.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14x86/purgatory: add missing FORCE to Makefile targetPhilipp Rudo1-1/+1
- Build the kernel without the fix - Add some flag to the purgatories KBUILD_CFLAGS,I used -fno-asynchronous-unwind-tables - Re-build the kernel When you look at makes output you see that sha256.o is not re-build in the last step. Also readelf -S still shows the .eh_frame section for sha256.o. With the fix sha256.o is rebuilt in the last step. Without FORCE make does not detect changes only made to the command line options. So object files might not be re-built even when they should be. Fix this by adding FORCE where it is missing. Link: http://lkml.kernel.org/r/20180704110044.29279-2-prudo@linux.ibm.com Fixes: df6f2801f511 ("kernel/kexec_file.c: move purgatories sha256 to common code") Signed-off-by: Philipp Rudo <prudo@linux.ibm.com> Acked-by: Dave Young <dyoung@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> [4.17+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14net/9p/client.c: put refcount of trans_mod in error case in parse_opts()piaojun1-1/+2
In my testing, the second mount will fail after umounting successfully. The reason is that we put refcount of trans_mod in the correct case rather than the error case in parse_opts() at last. That will cause the refcount decrease to -1, and when we try to get trans_mod again in try_module_get(), we could only increase refcount to 0 which will cause failure as follows: parse_opts v9fs_get_trans_by_name try_module_get : return NULL to caller which cause error So we should put refcount of trans_mod in error case. Link: http://lkml.kernel.org/r/5B3F39A0.2030509@huawei.com Fixes: 9421c3e64137ec ("net/9p/client.c: fix potential refcnt problem of trans module") Signed-off-by: Jun Piao <piaojun@huawei.com> Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Dominique Martinet <dominique.martinet@cea.fr> Tested-by: Dominique Martinet <dominique.martinet@cea.fr> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: allow arch to supply p??_free_tlb functionsNicholas Piggin1-0/+8
The mmu_gather APIs keep track of the invalidated address range including the span covered by invalidated page table pages. Ranges covered by page tables but not ptes (and therefore no TLBs) still need to be invalidated because some architectures (x86) can cache intermediate page table entries, and invalidate those with normal TLB invalidation instructions to be almost-backward-compatible. Architectures which don't cache intermediate page table entries, or which invalidate these caches separately from TLB invalidation, do not require TLB invalidation range expanded over page tables. Allow architectures to supply their own p??_free_tlb functions, which can avoid the __tlb_adjust_range. Link: http://lkml.kernel.org/r/20180703013131.2807-1-npiggin@gmail.com Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Nadav Amit <nadav.amit@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14autofs: fix slab out of bounds read in getname_kernel()Tomas Bortoli1-9/+13
The autofs subsystem does not check that the "path" parameter is present for all cases where it is required when it is passed in via the "param" struct. In particular it isn't checked for the AUTOFS_DEV_IOCTL_OPENMOUNT_CMD ioctl command. To solve it, modify validate_dev_ioctl(function to check that a path has been provided for ioctl commands that require it. Link: http://lkml.kernel.org/r/153060031527.26631.18306637892746301555.stgit@pluto.themaw.net Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com> Signed-off-by: Ian Kent <raven@themaw.net> Reported-by: syzbot+60c837b428dc84e83a93@syzkaller.appspotmail.com Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14fs/proc/task_mmu.c: fix Locked field in /proc/pid/smaps*Vlastimil Babka1-1/+2
Thomas reports: "While looking around in /proc on my v4.14.52 system I noticed that all processes got a lot of "Locked" memory in /proc/*/smaps. A lot more memory than a regular user can usually lock with mlock(). Commit 493b0e9d945f (in v4.14-rc1) seems to have changed the behavior of "Locked". Before that commit the code was like this. Notice the VM_LOCKED check. (vma->vm_flags & VM_LOCKED) ? (unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0); After that commit Locked is now the same as Pss: (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); This looks like a mistake." Indeed, the commit has added mss->pss_locked with the correct value that depends on VM_LOCKED, but forgot to actually use it. Fix it. Link: http://lkml.kernel.org/r/ebf6c7fb-fec3-6a26-544f-710ed193c154@suse.cz Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Daniel Colascione <dancol@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: do not drop unused pages when userfaultd is runningChristian Borntraeger1-1/+7
KVM guests on s390 can notify the host of unused pages. This can result in pte_unused callbacks to be true for KVM guest memory. If a page is unused (checked with pte_unused) we might drop this page instead of paging it. This can have side-effects on userfaultd, when the page in question was already migrated: The next access of that page will trigger a fault and a user fault instead of faulting in a new and empty zero page. As QEMU does not expect a userfault on an already migrated page this migration will fail. The most straightforward solution is to ignore the pte_unused hint if a userfault context is active for this VMA. Link: http://lkml.kernel.org/r/20180703171854.63981-1-borntraeger@de.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: David Hildenbrand <david@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-14mm: zero unavailable pages before memmap initPavel Tatashin1-2/+2
We must zero struct pages for memory that is not backed by physical memory, or kernel does not have access to. Recently, there was a change which zeroed all memmap for all holes in e820. Unfortunately, it introduced a bug that is discussed here: https://www.spinics.net/lists/linux-mm/msg156764.html Linus, also saw this bug on his machine, and confirmed that reverting commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") fixes the issue. The problem is that we incorrectly zero some struct pages after they were setup. The fix is to zero unavailable struct pages prior to initializing of struct pages. A more detailed fix should come later that would avoid double zeroing cases: one in __init_single_page(), the other one in zero_resv_unavail(). Fixes: 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-13rtc: fix alarm read and set offsetAlexandre Belloni1-3/+5
The offset needs to be added after reading the alarm value. It also needs to be subtracted after the now < alarm test. Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-07-13xen: setup pv irq ops vector earlierJuergen Gross2-16/+12
Setting pv_irq_ops for Xen PV domains should be done as early as possible in order to support e.g. very early printk() usage. The same applies to xen_vcpu_info_reset(0), as it is needed for the pv irq ops. Move the call of xen_setup_machphys_mapping() after initializing the pv functions as it contains a WARN_ON(), too. Remove the no longer necessary conditional in xen_init_irq_ops() from PVH V1 times to make clear this is a PV only function. Cc: <stable@vger.kernel.org> # 4.14 Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2018-07-12tracing: Reorder display of TGID to be after PIDJoel Fernandes (Google)2-6/+7
Currently ftrace displays data in trace output like so: _-----=> irqs-off / _----=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU TGID |||| TIMESTAMP FUNCTION | | | | |||| | | bash-1091 [000] ( 1091) d..2 28.313544: sched_switch: However Android's trace visualization tools expect a slightly different format due to an out-of-tree patch patch that was been carried for a decade, notice that the TGID and CPU fields are reversed: _-----=> irqs-off / _----=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID TGID CPU |||| TIMESTAMP FUNCTION | | | | |||| | | bash-1091 ( 1091) [002] d..2 64.965177: sched_switch: From kernel v4.13 onwards, during which TGID was introduced, tracing with systrace on all Android kernels will break (most Android kernels have been on 4.9 with Android patches, so this issues hasn't been seen yet). From v4.13 onwards things will break. The chrome browser's tracing tools also embed the systrace viewer which uses the legacy TGID format and updates to that are known to be difficult to make. Considering this, I suggest we make this change to the upstream kernel and backport it to all Android kernels. I believe this feature is merged recently enough into the upstream kernel that it shouldn't be a problem. Also logically, IMO it makes more sense to group the TGID with the TASK-PID and the CPU after these. Link: http://lkml.kernel.org/r/20180626000822.113931-1-joel@joelfernandes.org Cc: jreck@google.com Cc: tkjos@google.com Cc: stable@vger.kernel.org Fixes: 441dae8f2f29 ("tracing: Add support for display of tgid in trace output") Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-07-12i2c: recovery: if possible send STOP with recovery pulsesWolfram Sang1-1/+10
I2C clients may misunderstand recovery pulses if they can't read SDA to bail out early. In the worst case, as a write operation. To avoid that and if we can write SDA, try to send STOP to avoid the misinterpretation. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2018-07-13kbuild: suppress warnings from 'getconf LFS_*'Masahiro Yamada1-3/+3
Suppress warnings for systems that do not recognize LFS_*. getconf: no such configuration parameter `LFS_CFLAGS' getconf: no such configuration parameter `LFS_LDFLAGS' getconf: no such configuration parameter `LFS_LIBS' Fixes: d7f14c66c273 ("kbuild: Enable Large File Support for hostprogs") Reported-by: Chen Feng <puck.chen@hisilicon.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2018-07-13scripts/tags.sh: add __ro_after_initConstantine Shulyupin1-1/+1
Signed-off-by: Constantine Shulyupin <const@MakeLinux.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-13tools: build: Use HOSTLDFLAGS with fixdepLaura Abbott1-1/+1
The final link of fixdep uses LDFLAGS but not the existing HOSTLDFLAGS. Fix this. Signed-off-by: Laura Abbott <labbott@redhat.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-13tools: build: Fixup host c flagsLaura Abbott2-2/+2
Commit 0c3b7e42616f ("tools build: Add support for host programs format") introduced host_c_flags which referenced CHOSTFLAGS. The actual name of the variable is HOSTCFLAGS. Fix this up. Fixes: 0c3b7e42616f ("tools build: Add support for host programs format") Signed-off-by: Laura Abbott <labbott@redhat.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-13tools build: fix # escaping in .cmd files for future MakePaul Menzel1-2/+2
In 2016 GNU Make made a backwards incompatible change to the way '#' characters were handled in Makefiles when used inside functions or macros: http://git.savannah.gnu.org/cgit/make.git/commit/?id=c6966b323811c37acedff05b57 Due to this change, when attempting to run `make prepare' I get a spurious make syntax error: /home/earnest/linux/tools/objtool/.fixdep.o.cmd:1: *** missing separator. Stop. When inspecting `.fixdep.o.cmd' it includes two lines which use unescaped comment characters at the top: \# cannot find fixdep (/home/earnest/linux/tools/objtool//fixdep) \# using basic dep data This is because `tools/build/Build.include' prints these '\#' characters: printf '\# cannot find fixdep (%s)\n' $(fixdep) > $(dot-target).cmd; \ printf '\# using basic dep data\n\n' >> $(dot-target).cmd; \ This completes commit 9564a8cf422d ("Kbuild: fix # escaping in .cmd files for future Make"). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: stable@vger.kernel.org Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-12ARM: dts: am3517.dtsi: Disable reference to OMAP3 OTG controllerAdam Ford1-0/+5
The AM3517 has a different OTG controller location than the OMAP3, which is included from omap3.dtsi. This results in a hwmod error. Since the AM3517 has a different OTG controller address, this patch disabes one that is isn't available. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-07-12ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary coresNishanth Menon1-0/+41
Call secure services to enable ACTLR[0] (Enable invalidates of BTB with ICIALLU) when branch hardening is enabled for kernel. On GP devices OMAP5/DRA7, there is no possibility to update secure side since "secure world" is ROM and there are no override mechanisms possible. On HS devices, appropriate PPA should do the workarounds as well. However, the configuration is only done for secondary core, since it is expected that firmware/bootloader will have enabled the required configuration for the primary boot core (note: bootloaders typically will NOT enable secondary processors, since it has no need to do so). Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-07-12xen: remove global bit from __default_kernel_pte_mask for pv guestsJuergen Gross1-0/+1
When removing the global bit from __supported_pte_mask do the same for __default_kernel_pte_mask in order to avoid the WARN_ONCE() in check_pgprot() when setting a kernel pte before having called init_mem_mapping(). Cc: <stable@vger.kernel.org> # 4.17 Reported-by: Michael Young <m.a.young@durham.ac.uk> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2018-07-12ALSA: hda/ca0132: Update a pci quirk device nameAlastair Bridgewater1-1/+1
The PCI subsystem in question for this quirk rule has been identified as a Gigabyte GA-Z170X-Gaming 7 motherboard. Set the device name appropriately. Signed-off-by: Alastair Bridgewater <alastair.bridgewater@gmail.com> Reviewed-by: Connor McAdams <conmanx360@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-07-12ALSA: hda/ca0132: Add Recon3Di quirk for Gigabyte G1.Sniper Z97Alastair Bridgewater1-0/+1
These motherboards have Sound Core3D and apparently "support" Recon3Di. Added to the quirk list as QUIRK_R3DI. Issue report, PCI Subsystem ID, and testing by a contributor on IRC who wished to remain anonymous. Signed-off-by: Alastair Bridgewater <alastair.bridgewater@gmail.com> Reviewed-by: Connor McAdams <conmanx360@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.