1. 30 May, 2018 40 commits
    • Yonghong Song's avatar
      bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y · ee4bba56
      Yonghong Song authored
      [ Upstream commit 09584b40 ]
      
      With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file,
      tools/testing/selftests/bpf/test_kmod.sh failed like below:
        [root@localhost bpf]# ./test_kmod.sh
        sysctl: setting key "net.core.bpf_jit_enable": Invalid argument
        [ JIT enabled:0 hardened:0 ]
        [  132.175681] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  132.458834] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [ JIT enabled:1 hardened:0 ]
        [  133.456025] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  133.730935] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [ JIT enabled:1 hardened:1 ]
        [  134.769730] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  135.050864] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [ JIT enabled:1 hardened:2 ]
        [  136.442882] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
        [  136.821810] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
        [root@localhost bpf]#
      
      The test_kmod.sh load/remove test_bpf.ko multiple times with different
      settings for sysctl net.core.bpf_jit_{enable,harden}. The failed test #297
      of test_bpf.ko is designed such that JIT always fails.
      
      Commit 290af866 (bpf: introduce BPF_JIT_ALWAYS_ON config)
      introduced the following tightening logic:
          ...
              if (!bpf_prog_is_dev_bound(fp->aux)) {
                      fp = bpf_int_jit_compile(fp);
          #ifdef CONFIG_BPF_JIT_ALWAYS_ON
                      if (!fp->jited) {
                              *err = -ENOTSUPP;
                              return fp;
                      }
          #endif
          ...
      With this logic, Test #297 always gets return value -ENOTSUPP
      when CONFIG_BPF_JIT_ALWAYS_ON is defined, causing the test failure.
      
      This patch fixed the failure by marking Test #297 as expected failure
      when CONFIG_BPF_JIT_ALWAYS_ON is defined.
      
      Fixes: 290af866 (bpf: introduce BPF_JIT_ALWAYS_ON config)
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee4bba56
    • Hans de Goede's avatar
      ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs · cbaf06cc
      Hans de Goede authored
      [ Upstream commit 63347db0 ]
      
      The acpi_get_bus_status wrapper for acpi_bus_get_status_handle has some
      code to handle certain device quirks, in some cases we also need this
      quirk handling for the initial _STA call.
      
      Specifically on some devices calling _STA before all _DEP dependencies
      are met results in errors like these:
      
      [    0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c)
                     [GenericSerialBus] (20170831/evregion-166)
      [    0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler
                     (20170831/exfldio-299)
      [    0.123618] ACPI Error: Method parse/execution failed
                     \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)
      
      acpi_get_bus_status already has code to avoid this, so by using it we
      also silence these errors from the initial _STA call.
      
      Note that in order for the acpi_get_bus_status handling for this to work,
      we initialize dep_unmet to 1 until acpi_device_dep_initialize gets called,
      this means that battery devices will be instantiated with an initial
      status of 0. This is not a problem, acpi_bus_attach will get called soon
      after the instantiation anyways and it will update the status as first
      point of order.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cbaf06cc
    • Chen Yu's avatar
      ACPI: processor_perflib: Do not send _PPC change notification if not ready · 9a18bac1
      Chen Yu authored
      [ Upstream commit ba1edb9a ]
      
      The following warning was triggered after resumed from S3 -
      if all the nonboot CPUs were put offline before suspend:
      
      [ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 0xffffffff86061e3a (native_read_msr+0xa/0x30)
      [ 1840.329516] Call Trace:
      [ 1840.329521]  __rdmsr_on_cpu+0x33/0x50
      [ 1840.329525]  generic_exec_single+0x81/0xb0
      [ 1840.329527]  smp_call_function_single+0xd2/0x100
      [ 1840.329530]  ? acpi_ds_result_pop+0xdd/0xf2
      [ 1840.329532]  ? acpi_ds_create_operand+0x215/0x23c
      [ 1840.329534]  rdmsrl_on_cpu+0x57/0x80
      [ 1840.329536]  ? cpumask_next+0x1b/0x20
      [ 1840.329538]  ? rdmsrl_on_cpu+0x57/0x80
      [ 1840.329541]  intel_pstate_update_perf_limits+0xf3/0x220
      [ 1840.329544]  ? notifier_call_chain+0x4a/0x70
      [ 1840.329546]  intel_pstate_set_policy+0x4e/0x150
      [ 1840.329548]  cpufreq_set_policy+0xcd/0x2f0
      [ 1840.329550]  cpufreq_update_policy+0xb2/0x130
      [ 1840.329552]  ? cpufreq_update_policy+0x130/0x130
      [ 1840.329556]  acpi_processor_ppc_has_changed+0x65/0x80
      [ 1840.329558]  acpi_processor_notify+0x80/0x100
      [ 1840.329561]  acpi_ev_notify_dispatch+0x44/0x5c
      [ 1840.329563]  acpi_os_execute_deferred+0x14/0x20
      [ 1840.329565]  process_one_work+0x193/0x3c0
      [ 1840.329567]  worker_thread+0x35/0x3b0
      [ 1840.329569]  kthread+0x125/0x140
      [ 1840.329571]  ? process_one_work+0x3c0/0x3c0
      [ 1840.329572]  ? kthread_park+0x60/0x60
      [ 1840.329575]  ? do_syscall_64+0x67/0x180
      [ 1840.329577]  ret_from_fork+0x25/0x30
      [ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 0x0000000000000000) at rIP: 0xffffffff86061f78 (native_write_msr+0x8/0x30)
      [ 1840.329586] Call Trace:
      [ 1840.329587]  __wrmsr_on_cpu+0x37/0x40
      [ 1840.329589]  generic_exec_single+0x81/0xb0
      [ 1840.329592]  smp_call_function_single+0xd2/0x100
      [ 1840.329594]  ? acpi_ds_create_operand+0x215/0x23c
      [ 1840.329595]  ? cpumask_next+0x1b/0x20
      [ 1840.329597]  wrmsrl_on_cpu+0x57/0x70
      [ 1840.329598]  ? rdmsrl_on_cpu+0x57/0x80
      [ 1840.329599]  ? wrmsrl_on_cpu+0x57/0x70
      [ 1840.329602]  intel_pstate_hwp_set+0xd3/0x150
      [ 1840.329604]  intel_pstate_set_policy+0x119/0x150
      [ 1840.329606]  cpufreq_set_policy+0xcd/0x2f0
      [ 1840.329607]  cpufreq_update_policy+0xb2/0x130
      [ 1840.329610]  ? cpufreq_update_policy+0x130/0x130
      [ 1840.329613]  acpi_processor_ppc_has_changed+0x65/0x80
      [ 1840.329615]  acpi_processor_notify+0x80/0x100
      [ 1840.329617]  acpi_ev_notify_dispatch+0x44/0x5c
      [ 1840.329619]  acpi_os_execute_deferred+0x14/0x20
      [ 1840.329620]  process_one_work+0x193/0x3c0
      [ 1840.329622]  worker_thread+0x35/0x3b0
      [ 1840.329624]  kthread+0x125/0x140
      [ 1840.329625]  ? process_one_work+0x3c0/0x3c0
      [ 1840.329626]  ? kthread_park+0x60/0x60
      [ 1840.329628]  ? do_syscall_64+0x67/0x180
      [ 1840.329631]  ret_from_fork+0x25/0x30
      
      This is because if there's only one online CPU, the MSR_PM_ENABLE
      (package wide)can not be enabled after resumed, due to
      intel_pstate_hwp_enable() will only be invoked on AP's online
      process after resumed - if there's no AP online, the HWP remains
      disabled after resumed (BIOS has disabled it in S3). Then if
      there comes a _PPC change notification which touches HWP register
      during this stage, the warning is triggered.
      
      Since we don't call acpi_processor_register_performance() when
      HWP is enabled, the pr->performance will be NULL. When this is
      NULL we don't need to do _PPC change notification.
      Reported-by: default avatarDoug Smythies <dsmythies@telus.net>
      Suggested-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarYu Chen <yu.c.chen@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9a18bac1
    • Jean Delvare's avatar
      firmware: dmi_scan: Fix handling of empty DMI strings · 6fdca0dc
      Jean Delvare authored
      [ Upstream commit a7770ae1 ]
      
      The handling of empty DMI strings looks quite broken to me:
      * Strings from 1 to 7 spaces are not considered empty.
      * True empty DMI strings (string index set to 0) are not considered
        empty, and result in allocating a 0-char string.
      * Strings with invalid index also result in allocating a 0-char
        string.
      * Strings starting with 8 spaces are all considered empty, even if
        non-space characters follow (sounds like a weird thing to do, but
        I have actually seen occurrences of this in DMI tables before.)
      * Strings which are considered empty are reported as 8 spaces,
        instead of being actually empty.
      
      Some of these issues are the result of an off-by-one error in memcmp,
      the rest is incorrect by design.
      
      So let's get it square: missing strings and strings made of only
      spaces, regardless of their length, should be treated as empty and
      no memory should be allocated for them. All other strings are
      non-empty and should be allocated.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Fixes: 79da4721 ("x86: fix DMI out of memory problems")
      Cc: Parag Warudkar <parag.warudkar@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fdca0dc
    • Arnd Bergmann's avatar
      x86/power: Fix swsusp_arch_resume prototype · b2e949bf
      Arnd Bergmann authored
      [ Upstream commit 328008a7 ]
      
      The declaration for swsusp_arch_resume marks it as 'asmlinkage', but the
      definition in x86-32 does not, and it fails to include the header with the
      declaration. This leads to a warning when building with
      link-time-optimizations:
      
      kernel/power/power.h:108:23: error: type of 'swsusp_arch_resume' does not match original declaration [-Werror=lto-type-mismatch]
       extern asmlinkage int swsusp_arch_resume(void);
                             ^
      arch/x86/power/hibernate_32.c:148:0: note: 'swsusp_arch_resume' was previously declared here
       int swsusp_arch_resume(void)
      
      This moves the declaration into a globally visible header file and fixes up
      both x86 definitions to match it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: linux-pm@vger.kernel.org
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Link: https://lkml.kernel.org/r/20180202145634.200291-2-arnd@arndb.deSigned-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2e949bf
    • Subash Abhinov Kasiviswanathan's avatar
      netfilter: ipv6: nf_defrag: Kill frag queue on RFC2460 failure · dd5968e8
      Subash Abhinov Kasiviswanathan authored
      [ Upstream commit ea23d5e3 ]
      
      Failures were seen in ICMPv6 fragmentation timeout tests if they were
      run after the RFC2460 failure tests. Kernel was not sending out the
      ICMPv6 fragment reassembly time exceeded packet after the fragmentation
      reassembly timeout of 1 minute had elapsed.
      
      This happened because the frag queue was not released if an error in
      IPv6 fragmentation header was detected by RFC2460.
      
      Fixes: 83f1999c ("netfilter: ipv6: nf_defrag: Pass on packets to stack per RFC2460")
      Signed-off-by: default avatarSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd5968e8
    • Karol Herbst's avatar
      drm/nouveau/pmu/fuc: don't use movw directly anymore · e7bce211
      Karol Herbst authored
      [ Upstream commit fe9748b7 ]
      
      Fixes failure to compile with recent envyas as a result of the 'movw'
      alias being removed for v5.
      
      A bit of history:
      
      v3 only has a 16-bit sign-extended immediate mov op. In order to set
      the high bits, there's a separate 'sethi' op. envyas validates that
      the value passed to mov(imm) is between -0x8000 and 0x7fff. In order
      to simplify macros that load both the low and high word, a 'movw'
      alias was added which takes an unsigned 16-bit immediate. However the
      actual hardware op still sign extends.
      
      v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op
      is gone (loads 0 into the dst reg). However due to a bug in envyas,
      the movw alias still existed, and selected the no-longer-present v3
      16-bit immediate mov op. As a result usage of movw on v5 is the same
      as mov with a 0x0 argument.
      
      The proper fix throughout is to only ever use the 'movw' alias in
      combination with 'sethi'. Anything else should get the sign-extended
      validation to ensure that the intended value ends up in the
      destination register.
      
      Changes in fuc3 binaries is the result of a different encoding being
      selected for a mov with an 8-bit value.
      
      v2: added commit message written by Ilia, thanks for that!
      v3: messed up rebasing, now it should apply
      Signed-off-by: default avatarKarol Herbst <kherbst@redhat.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7bce211
    • Alex Estrin's avatar
      IB/ipoib: Fix for potential no-carrier state · e405d2eb
      Alex Estrin authored
      [ Upstream commit 10293610 ]
      
      On reboot SM can program port pkey table before ipoib registered its
      event handler, which could result in missing pkey event and leave root
      interface with initial pkey value from index 0.
      
      Since OPA port starts with invalid pkey in index 0, root interface will
      fail to initialize and stay down with no-carrier flag.
      
      For IB ipoib interface may end up with pkey different from value
      opensm put in pkey table idx 0, resulting in connectivity issues
      (different mcast groups, for example).
      
      Close the window by calling event handler after registration
      to make sure ipoib pkey is in sync with port pkey table.
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Signed-off-by: default avatarAlex Estrin <alex.estrin@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e405d2eb
    • Ed Swierk's avatar
      openvswitch: Remove padding from packet before L3+ conntrack processing · bfd188fb
      Ed Swierk authored
      [ Upstream commit 9382fe71 ]
      
      IPv4 and IPv6 packets may arrive with lower-layer padding that is not
      included in the L3 length. For example, a short IPv4 packet may have
      up to 6 bytes of padding following the IP payload when received on an
      Ethernet device with a minimum packet length of 64 bytes.
      
      Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(),
      and help() in nf_conntrack_ftp) assume skb->len reflects the length of
      the L3 header and payload, rather than referring back to
      ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by
      lower-layer padding.
      
      In the normal IPv4 receive path, ip_rcv() trims the packet to
      ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive
      path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly
      in the br_netfilter receive path, br_validate_ipv4() and
      br_validate_ipv6() trim the packet to the L3 length before invoking
      netfilter hooks.
      
      Currently in the OVS conntrack receive path, ovs_ct_execute() pulls
      the skb to the L3 header but does not trim it to the L3 length before
      calling nf_conntrack_in(NF_INET_PRE_ROUTING). When
      nf_conntrack_proto_tcp encounters a packet with lower-layer padding,
      nf_ip_checksum() fails causing a "nf_ct_tcp: bad TCP checksum" log
      message. While extra zero bytes don't affect the checksum, the length
      in the IP pseudoheader does. That length is based on skb->len, and
      without trimming, it doesn't match the length the sender used when
      computing the checksum.
      
      In ovs_ct_execute(), trim the skb to the L3 length before higher-layer
      processing.
      Signed-off-by: default avatarEd Swierk <eswierk@skyportsystems.com>
      Acked-by: default avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfd188fb
    • shidao.ytt's avatar
      mm/fadvise: discard partial page if endbyte is also EOF · a8b21508
      shidao.ytt authored
      [ Upstream commit a7ab400d ]
      
      During our recent testing with fadvise(FADV_DONTNEED), we find that if
      given offset/length is not page-aligned, the last page will not be
      discarded.  The tool we use is vmtouch (https://hoytech.com/vmtouch/),
      we map a 10KB-sized file into memory and then try to run this tool to
      evict the whole file mapping, but the last single page always remains
      staying in the memory:
      
      $./vmtouch -e test_10K
                 Files: 1
           Directories: 0
         Evicted Pages: 3 (12K)
               Elapsed: 2.1e-05 seconds
      
      $./vmtouch test_10K
                 Files: 1
           Directories: 0
        Resident Pages: 1/3  4K/12K  33.3%
               Elapsed: 5.5e-05 seconds
      
      However when we test with an older kernel, say 3.10, this problem is
      gone.  So we wonder if this is a regression:
      
      $./vmtouch -e test_10K
                 Files: 1
           Directories: 0
         Evicted Pages: 3 (12K)
               Elapsed: 8.2e-05 seconds
      
      $./vmtouch test_10K
                 Files: 1
           Directories: 0
        Resident Pages: 0/3  0/12K  0%  <-- partial page also discarded
               Elapsed: 5e-05 seconds
      
      After digging a little bit into this problem, we find it seems not a
      regression.  Not discarding partial page is likely to be on purpose
      according to commit 441c228f ("mm: fadvise: document the
      fadvise(FADV_DONTNEED) behaviour for partial pages") written by Mel
      Gorman.  He explained why partial pages should be preserved instead of
      being discarded when using fadvise(FADV_DONTNEED).
      
      However, the interesting part is that the actual code did NOT work as
      the same as it was described, the partial page was still discarded
      anyway, due to a calculation mistake of `end_index' passed to
      invalidate_mapping_pages().  This mistake has not been fixed until
      recently, that's why we fail to reproduce our problem in old kernels.
      The fix is done in commit 18aba41c ("mm/fadvise.c: do not discard
      partial pages with POSIX_FADV_DONTNEED") by Oleg Drokin.
      
      Back to the original testing, our problem becomes that there is a
      special case that, if the page-unaligned `endbyte' is also the end of
      file, it is not necessary at all to preserve the last partial page, as
      we all know no one else will use the rest of it.  It should be safe
      enough if we just discard the whole page.  So we add an EOF check in
      this patch.
      
      We also find a poosbile real world issue in mainline kernel.  Assume
      such scenario: A userspace backup application want to backup a huge
      amount of small files (<4k) at once, the developer might (I guess) want
      to use fadvise(FADV_DONTNEED) to save memory.  However, FADV_DONTNEED
      won't really happen since the only page mapped is a partial page, and
      kernel will preserve it.  Our patch also fixes this problem, since we
      know the endbyte is EOF, so we discard it.
      
      Here is a simple reproducer to reproduce and verify each scenario we
      described above:
      
        test_fadvise.c
        ==============================
        #include <sys/mman.h>
        #include <sys/stat.h>
        #include <fcntl.h>
        #include <stdlib.h>
        #include <string.h>
        #include <stdio.h>
        #include <unistd.h>
      
        int main(int argc, char **argv)
        {
        	int i, fd, ret, len;
        	struct stat buf;
        	void *addr;
        	unsigned char *vec;
        	char *strbuf;
        	ssize_t pagesize = getpagesize();
        	ssize_t filesize;
      
        	fd = open(argv[1], O_RDWR|O_CREAT, S_IRUSR|S_IWUSR);
        	if (fd < 0)
        		return -1;
        	filesize = strtoul(argv[2], NULL, 10);
      
        	strbuf = malloc(filesize);
        	memset(strbuf, 42, filesize);
        	write(fd, strbuf, filesize);
        	free(strbuf);
        	fsync(fd);
      
        	len = (filesize + pagesize - 1) / pagesize;
        	printf("length of pages: %d\n", len);
      
        	addr = mmap(NULL, filesize, PROT_READ, MAP_SHARED, fd, 0);
        	if (addr == MAP_FAILED)
        		return -1;
      
        	ret = posix_fadvise(fd, 0, filesize, POSIX_FADV_DONTNEED);
        	if (ret < 0)
        		return -1;
      
        	vec = malloc(len);
        	ret = mincore(addr, filesize, (void *)vec);
        	if (ret < 0)
        		return -1;
      
        	for (i = 0; i < len; i++)
        		printf("pages[%d]: %x\n", i, vec[i] & 0x1);
      
        	free(vec);
        	close(fd);
      
        	return 0;
        }
        ==============================
      
      Test 1: running on kernel with commit 18aba41c reverted:
      
        [root@caspar ~]# uname -r
        4.15.0-rc6.revert+
        [root@caspar ~]# ./test_fadvise file1 1024
        length of pages: 1
        pages[0]: 0    # <-- partial page discarded
        [root@caspar ~]# ./test_fadvise file2 8192
        length of pages: 2
        pages[0]: 0
        pages[1]: 0
        [root@caspar ~]# ./test_fadvise file3 10240
        length of pages: 3
        pages[0]: 0
        pages[1]: 0
        pages[2]: 0    # <-- partial page discarded
      
      Test 2: running on mainline kernel:
      
        [root@caspar ~]# uname -r
        4.15.0-rc6+
        [root@caspar ~]# ./test_fadvise test1 1024
        length of pages: 1
        pages[0]: 1    # <-- partial and the only page not discarded
        [root@caspar ~]# ./test_fadvise test2 8192
        length of pages: 2
        pages[0]: 0
        pages[1]: 0
        [root@caspar ~]# ./test_fadvise test3 10240
        length of pages: 3
        pages[0]: 0
        pages[1]: 0
        pages[2]: 1    # <-- partial page not discarded
      
      Test 3: running on kernel with this patch:
      
        [root@caspar ~]# uname -r
        4.15.0-rc6.patched+
        [root@caspar ~]# ./test_fadvise test1 1024
        length of pages: 1
        pages[0]: 0    # <-- partial page and EOF, discarded
        [root@caspar ~]# ./test_fadvise test2 8192
        length of pages: 2
        pages[0]: 0
        pages[1]: 0
        [root@caspar ~]# ./test_fadvise test3 10240
        length of pages: 3
        pages[0]: 0
        pages[1]: 0
        pages[2]: 0    # <-- partial page and EOF, discarded
      
      [akpm@linux-foundation.org: tweak code comment]
      Link: http://lkml.kernel.org/r/5222da9ee20e1695eaabb69f631f200d6e6b8876.1515132470.git.jinli.zjl@alibaba-inc.comSigned-off-by: default avatarshidao.ytt <shidao.ytt@alibaba-inc.com>
      Signed-off-by: default avatarCaspar Zhang <jinli.zjl@alibaba-inc.com>
      Reviewed-by: default avatarOliver Yang <zhiche.yy@alibaba-inc.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8b21508
    • Mel Gorman's avatar
      mm: pin address_space before dereferencing it while isolating an LRU page · ab88b8a2
      Mel Gorman authored
      [ Upstream commit 69d763fc ]
      
      Minchan Kim asked the following question -- what locks protects
      address_space destroying when race happens between inode trauncation and
      __isolate_lru_page? Jan Kara clarified by describing the race as follows
      
      CPU1                                            CPU2
      
      truncate(inode)                                 __isolate_lru_page()
        ...
        truncate_inode_page(mapping, page);
          delete_from_page_cache(page)
            spin_lock_irqsave(&mapping->tree_lock, flags);
              __delete_from_page_cache(page, NULL)
                page_cache_tree_delete(..)
                  ...                                   mapping = page_mapping(page);
                  page->mapping = NULL;
                  ...
            spin_unlock_irqrestore(&mapping->tree_lock, flags);
            page_cache_free_page(mapping, page)
              put_page(page)
                if (put_page_testzero(page)) -> false
      - inode now has no pages and can be freed including embedded address_space
      
                                                        if (mapping && !mapping->a_ops->migratepage)
      - we've dereferenced mapping which is potentially already free.
      
      The race is theoretically possible but unlikely.  Before the
      delete_from_page_cache, truncate_cleanup_page is called so the page is
      likely to be !PageDirty or PageWriteback which gets skipped by the only
      caller that checks the mappping in __isolate_lru_page.  Even if the race
      occurs, a substantial amount of work has to happen during a tiny window
      with no preemption but it could potentially be done using a virtual
      machine to artifically slow one CPU or halt it during the critical
      window.
      
      This patch should eliminate the race with truncation by try-locking the
      page before derefencing mapping and aborting if the lock was not
      acquired.  There was a suggestion from Huang Ying to use RCU as a
      side-effect to prevent mapping being freed.  However, I do not like the
      solution as it's an unconventional means of preserving a mapping and
      it's not a context where rcu_read_lock is obviously protecting rcu data.
      
      Link: http://lkml.kernel.org/r/20180104102512.2qos3h5vqzeisrek@techsingularity.net
      Fixes: c8244935 ("mm: compaction: make isolate_lru_page() filter-aware again")
      Signed-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Acked-by: default avatarMinchan Kim <minchan@kernel.org>
      Cc: "Huang, Ying" <ying.huang@intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab88b8a2
    • Yang Shi's avatar
      mm: thp: use down_read_trylock() in khugepaged to avoid long block · e56d3700
      Yang Shi authored
      [ Upstream commit 3b454ad3 ]
      
      In the current design, khugepaged needs to acquire mmap_sem before
      scanning an mm.  But in some corner cases, khugepaged may scan a process
      which is modifying its memory mapping, so khugepaged blocks in
      uninterruptible state.  But the process might hold the mmap_sem for a
      long time when modifying a huge memory space and it may trigger the
      below khugepaged hung issue:
      
        INFO: task khugepaged:270 blocked for more than 120 seconds.
        Tainted: G E 4.9.65-006.ali3000.alios7.x86_64 #1
        "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
        khugepaged D 0 270 2 0x00000000 
        ffff883f3deae4c0 0000000000000000 ffff883f610596c0 ffff883f7d359440
        ffff883f63818000 ffffc90019adfc78 ffffffff817079a5 d67e5aa8c1860a64
        0000000000000246 ffff883f7d359440 ffffc90019adfc88 ffff883f610596c0
        Call Trace:
          schedule+0x36/0x80
          rwsem_down_read_failed+0xf0/0x150
          call_rwsem_down_read_failed+0x18/0x30
          down_read+0x20/0x40
          khugepaged+0x476/0x11d0
          kthread+0xe6/0x100
          ret_from_fork+0x25/0x30
      
      So it sounds pointless to just block khugepaged waiting for the
      semaphore so replace down_read() with down_read_trylock() to move to
      scan the next mm quickly instead of just blocking on the semaphore so
      that other processes can get more chances to install THP.  Then
      khugepaged can come back to scan the skipped mm when it has finished the
      current round full_scan.
      
      And it appears that the change can improve khugepaged efficiency a
      little bit.
      
      Below is the test result when running LTP on a 24 cores 4GB memory 2
      nodes NUMA VM:
      
                                          pristine          w/ trylock
        full_scan                         197               187
        pages_collapsed                   21                26
        thp_fault_alloc                   40818             44466
        thp_fault_fallback                18413             16679
        thp_collapse_alloc                21                150
        thp_collapse_alloc_failed         14                16
        thp_file_alloc                    369               369
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: tweak comment]
      [arnd@arndb.de: avoid uninitialized variable use]
        Link: http://lkml.kernel.org/r/20171215125129.2948634-1-arnd@arndb.de
      Link: http://lkml.kernel.org/r/1513281203-54878-1-git-send-email-yang.s@alibaba-inc.comSigned-off-by: default avatarYang Shi <yang.s@alibaba-inc.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e56d3700
    • Nitin Gupta's avatar
      sparc64: update pmdp_invalidate() to return old pmd value · 9da97a95
      Nitin Gupta authored
      [ Upstream commit a8e654f0 ]
      
      It's required to avoid losing dirty and accessed bits.
      
      [akpm@linux-foundation.org: add a `do' to the do-while loop]
      Link: http://lkml.kernel.org/r/20171213105756.69879-9-kirill.shutemov@linux.intel.comSigned-off-by: default avatarNitin Gupta <nitin.m.gupta@oracle.com>
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9da97a95
    • Kirill A. Shutemov's avatar
      asm-generic: provide generic_pmdp_establish() · 038ab51e
      Kirill A. Shutemov authored
      [ Upstream commit c58f0bb7 ]
      
      Patch series "Do not lose dirty bit on THP pages", v4.
      
      Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
      dirty and access bits if CPU sets them after pmdp dereference, but
      before set_pmd_at().
      
      The bug can lead to data loss, but the race window is tiny and I haven't
      seen any reports that suggested that it happens in reality.  So I don't
      think it worth sending it to stable.
      
      Unfortunately, there's no way to address the issue in a generic way.  We
      need to fix all architectures that support THP one-by-one.
      
      All architectures that have THP supported have to provide atomic
      pmdp_invalidate() that returns previous value.
      
      If generic implementation of pmdp_invalidate() is used, architecture
      needs to provide atomic pmdp_estabish().
      
      pmdp_estabish() is not used out-side generic implementation of
      pmdp_invalidate() so far, but I think this can change in the future.
      
      This patch (of 12):
      
      This is an implementation of pmdp_establish() that is only suitable for
      an architecture that doesn't have hardware dirty/accessed bits.  In this
      case we can't race with CPU which sets these bits and non-atomic
      approach is fine.
      
      Link: http://lkml.kernel.org/r/20171213105756.69879-2-kirill.shutemov@linux.intel.comSigned-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nitin Gupta <nitin.m.gupta@oracle.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      038ab51e
    • Yisheng Xie's avatar
      mm/mempolicy: add nodes_empty check in SYSC_migrate_pages · 4cf2463f
      Yisheng Xie authored
      [ Upstream commit 0486a38b ]
      
      As in manpage of migrate_pages, the errno should be set to EINVAL when
      none of the node IDs specified by new_nodes are on-line and allowed by
      the process's current cpuset context, or none of the specified nodes
      contain memory.  However, when test by following case:
      
      	new_nodes = 0;
      	old_nodes = 0xf;
      	ret = migrate_pages(pid, old_nodes, new_nodes, MAX);
      
      The ret will be 0 and no errno is set.  As the new_nodes is empty, we
      should expect EINVAL as documented.
      
      To fix the case like above, this patch check whether target nodes AND
      current task_nodes is empty, and then check whether AND
      node_states[N_MEMORY] is empty.
      
      Link: http://lkml.kernel.org/r/1510882624-44342-4-git-send-email-xieyisheng1@huawei.comSigned-off-by: default avatarYisheng Xie <xieyisheng1@huawei.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Chris Salls <salls@cs.ucsb.edu>
      Cc: Christopher Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Tan Xiaojun <tanxiaojun@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cf2463f
    • Yisheng Xie's avatar
      mm/mempolicy: fix the check of nodemask from user · 2851e3bd
      Yisheng Xie authored
      [ Upstream commit 56521e7a ]
      
      As Xiaojun reported the ltp of migrate_pages01 will fail on arm64 system
      which has 4 nodes[0...3], all have memory and CONFIG_NODES_SHIFT=2:
      
        migrate_pages01    0  TINFO  :  test_invalid_nodes
        migrate_pages01   14  TFAIL  :  migrate_pages_common.c:45: unexpected failure - returned value = 0, expected: -1
        migrate_pages01   15  TFAIL  :  migrate_pages_common.c:55: call succeeded unexpectedly
      
      In this case the test_invalid_nodes of migrate_pages01 will call:
      SYSC_migrate_pages as:
      
        migrate_pages(0, , {0x0000000000000001}, 64, , {0x0000000000000010}, 64) = 0
      
      The new nodes specifies one or more node IDs that are greater than the
      maximum supported node ID, however, the errno is not set to EINVAL as
      expected.
      
      As man pages of set_mempolicy[1], mbind[2], and migrate_pages[3]
      mentioned, when nodemask specifies one or more node IDs that are greater
      than the maximum supported node ID, the errno should set to EINVAL.
      However, get_nodes only check whether the part of bits
      [BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES), maxnode) is zero or not, and
      remain [MAX_NUMNODES, BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES)
      unchecked.
      
      This patch is to check the bits of [MAX_NUMNODES, maxnode) in get_nodes
      to let migrate_pages set the errno to EINVAL when nodemask specifies one
      or more node IDs that are greater than the maximum supported node ID,
      which follows the manpage's guide.
      
      [1] http://man7.org/linux/man-pages/man2/set_mempolicy.2.html
      [2] http://man7.org/linux/man-pages/man2/mbind.2.html
      [3] http://man7.org/linux/man-pages/man2/migrate_pages.2.html
      
      Link: http://lkml.kernel.org/r/1510882624-44342-3-git-send-email-xieyisheng1@huawei.comSigned-off-by: default avatarYisheng Xie <xieyisheng1@huawei.com>
      Reported-by: default avatarTan Xiaojun <tanxiaojun@huawei.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Chris Salls <salls@cs.ucsb.edu>
      Cc: Christopher Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2851e3bd
    • piaojun's avatar
      ocfs2: return error when we attempt to access a dirty bh in jbd2 · 9f5efe59
      piaojun authored
      [ Upstream commit d984187e ]
      
      We should not reuse the dirty bh in jbd2 directly due to the following
      situation:
      
      1. When removing extent rec, we will dirty the bhs of extent rec and
         truncate log at the same time, and hand them over to jbd2.
      
      2. The bhs are submitted to jbd2 area successfully.
      
      3. The write-back thread of device help flush the bhs to disk but
         encounter write error due to abnormal storage link.
      
      4. After a while the storage link become normal. Truncate log flush
         worker triggered by the next space reclaiming found the dirty bh of
         truncate log and clear its 'BH_Write_EIO' and then set it uptodate in
         __ocfs2_journal_access():
      
         ocfs2_truncate_log_worker
           ocfs2_flush_truncate_log
             __ocfs2_flush_truncate_log
               ocfs2_replay_truncate_records
                 ocfs2_journal_access_di
                   __ocfs2_journal_access // here we clear io_error and set 'tl_bh' uptodata.
      
      5. Then jbd2 will flush the bh of truncate log to disk, but the bh of
         extent rec is still in error state, and unfortunately nobody will
         take care of it.
      
      6. At last the space of extent rec was not reduced, but truncate log
         flush worker have given it back to globalalloc. That will cause
         duplicate cluster problem which could be identified by fsck.ocfs2.
      
      Sadly we can hardly revert this but set fs read-only in case of ruining
      atomicity and consistency of space reclaim.
      
      Link: http://lkml.kernel.org/r/5A6E8092.8090701@huawei.com
      Fixes: acf8fdbe ("ocfs2: do not BUG if buffer not uptodate in __ocfs2_journal_access")
      Signed-off-by: default avatarJun Piao <piaojun@huawei.com>
      Reviewed-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Reviewed-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f5efe59
    • piaojun's avatar
      ocfs2/acl: use 'ip_xattr_sem' to protect getting extended attribute · 1d5fdc13
      piaojun authored
      [ Upstream commit 16c8d569 ]
      
      The race between *set_acl and *get_acl will cause getting incomplete
      xattr data as below:
      
        processA                                    processB
      
        ocfs2_set_acl
          ocfs2_xattr_set
            __ocfs2_xattr_set_handle
      
                                                    ocfs2_get_acl_nolock
                                                      ocfs2_xattr_get_nolock:
      
      processB may get incomplete xattr data if processA hasn't set_acl done.
      
      So we should use 'ip_xattr_sem' to protect getting extended attribute in
      ocfs2_get_acl_nolock(), as other processes could be changing it
      concurrently.
      
      Link: http://lkml.kernel.org/r/5A5DDCFF.7030001@huawei.comSigned-off-by: default avatarJun Piao <piaojun@huawei.com>
      Reviewed-by: default avatarAlex Chen <alex.chen@huawei.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: Changwei Ge <ge.changwei@h3c.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d5fdc13
    • piaojun's avatar
      ocfs2: return -EROFS to mount.ocfs2 if inode block is invalid · e2afc406
      piaojun authored
      [ Upstream commit 025bcbde ]
      
      If metadata is corrupted such as 'invalid inode block', we will get
      failed by calling 'mount()' and then set filesystem readonly as below:
      
        ocfs2_mount
          ocfs2_initialize_super
            ocfs2_init_global_system_inodes
              ocfs2_iget
                ocfs2_read_locked_inode
                  ocfs2_validate_inode_block
      	      ocfs2_error
      	        ocfs2_handle_error
      	          ocfs2_set_ro_flag(osb, 0);  // set readonly
      
      In this situation we need return -EROFS to 'mount.ocfs2', so that user
      can fix it by fsck.  And then mount again.  In addition, 'mount.ocfs2'
      should be updated correspondingly as it only return 1 for all errno.
      And I will post a patch for 'mount.ocfs2' too.
      
      Link: http://lkml.kernel.org/r/5A4302FA.2010606@huawei.comSigned-off-by: default avatarJun Piao <piaojun@huawei.com>
      Reviewed-by: default avatarAlex Chen <alex.chen@huawei.com>
      Reviewed-by: default avatarJoseph Qi <jiangqi903@gmail.com>
      Reviewed-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Reviewed-by: default avatarGang He <ghe@suse.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2afc406
    • KarimAllah Ahmed's avatar
      kvm: Map PFN-type memory regions as writable (if possible) · 9445fde8
      KarimAllah Ahmed authored
      [ Upstream commit a340b3e2 ]
      
      For EPT-violations that are triggered by a read, the pages are also mapped with
      write permissions (if their memory region is also writable). That would avoid
      getting yet another fault on the same page when a write occurs.
      
      This optimization only happens when you have a "struct page" backing the memory
      region. So also enable it for memory regions that do not have a "struct page".
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: kvm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarKarimAllah Ahmed <karahmed@amazon.de>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9445fde8
    • Gustavo A. R. Silva's avatar
      tcp_nv: fix potential integer overflow in tcpnv_acked · d805047b
      Gustavo A. R. Silva authored
      [ Upstream commit e4823fbd ]
      
      Add suffix ULL to constant 80000 in order to avoid a potential integer
      overflow and give the compiler complete information about the proper
      arithmetic to use. Notice that this constant is used in a context that
      expects an expression of type u64.
      
      The current cast to u64 effectively applies to the whole expression
      as an argument of type u64 to be passed to div64_u64, but it does
      not prevent it from being evaluated using 32-bit arithmetic instead
      of 64-bit arithmetic.
      
      Also, once the expression is properly evaluated using 64-bit arithmentic,
      there is no need for the parentheses and the external cast to u64.
      
      Addresses-Coverity-ID: 1357588 ("Unintentional integer overflow")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d805047b
    • Andy Spencer's avatar
      gianfar: prevent integer wrapping in the rx handler · eea27e5b
      Andy Spencer authored
      [ Upstream commit 202a0a70 ]
      
      When the frame check sequence (FCS) is split across the last two frames
      of a fragmented packet, part of the FCS gets counted twice, once when
      subtracting the FCS, and again when subtracting the previously received
      data.
      
      For example, if 1602 bytes are received, and the first fragment contains
      the first 1600 bytes (including the first two bytes of the FCS), and the
      second fragment contains the last two bytes of the FCS:
      
        'skb->len == 1600' from the first fragment
      
        size  = lstatus & BD_LENGTH_MASK; # 1602
        size -= ETH_FCS_LEN;              # 1598
        size -= skb->len;                 # -2
      
      Since the size is unsigned, it wraps around and causes a BUG later in
      the packet handling, as shown below:
      
        kernel BUG at ./include/linux/skbuff.h:2068!
        Oops: Exception in kernel mode, sig: 5 [#1]
        ...
        NIP [c021ec60] skb_pull+0x24/0x44
        LR [c01e2fbc] gfar_clean_rx_ring+0x498/0x690
        Call Trace:
        [df7edeb0] [c01e2c1c] gfar_clean_rx_ring+0xf8/0x690 (unreliable)
        [df7edf20] [c01e33a8] gfar_poll_rx_sq+0x3c/0x9c
        [df7edf40] [c023352c] net_rx_action+0x21c/0x274
        [df7edf90] [c0329000] __do_softirq+0xd8/0x240
        [df7edff0] [c000c108] call_do_irq+0x24/0x3c
        [c0597e90] [c00041dc] do_IRQ+0x64/0xc4
        [c0597eb0] [c000d920] ret_from_except+0x0/0x18
        --- interrupt: 501 at arch_cpu_idle+0x24/0x5c
      
      Change the size to a signed integer and then trim off any part of the
      FCS that was received prior to the last fragment.
      
      Fixes: 6c389fc9 ("gianfar: fix size of scatter-gathered frames")
      Signed-off-by: default avatarAndy Spencer <aspencer@spacex.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eea27e5b
    • Logan Gunthorpe's avatar
      ntb_transport: Fix bug with max_mw_size parameter · 33d353db
      Logan Gunthorpe authored
      [ Upstream commit cbd27448 ]
      
      When using the max_mw_size parameter of ntb_transport to limit the size of
      the Memory windows, communication cannot be established and the queues
      freeze.
      
      This is because the mw_size that's reported to the peer is correctly
      limited but the size used locally is not. So the MW is initialized
      with a buffer smaller than the window but the TX side is using the
      full window. This means the TX side will be writing to a region of the
      window that points nowhere.
      
      This is easily fixed by applying the same limit to tx_size in
      ntb_transport_init_queue().
      
      Fixes: e26a5843 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
      Signed-off-by: default avatarLogan Gunthorpe <logang@deltatee.com>
      Acked-by: default avatarAllen Hubbe <Allen.Hubbe@dell.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarJon Mason <jdmason@kudzu.us>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33d353db
    • Leon Romanovsky's avatar
      RDMA/mlx5: Avoid memory leak in case of XRCD dealloc failure · bdae32c7
      Leon Romanovsky authored
      [ Upstream commit b081808a ]
      
      Failure in XRCD FW deallocation command leaves memory leaked and
      returns error to the user which he can't do anything about it.
      
      This patch changes behavior to always free memory and always return
      success to the user.
      
      Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters")
      Reviewed-by: default avatarMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarYuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdae32c7
    • Michael Bringmann's avatar
      powerpc/numa: Ensure nodes initialized for hotplug · 2f2f95d9
      Michael Bringmann authored
      [ Upstream commit ea05ba7c ]
      
      This patch fixes some problems encountered at runtime with
      configurations that support memory-less nodes, or that hot-add CPUs
      into nodes that are memoryless during system execution after boot. The
      problems of interest include:
      
      * Nodes known to powerpc to be memoryless at boot, but to have CPUs in
        them are allowed to be 'possible' and 'online'. Memory allocations
        for those nodes are taken from another node that does have memory
        until and if memory is hot-added to the node.
      
      * Nodes which have no resources assigned at boot, but which may still
        be referenced subsequently by affinity or associativity attributes,
        are kept in the list of 'possible' nodes for powerpc. Hot-add of
        memory or CPUs to the system can reference these nodes and bring
        them online instead of redirecting the references to one of the set
        of nodes known to have memory at boot.
      
      Note that this software operates under the context of CPU hotplug. We
      are not doing memory hotplug in this code, but rather updating the
      kernel's CPU topology (i.e. arch_update_cpu_topology /
      numa_update_cpu_topology). We are initializing a node that may be used
      by CPUs or memory before it can be referenced as invalid by a CPU
      hotplug operation. CPU hotplug operations are protected by a range of
      APIs including cpu_maps_update_begin/cpu_maps_update_done,
      cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
      Memory hotplug operations, including try_online_node, are protected by
      mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
      case of CPUs being hot-added to a previously memoryless node, the
      try_online_node operation occurs wholly within the CPU locks with no
      overlap. Using HMC hot-add/hot-remove operations, we have been able to
      add and remove CPUs to any possible node without failures. HMC
      operations involve a degree self-serialization, though.
      Signed-off-by: default avatarMichael Bringmann <mwb@linux.vnet.ibm.com>
      Reviewed-by: default avatarNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f2f95d9
    • Michael Bringmann's avatar
      powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes · 6f9c15a3
      Michael Bringmann authored
      [ Upstream commit a346137e ]
      
      On powerpc systems which allow 'hot-add' of CPU or memory resources,
      it may occur that the new resources are to be inserted into nodes that
      were not used for these resources at bootup. In the kernel, any node
      that is used must be defined and initialized. These empty nodes may
      occur when,
      
      * Dedicated vs. shared resources. Shared resources require information
        such as the VPHN hcall for CPU assignment to nodes. Associativity
        decisions made based on dedicated resource rules, such as
        associativity properties in the device tree, may vary from decisions
        made using the values returned by the VPHN hcall.
      
      * memoryless nodes at boot. Nodes need to be defined as 'possible' at
        boot for operation with other code modules. Previously, the powerpc
        code would limit the set of possible nodes to those which have
        memory assigned at boot, and were thus online. Subsequent add/remove
        of CPUs or memory would only work with this subset of possible
        nodes.
      
      * memoryless nodes with CPUs at boot. Due to the previous restriction
        on nodes, nodes that had CPUs but no memory were being collapsed
        into other nodes that did have memory at boot. In practice this
        meant that the node assignment presented by the runtime kernel
        differed from the affinity and associativity attributes presented by
        the device tree or VPHN hcalls. Nodes that might be known to the
        pHyp were not 'possible' in the runtime kernel because they did not
        have memory at boot.
      
      This patch ensures that sufficient nodes are defined to support
      configuration requirements after boot, as well as at boot. This patch
      set fixes a couple of problems.
      
      * Nodes known to powerpc to be memoryless at boot, but to have CPUs in
        them are allowed to be 'possible' and 'online'. Memory allocations
        for those nodes are taken from another node that does have memory
        until and if memory is hot-added to the node. * Nodes which have no
        resources assigned at boot, but which may still be referenced
        subsequently by affinity or associativity attributes, are kept in
        the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
        to the system can reference these nodes and bring them online
        instead of redirecting to one of the set of nodes that were known to
        have memory at boot.
      
      This patch extracts the value of the lowest domain level (number of
      allocable resources) from the device tree property
      "ibm,max-associativity-domains" to use as the maximum number of nodes
      to setup as possibly available in the system. This new setting will
      override the instruction:
      
          nodes_and(node_possible_map, node_possible_map, node_online_map);
      
      presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
      
      If the "ibm,max-associativity-domains" property is not present at
      boot, no operation will be performed to define or enable additional
      nodes, or enable the above 'nodes_and()'.
      Signed-off-by: default avatarMichael Bringmann <mwb@linux.vnet.ibm.com>
      Reviewed-by: default avatarNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f9c15a3
    • Jake Daryll Obina's avatar
      jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path · b4754445
      Jake Daryll Obina authored
      [ Upstream commit 5bdd0c6f ]
      
      If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode()
      can get called twice in the error handling path, the first call in
      jffs2_iget() itself and the second through iget_failed(). This can result
      to a use-after-free error in the second jffs2_do_clear_inode() call, such
      as shown by the oops below wherein the second jffs2_do_clear_inode() call
      was trying to free node fragments that were already freed in the first
      jffs2_do_clear_inode() call.
      
      [   78.178860] jffs2: error: (1904) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 24 at physical location 0x1fc00c
      [   78.178914] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
      [   78.185871] pgd = ffffffc03a567000
      [   78.188794] [6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
      [   78.194968] Internal error: Oops: 96000004 [#1] PREEMPT SMP
      ...
      [   78.513147] PC is at rb_first_postorder+0xc/0x28
      [   78.516503] LR is at jffs2_kill_fragtree+0x28/0x90 [jffs2]
      [   78.520672] pc : [<ffffff8008323d28>] lr : [<ffffff8000eb1cc8>] pstate: 60000105
      [   78.526757] sp : ffffff800cea38f0
      [   78.528753] x29: ffffff800cea38f0 x28: ffffffc01f3f8e80
      [   78.532754] x27: 0000000000000000 x26: ffffff800cea3c70
      [   78.536756] x25: 00000000dc67c8ae x24: ffffffc033d6945d
      [   78.540759] x23: ffffffc036811740 x22: ffffff800891a5b8
      [   78.544760] x21: 0000000000000000 x20: 0000000000000000
      [   78.548762] x19: ffffffc037d48910 x18: ffffff800891a588
      [   78.552764] x17: 0000000000000800 x16: 0000000000000c00
      [   78.556766] x15: 0000000000000010 x14: 6f2065646f6e695f
      [   78.560767] x13: 6461657220726f66 x12: 2064656c69616620
      [   78.564769] x11: 435243203a6c616e x10: 7265746e695f6564
      [   78.568771] x9 : 6f6e695f64616572 x8 : ffffffc037974038
      [   78.572774] x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000008
      [   78.576775] x5 : 002f91d85bd44a2f x4 : 0000000000000000
      [   78.580777] x3 : 0000000000000000 x2 : 000000403755e000
      [   78.584779] x1 : 6b6b6b6b6b6b6b6b x0 : 6b6b6b6b6b6b6b6b
      ...
      [   79.038551] [<ffffff8008323d28>] rb_first_postorder+0xc/0x28
      [   79.042962] [<ffffff8000eb5578>] jffs2_do_clear_inode+0x88/0x100 [jffs2]
      [   79.048395] [<ffffff8000eb9ddc>] jffs2_evict_inode+0x3c/0x48 [jffs2]
      [   79.053443] [<ffffff8008201ca8>] evict+0xb0/0x168
      [   79.056835] [<ffffff8008202650>] iput+0x1c0/0x200
      [   79.060228] [<ffffff800820408c>] iget_failed+0x30/0x3c
      [   79.064097] [<ffffff8000eba0c0>] jffs2_iget+0x2d8/0x360 [jffs2]
      [   79.068740] [<ffffff8000eb0a60>] jffs2_lookup+0xe8/0x130 [jffs2]
      [   79.073434] [<ffffff80081f1a28>] lookup_slow+0x118/0x190
      [   79.077435] [<ffffff80081f4708>] walk_component+0xfc/0x28c
      [   79.081610] [<ffffff80081f4dd0>] path_lookupat+0x84/0x108
      [   79.085699] [<ffffff80081f5578>] filename_lookup+0x88/0x100
      [   79.089960] [<ffffff80081f572c>] user_path_at_empty+0x58/0x6c
      [   79.094396] [<ffffff80081ebe14>] vfs_statx+0xa4/0x114
      [   79.098138] [<ffffff80081ec44c>] SyS_newfstatat+0x58/0x98
      [   79.102227] [<ffffff800808354c>] __sys_trace_return+0x0/0x4
      [   79.106489] Code: d65f03c0 f9400001 b40000e1 aa0103e0 (f9400821)
      
      The jffs2_do_clear_inode() call in jffs2_iget() is unnecessary since
      iget_failed() will eventually call jffs2_do_clear_inode() if needed, so
      just remove it.
      
      Fixes: 5451f79f ("iget: stop JFFS2 from using iget() and read_inode()")
      Reviewed-by: Richard Weinberger's avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarJake Daryll Obina <jake.obina@gmail.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4754445
    • Andy Shevchenko's avatar
      device property: Define type of PROPERTY_ENRTY_*() macros · f4afb04a
      Andy Shevchenko authored
      [ Upstream commit c505cbd4 ]
      
      Some of the drivers may use the macro at runtime flow, like
      
        struct property_entry p[10];
      ...
        p[index++] = PROPERTY_ENTRY_U8("u8 property", u8_data);
      
      In that case and absence of the data type compiler fails the build:
      
      drivers/char/ipmi/ipmi_dmi.c:79:29: error: Expected ; at end of statement
      drivers/char/ipmi/ipmi_dmi.c:79:29: error: got {
      Acked-by: default avatarCorey Minyard <cminyard@mvista.com>
      Cc: Corey Minyard <minyard@acm.org>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4afb04a
    • Ngai-Mint Kwan's avatar
      fm10k: fix "failed to kill vid" message for VF · 42be47ac
      Ngai-Mint Kwan authored
      [ Upstream commit cf315ea5 ]
      
      When a VF is under PF VLAN assignment:
      
      ip link set <pf> vf <#> vlan <vid>
      
      This will remove all previous entries in the VLAN table including those
      generated by VLAN interfaces created on the VF. The issue arises when
      the VF is under PF VLAN assignment and one or more of these VLAN
      interfaces of the VF are deleted. When deleting these VLAN interfaces,
      the following message will be generated in "dmesg":
      
      failed to kill vid 0081/<vid> for device <vf>
      
      This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error.
      The handler for this ndo is "fm10k_update_vid". Any calls to this
      function while under PF VLAN management will exit prematurely and, thus,
      it will generate the failure message.
      
      Additionally, since "fm10k_update_vid" exits prematurely, none of the
      VLAN update is performed. So, even though the actual VLAN interfaces of
      the VF will be deleted, the active_vlans bitmask is not cleared. When
      the VF is no longer under PF VLAN assignment, the driver mistakenly
      restores the previous entries of the VLAN table based on an
      unsynchronized list of active VLANs.
      
      The solution to this issue involves checking the VLAN update action type
      before exiting "fm10k_update_vid". If the VLAN update action type is to
      "add", this action will not be permitted while the VF is under PF VLAN
      assignment and the VLAN update is abandoned like before.
      
      However, if the VLAN update action type is to "kill", then we need to
      also clear the active_vlans bitmask. However, we don't need to actually
      queue any messages to the PF, because the MAC and VLAN tables have
      already been cleared, and the PF would silently ignore these requests
      anyways.
      Signed-off-by: default avatarNgai-Mint Kwan <ngai-mint.kwan@intel.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42be47ac
    • Dan Carpenter's avatar
      HID: roccat: prevent an out of bounds read in kovaplus_profile_activated() · 5d193635
      Dan Carpenter authored
      [ Upstream commit 7ad81482 ]
      
      We get the "new_profile_index" value from the mouse device when we're
      handling raw events.  Smatch taints it as untrusted data and complains
      that we need a bounds check.  This seems like a reasonable warning
      otherwise there is a small read beyond the end of the array.
      
      Fixes: 0e70f97f ("HID: roccat: Add support for Kova[+] mouse")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarSilvan Jegen <s.jegen@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d193635
    • Anand Jain's avatar
      btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP · 3feba590
      Anand Jain authored
      [ Upstream commit 6f794e3c ]
      
      It appears from the original commit [1] that there isn't any design
      specific reason not to fail the mount instead of just warning. This
      patch will change it to fail.
      
      [1]
       commit 319e4d06
          btrfs: Enhance super validation check
      
      Fixes: 319e4d06 ("btrfs: Enhance super validation check")
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3feba590
    • Liu Bo's avatar
      Btrfs: fix scrub to repair raid6 corruption · 186a6519
      Liu Bo authored
      [ Upstream commit 762221f0 ]
      
      The raid6 corruption is that,
      suppose that all disks can be read without problems and if the content
      that was read out doesn't match its checksum, currently for raid6
      btrfs at most retries twice,
      
      - the 1st retry is to rebuild with all other stripes, it'll eventually
        be a raid5 xor rebuild,
      - if the 1st fails, the 2nd retry will deliberately fail parity p so
        that it will do raid6 style rebuild,
      
      however, the chances are that another non-parity stripe content also
      has something corrupted, so that the above retries are not able to
      return correct content.
      
      We've fixed normal reads to rebuild raid6 correctly with more retries
      in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix
      scrub to do the exactly same rebuild process.
      
      [1]: https://patchwork.kernel.org/patch/10091755/Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      186a6519
    • Nikolay Borisov's avatar
      btrfs: Fix out of bounds access in btrfs_search_slot · e23c0976
      Nikolay Borisov authored
      [ Upstream commit 9ea2c7c9 ]
      
      When modifying a tree where the root is at BTRFS_MAX_LEVEL - 1 then
      the level variable is going to be 7 (this is the max height of the
      tree). On the other hand btrfs_cow_block is always called with
      "level + 1" as an index into the nodes and slots arrays. This leads to
      an out of bounds access. Admittdely this will be benign since an OOB
      access of the nodes array will likely read the 0th element from the
      slots array, which in this case is going to be 0 (since we start CoW at
      the top of the tree). The OOB access into the slots array in turn will
      read the 0th and 1st values of the locks array, which would both be 0
      at the time. However, this benign behavior relies on the fact that the
      path being passed hasn't been initialised, if it has already been used to
      query a btree then it could potentially have populated the nodes/slots arrays.
      
      Fix it by explicitly checking if we are at level 7 (the maximum allowed
      index in nodes/slots arrays) and explicitly call the CoW routine with
      NULL for parent's node/slot.
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Fixes-coverity-id: 711515
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e23c0976
    • Liu Bo's avatar
      Btrfs: set plug for fsync · bfae0436
      Liu Bo authored
      [ Upstream commit 343e4fc1 ]
      
      Setting plug can merge adjacent IOs before dispatching IOs to the disk
      driver.
      
      Without plug, it'd not be a problem for single disk usecases, but for
      multiple disks using raid profile, a large IO can be split to several
      IOs of stripe length, and plug can be helpful to bring them together
      for each disk so that we can save several disk access.
      
      Moreover, fsync issues synchronous writes, so plug can really take
      effect.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfae0436
    • Wei Yongjun's avatar
      ipmi/powernv: Fix error return code in ipmi_powernv_probe() · b5c7751a
      Wei Yongjun authored
      [ Upstream commit e749d328 ]
      
      Fix to return a negative error code from the request_irq() error
      handling case instead of 0, as done elsewhere in this function.
      
      Fixes: dce143c3 ("ipmi/powernv: Convert to irq event interface")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5c7751a
    • weiyongjun (A)'s avatar
      mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl() · 7e6d77df
      weiyongjun (A) authored
      [ Upstream commit 0ddcff49 ]
      
      'hwname' is malloced in hwsim_new_radio_nl() and should be freed
      before leaving from the error handling cases, otherwise it will cause
      memory leak.
      
      Fixes: ff4dd73d ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e6d77df
    • Ulf Magnusson's avatar
      kconfig: Fix expr_free() E_NOT leak · f52bf071
      Ulf Magnusson authored
      [ Upstream commit 5b1374b3 ]
      
      Only the E_NOT operand and not the E_NOT node itself was freed, due to
      accidentally returning too early in expr_free(). Outline of leak:
      
      	switch (e->type) {
      	...
      	case E_NOT:
      		expr_free(e->left.expr);
      		return;
      	...
      	}
      	*Never reached, 'e' leaked*
      	free(e);
      
      Fix by changing the 'return' to a 'break'.
      
      Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
      
      	LEAK SUMMARY:
      	   definitely lost: 44,448 bytes in 1,852 blocks
      	   ...
      
      Summary after the fix:
      
      	LEAK SUMMARY:
      	   definitely lost: 1,608 bytes in 67 blocks
      	   ...
      Signed-off-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f52bf071
    • Ulf Magnusson's avatar
      kconfig: Fix automatic menu creation mem leak · a3343787
      Ulf Magnusson authored
      [ Upstream commit ae7440ef ]
      
      expr_trans_compare() always allocates and returns a new expression,
      giving the following leak outline:
      
      	...
      	*Allocate*
      	basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no);
      	...
      	for (menu = parent->next; menu; menu = menu->next) {
      		...
      		*Copy*
      		dep2 = expr_copy(basedep);
      		...
      		*Free copy*
      		expr_free(dep2);
      	}
      	*basedep lost!*
      
      Fix by freeing 'basedep' after the loop.
      
      Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
      
      	LEAK SUMMARY:
      	   definitely lost: 344,376 bytes in 14,349 blocks
      	   ...
      
      Summary after the fix:
      
      	LEAK SUMMARY:
      	   definitely lost: 44,448 bytes in 1,852 blocks
      	   ...
      Signed-off-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3343787
    • Ulf Magnusson's avatar
      kconfig: Don't leak main menus during parsing · d0c1ba16
      Ulf Magnusson authored
      [ Upstream commit 0724a7c3 ]
      
      If a 'mainmenu' entry appeared in the Kconfig files, two things would
      leak:
      
      	- The 'struct property' allocated for the default "Linux Kernel
      	  Configuration" prompt.
      
      	- The string for the T_WORD/T_WORD_QUOTE prompt after the
      	  T_MAINMENU token, allocated on the heap in zconf.l.
      
      To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches
      if there's no 'mainmenu' and adds the default prompt. That means the
      prompt only gets allocated once regardless of whether there's a
      'mainmenu' statement or not, and managing it becomes simple.
      
      Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
      
      	LEAK SUMMARY:
      	   definitely lost: 344,568 bytes in 14,352 blocks
      	   ...
      
      Summary after the fix:
      
      	LEAK SUMMARY:
      	   definitely lost: 344,440 bytes in 14,350 blocks
      	   ...
      Signed-off-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0c1ba16
    • Guenter Roeck's avatar
      watchdog: sp5100_tco: Fix watchdog disable bit · 8dec8a30
      Guenter Roeck authored
      [ Upstream commit f541c09e ]
      
      According to all published information, the watchdog disable bit for SB800
      compatible controllers is bit 1 of PM register 0x48, not bit 2. For the
      most part that doesn't matter in practice, since the bit has to be cleared
      to enable watchdog address decoding, which is the default setting, but it
      still needs to be fixed.
      
      Cc: Zoltán Böszörményi <zboszor@pr.hu>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWim Van Sebroeck <wim@iguana.be>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8dec8a30