1. 20 Feb, 2019 7 commits
    • Jin Yao's avatar
      perf report: Fix wrong iteration count in --branch-history · 394fc1c6
      Jin Yao authored
      [ Upstream commit a3366db0 ]
      
      By calculating the removed loops, we can get the iteration count.
      
      But the iteration count could be reported incorrectly, reporting
      impossibly high counts.
      
      That's because previous code uses the number of removed LBR entries for
      the iteration count. That's not good. Fix this by increasing the
      iteration count when a loop is detected.
      
      When matching the chain, the iteration count would be added up, finally we need
      to compute the average value when printing out.
      
      For example,
      
        $ perf report --branch-history --stdio --no-children
      
      Before:
      
        ---f2 +0
           |
           |--33.62%--f1 +9 (cycles:1)
           |          f1 +0
           |          main +22 (cycles:1)
           |          main +17
           |          main +38 (cycles:1)
           |          main +27
           |          f1 +26 (cycles:1)
           |          f1 +24
           |          f2 +27 (cycles:7)
           |          f2 +0
           |          f1 +19 (cycles:1)
           |          f1 +14
           |          f2 +27 (cycles:11)
           |          f2 +0
           |          f1 +9 (cycles:1 iter:2968 avg_cycles:3)
           |          f1 +0
           |          main +22 (cycles:1 iter:2968 avg_cycles:3)
           |          main +17
           |          main +38 (cycles:1 iter:2968 avg_cycles:3)
      
      2968 is an impossible high iteration count and avg_cycles is too small.
      
      After:
      
        ---f2 +0
           |
           |--33.62%--f1 +9 (cycles:1)
           |          f1 +0
           |          main +22 (cycles:1)
           |          main +17
           |          main +38 (cycles:1)
           |          main +27
           |          f1 +26 (cycles:1)
           |          f1 +24
           |          f2 +27 (cycles:7)
           |          f2 +0
           |          f1 +19 (cycles:1)
           |          f1 +14
           |          f2 +27 (cycles:11)
           |          f2 +0
           |          f1 +9 (cycles:1 iter:1 avg_cycles:23)
           |          f1 +0
           |          main +22 (cycles:1 iter:1 avg_cycles:23)
           |          main +17
           |          main +38 (cycles:1 iter:1 avg_cycles:23)
      
      avg_cycles:23 is the average cycles of this iteration.
      
      Fixes: c4ee0625 ("perf report: Calculate the average cycles of iterations")
      Signed-off-by: 's avatarJin Yao <yao.jin@linux.intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1546582230-17507-1-git-send-email-yao.jin@linux.intel.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      394fc1c6
    • Jin Yao's avatar
      perf stat: Fix endless wait for child process · 3902b972
      Jin Yao authored
      [ Upstream commit 8a99255a ]
      
      We hit a 'perf stat' issue by using following script:
      
        #!/bin/bash
      
        sleep 1000 &
        exec perf stat -a -e cycles -I1000 -- sleep 5
      
      Since "perf stat" is launched by exec, the "sleep 1000" would be the
      child process of "perf stat". The wait4() call will not return because
      it's waiting for the child process "sleep 1000" to end. So 'perf stat'
      doesn't return even after 5s passes.
      
      This patch lets 'perf stat' return when the specified child process ends
      (in this case, the specified child process is "sleep 5").
      
      Committer testing:
      
        # cat test.sh
        #!/bin/bash
      
        sleep 10 &
        exec perf stat -a -e cycles -I1000 -- sleep 5
        #
      
      Before:
      
        # time ./test.sh
        #           time             counts unit events
             1.001113090        108,453,351      cycles
             2.002062196        142,075,435      cycles
             3.002896194        164,801,068      cycles
             4.003731666        107,062,140      cycles
             5.002068867        112,241,832      cycles
      
        real	0m10.066s
        user	0m0.016s
        sys	0m0.101s
        #
      
      After:
      
        # time ./test.sh
        #           time             counts unit events
             1.001016096         91,412,027      cycles
             2.002014963        124,063,708      cycles
             3.002883964        125,993,929      cycles
             4.003706470        120,465,734      cycles
             5.002006778        163,560,355      cycles
      
        real	0m5.123s
        user	0m0.014s
        sys	0m0.105s
        #
      Signed-off-by: 's avatarJin Yao <yao.jin@linux.intel.com>
      Reviewed-by: 's avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1546501245-4512-1-git-send-email-yao.jin@linux.intel.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      3902b972
    • Chao Fan's avatar
      ACPI: NUMA: Use correct type for printing addresses on i386-PAE · 82f61afa
      Chao Fan authored
      [ Upstream commit b9ced18a ]
      
      The addresses of NUMA nodes are not printed correctly on i386-PAE
      which is misleading.
      
      Here is a debian9-32bit with PAE in a QEMU guest having more than 4G
      of memory:
      
      qemu-system-i386 \
      -hda /var/lib/libvirt/images/debian32.qcow2 \
      -m 5G \
      -enable-kvm \
      -smp 10 \
      -numa node,mem=512M,nodeid=0,cpus=0 \
      -numa node,mem=512M,nodeid=1,cpus=1 \
      -numa node,mem=512M,nodeid=2,cpus=2 \
      -numa node,mem=512M,nodeid=3,cpus=3 \
      -numa node,mem=512M,nodeid=4,cpus=4 \
      -numa node,mem=512M,nodeid=5,cpus=5 \
      -numa node,mem=512M,nodeid=6,cpus=6 \
      -numa node,mem=512M,nodeid=7,cpus=7 \
      -numa node,mem=512M,nodeid=8,cpus=8 \
      -numa node,mem=512M,nodeid=9,cpus=9 \
      -serial stdio
      
      Because of the wrong value type, it prints as below:
      
      [    0.021049] ACPI: SRAT Memory (0x0 length 0xa0000) in proximity domain 0 enabled
      [    0.021740] ACPI: SRAT Memory (0x100000 length 0x1ff00000) in proximity domain 0 enabled
      [    0.022425] ACPI: SRAT Memory (0x20000000 length 0x20000000) in proximity domain 1 enabled
      [    0.023092] ACPI: SRAT Memory (0x40000000 length 0x20000000) in proximity domain 2 enabled
      [    0.023764] ACPI: SRAT Memory (0x60000000 length 0x20000000) in proximity domain 3 enabled
      [    0.024431] ACPI: SRAT Memory (0x80000000 length 0x20000000) in proximity domain 4 enabled
      [    0.025104] ACPI: SRAT Memory (0xa0000000 length 0x20000000) in proximity domain 5 enabled
      [    0.025791] ACPI: SRAT Memory (0x0 length 0x20000000) in proximity domain 6 enabled
      [    0.026412] ACPI: SRAT Memory (0x20000000 length 0x20000000) in proximity domain 7 enabled
      [    0.027118] ACPI: SRAT Memory (0x40000000 length 0x20000000) in proximity domain 8 enabled
      [    0.027802] ACPI: SRAT Memory (0x60000000 length 0x20000000) in proximity domain 9 enabled
      
      The upper half of the start address of the NUMA domains between 6
      and 9 inclusive was cut, so the printed values are incorrect.
      
      Fix the value type, to get the correct values in the log as follows:
      
      [    0.023698] ACPI: SRAT Memory (0x0 length 0xa0000) in proximity domain 0 enabled
      [    0.024325] ACPI: SRAT Memory (0x100000 length 0x1ff00000) in proximity domain 0 enabled
      [    0.024981] ACPI: SRAT Memory (0x20000000 length 0x20000000) in proximity domain 1 enabled
      [    0.025659] ACPI: SRAT Memory (0x40000000 length 0x20000000) in proximity domain 2 enabled
      [    0.026317] ACPI: SRAT Memory (0x60000000 length 0x20000000) in proximity domain 3 enabled
      [    0.026980] ACPI: SRAT Memory (0x80000000 length 0x20000000) in proximity domain 4 enabled
      [    0.027635] ACPI: SRAT Memory (0xa0000000 length 0x20000000) in proximity domain 5 enabled
      [    0.028311] ACPI: SRAT Memory (0x100000000 length 0x20000000) in proximity domain 6 enabled
      [    0.028985] ACPI: SRAT Memory (0x120000000 length 0x20000000) in proximity domain 7 enabled
      [    0.029667] ACPI: SRAT Memory (0x140000000 length 0x20000000) in proximity domain 8 enabled
      [    0.030334] ACPI: SRAT Memory (0x160000000 length 0x20000000) in proximity domain 9 enabled
      Signed-off-by: 's avatarChao Fan <fanc.fnst@cn.fujitsu.com>
      [ rjw: Subject & changelog ]
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      82f61afa
    • Emily Deng's avatar
      drm/amdgpu/sriov:Correct pfvf exchange logic · 75189d28
      Emily Deng authored
      [ Upstream commit b8cf6618 ]
      
      The pfvf exchange need be in exclusive mode. And add pfvf exchange in gpu
      reset.
      Signed-off-by: 's avatarEmily Deng <Emily.Deng@amd.com>
      Reviewed-By: 's avatarXiangliang Yu <Xiangliang.Yu@amd.com>
      Signed-off-by: 's avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      75189d28
    • Jianchao Wang's avatar
      blk-mq: fix a hung issue when fsync · 74712cec
      Jianchao Wang authored
      [ Upstream commit 85bd6e61 ]
      
      Florian reported a io hung issue when fsync(). It should be
      triggered by following race condition.
      
      data + post flush         a flush
      
      blk_flush_complete_seq
        case REQ_FSEQ_DATA
          blk_flush_queue_rq
          issued to driver      blk_mq_dispatch_rq_list
                                  try to issue a flush req
                                  failed due to NON-NCQ command
                                  .queue_rq return BLK_STS_DEV_RESOURCE
      
      request completion
        req->end_io // doesn't check RESTART
        mq_flush_data_end_io
          case REQ_FSEQ_POSTFLUSH
            blk_kick_flush
              do nothing because previous flush
              has not been completed
           blk_mq_run_hw_queue
                                    insert rq to hctx->dispatch
                                    due to RESTART is still set, do nothing
      
      To fix this, replace the blk_mq_run_hw_queue in mq_flush_data_end_io
      with blk_mq_sched_restart to check and clear the RESTART flag.
      
      Fixes: bd166ef1 (blk-mq-sched: add framework for MQ capable IO schedulers)
      Reported-by: 's avatarFlorian Stecker <m19@florianstecker.de>
      Tested-by: 's avatarFlorian Stecker <m19@florianstecker.de>
      Signed-off-by: 's avatarJianchao Wang <jianchao.w.wang@oracle.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      74712cec
    • Adrian Bunk's avatar
      eeprom: at24: add support for 24c2048 · f93db166
      Adrian Bunk authored
      [ Upstream commit 37cf28d3 ]
      
      Works with ST M24M02.
      Signed-off-by: Adrian Bunk's avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: 's avatarBartosz Golaszewski <brgl@bgdev.pl>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f93db166
    • Adrian Bunk's avatar
      dt-bindings: eeprom: at24: add "atmel,24c2048" compatible string · 815dbc22
      Adrian Bunk authored
      [ Upstream commit 6c0c5dc3 ]
      
      Add new compatible to the device tree bindings.
      Signed-off-by: Adrian Bunk's avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      Signed-off-by: 's avatarBartosz Golaszewski <brgl@bgdev.pl>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      815dbc22
  2. 15 Feb, 2019 33 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.20.10 · 7f600870
      Greg Kroah-Hartman authored
      7f600870
    • Linus Torvalds's avatar
      Revert "exec: load_script: don't blindly truncate shebang string" · 90aa9a75
      Linus Torvalds authored
      commit cb5b020a upstream.
      
      This reverts commit 8099b047.
      
      It turns out that people do actually depend on the shebang string being
      truncated, and on the fact that an interpreter (like perl) will often
      just re-interpret it entirely to get the full argument list.
      Reported-by: Samuel Dionne-Riel's avatarSamuel Dionne-Riel <samuel@dionne-riel.com>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90aa9a75
    • Greg Kroah-Hartman's avatar
      Linux 4.20.9 · 03feb1ee
      Greg Kroah-Hartman authored
      03feb1ee
    • Sven Eckelmann's avatar
      batman-adv: Force mac header to start of data on xmit · b005b2fd
      Sven Eckelmann authored
      commit 9114daa8 upstream.
      
      The caller of ndo_start_xmit may not already have called
      skb_reset_mac_header. The returned value of skb_mac_header/eth_hdr
      therefore can be in the wrong position and even outside the current skbuff.
      This for example happens when the user binds to the device using a
      PF_PACKET-SOCK_RAW with enabled qdisc-bypass:
      
        int opt = 4;
        setsockopt(sock, SOL_PACKET, PACKET_QDISC_BYPASS, &opt, sizeof(opt));
      
      Since eth_hdr is used all over the codebase, the batadv_interface_tx
      function must always take care of resetting it.
      
      Fixes: c6c8fea2 ("net: Add batman-adv meshing protocol")
      Reported-by: syzbot+9d7405c7faa390e60b4e@syzkaller.appspotmail.com
      Reported-by: syzbot+7d20bc3f1ddddc0f9079@syzkaller.appspotmail.com
      Signed-off-by: Sven Eckelmann's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: Simon Wunderlich's avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b005b2fd
    • Sven Eckelmann's avatar
      batman-adv: Avoid WARN on net_device without parent in netns · 54dbbb7b
      Sven Eckelmann authored
      commit 955d3411 upstream.
      
      It is not allowed to use WARN* helpers on potential incorrect input from
      the user or transient problems because systems configured as panic_on_warn
      will reboot due to such a problem.
      
      A NULL return value of __dev_get_by_index can be caused by various problems
      which can either be related to the system configuration or problems
      (incorrectly returned network namespaces) in other (virtual) net_device
      drivers. batman-adv should not cause a (harmful) WARN in this situation and
      instead only report it via a simple message.
      
      Fixes: b7eddd0b ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface")
      Reported-by: syzbot+c764de0fcfadca9a8595@syzkaller.appspotmail.com
      Reported-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: Sven Eckelmann's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: Simon Wunderlich's avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54dbbb7b
    • Florian Westphal's avatar
      xfrm: refine validation of template and selector families · f46373e0
      Florian Westphal authored
      commit 35e61038 upstream.
      
      The check assumes that in transport mode, the first templates family
      must match the address family of the policy selector.
      
      Syzkaller managed to build a template using MODE_ROUTEOPTIMIZATION,
      with ipv4-in-ipv6 chain, leading to following splat:
      
      BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x1db/0x1854
      Read of size 4 at addr ffff888063e57aa0 by task a.out/2050
       xfrm_state_find+0x1db/0x1854
       xfrm_tmpl_resolve+0x100/0x1d0
       xfrm_resolve_and_create_bundle+0x108/0x1000 [..]
      
      Problem is that addresses point into flowi4 struct, but xfrm_state_find
      treats them as being ipv6 because it uses templ->encap_family is used
      (AF_INET6 in case of reproducer) rather than family (AF_INET).
      
      This patch inverts the logic: Enforce 'template family must match
      selector' EXCEPT for tunnel and BEET mode.
      
      In BEET and Tunnel mode, xfrm_tmpl_resolve_one will have remote/local
      address pointers changed to point at the addresses found in the template,
      rather than the flowi ones, so no oob read will occur.
      
      Reported-by: 3ntr0py1337@gmail.com
      Reported-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: 's avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f46373e0
    • Ilya Dryomov's avatar
      libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive() · df985724
      Ilya Dryomov authored
      commit 4aac9228 upstream.
      
      con_fault() can transition the connection into STANDBY right after
      ceph_con_keepalive() clears STANDBY in clear_standby():
      
          libceph user thread               ceph-msgr worker
      
      ceph_con_keepalive()
        mutex_lock(&con->mutex)
        clear_standby(con)
        mutex_unlock(&con->mutex)
                                      mutex_lock(&con->mutex)
                                      con_fault()
                                        ...
                                        if KEEPALIVE_PENDING isn't set
                                          set state to STANDBY
                                        ...
                                      mutex_unlock(&con->mutex)
        set KEEPALIVE_PENDING
        set WRITE_PENDING
      
      This triggers warnings in clear_standby() when either ceph_con_send()
      or ceph_con_keepalive() get to clearing STANDBY next time.
      
      I don't see a reason to condition queue_con() call on the previous
      value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
      into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
      could have been a non-atomic flag.
      
      Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
      Signed-off-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Tested-by: Myungho Jung's avatarMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df985724
    • Theodore Ts'o's avatar
      Revert "ext4: use ext4_write_inode() when fsyncing w/o a journal" · 196ffed8
      Theodore Ts'o authored
      commit 8fdd60f2 upstream.
      
      This reverts commit ad211f3e.
      
      As Jan Kara pointed out, this change was unsafe since it means we lose
      the call to sync_mapping_buffers() in the nojournal case.  The
      original point of the commit was avoid taking the inode mutex (since
      it causes a lockdep warning in generic/113); but we need the mutex in
      order to call sync_mapping_buffers().
      
      The real fix to this problem was discussed here:
      
      https://lore.kernel.org/lkml/20181025150540.259281-4-bvanassche@acm.org
      
      The proposed patch was to fix a syzbot complaint, but the problem can
      also demonstrated via "kvm-xfstests -c nojournal generic/113".
      Multiple solutions were discused in the e-mail thread, but none have
      landed in the kernel as of this writing.  Anyway, commit
      ad211f3e is absolutely the wrong way to suppress the lockdep, so
      revert it.
      
      Fixes: ad211f3e ("ext4: use ext4_write_inode() when fsyncing w/o a journal")
      Signed-off-by: Theodore Ts'o's avatarTheodore Ts'o <tytso@mit.edu>
      Reported: Jan Kara <jack@suse.cz>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      196ffed8
    • Ville Syrjälä's avatar
      drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen · 40a8bea6
      Ville Syrjälä authored
      commit d028a646 upstream.
      
      Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS
      which misprograms the hardware badly when encountering a suitably
      high resolution display. The programmed pipe timings are somewhat
      bonkers and the DPLL is totally misprogrammed (P divider == 0).
      That will result in atomic commit timeouts as apparently the pipe
      is sufficiently stuck to not signal vblank interrupts.
      
      IIRC something like this was also observed on some other SNB
      machine years ago (might have been a Dell XPS 8300) but a BIOS
      update cured it. Sadly looks like this was never fixed for the
      ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still
      broken.
      
      The quickest way to deal with this seems to be to shut down
      the pipe+ports+DPLL. Unfortunately doing this during the
      normal sanitization phase isn't quite soon enough as we
      already spew several WARNs about the bogus hardware state.
      But it's better than hanging the boot for a few dozen seconds.
      Since this is limited to a few old machines it doesn't seem
      entirely worthwile to try and rework the readout+sanitization
      code to handle it more gracefully.
      
      v2: Fix potential NULL deref (kbuild test robot)
          Constify has_bogus_dpll_config()
      
      Cc: stable@vger.kernel.org # v4.20+
      Cc: Daniel Kamil Kozar <dkk089@gmail.com>
      Reported-by: Daniel Kamil Kozar's avatarDaniel Kamil Kozar <dkk089@gmail.com>
      Tested-by: Daniel Kamil Kozar's avatarDaniel Kamil Kozar <dkk089@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245
      Fixes: 516a49cc ("drm/i915: Fix assert_plane() warning on bootup with external display")
      Signed-off-by: 's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190111174950.10681-1-ville.syrjala@linux.intel.comReviewed-by: 's avatarMika Kahola <mika.kahola@intel.com>
      (cherry picked from commit 7bed8adc)
      Signed-off-by: 's avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190205141846.6053-1-ville.syrjala@linux.intel.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40a8bea6
    • Benedict Wong's avatar
      xfrm: Make set-mark default behavior backward compatible · 6bd57df3
      Benedict Wong authored
      commit e2612cd4 upstream.
      
      Fixes 9b42c1f1, which changed the default route lookup behavior for
      tunnel mode SAs in the outbound direction to use the skb mark, whereas
      previously mark=0 was used if the output mark was unspecified. In
      mark-based routing schemes such as Android’s, this change in default
      behavior causes routing loops or lookup failures.
      
      This patch restores the default behavior of using a 0 mark while still
      incorporating the skb mark if the SET_MARK (and SET_MARK_MASK) is
      specified.
      
      Tested with additions to Android's kernel unit test suite:
      https://android-review.googlesource.com/c/kernel/tests/+/860150
      
      Fixes: 9b42c1f1 ("xfrm: Extend the output_mark to support input direction and masking")
      Signed-off-by: 's avatarBenedict Wong <benedictwong@google.com>
      Signed-off-by: 's avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bd57df3
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user · 547dd71c
      Thomas Hellstrom authored
      commit 728354c0 upstream.
      
      The function was unconditionally returning 0, and a caller would have to
      rely on the returned fence pointer being NULL to detect errors. However,
      the function vmw_execbuf_copy_fence_user() would expect a non-zero error
      code in that case and would BUG otherwise.
      
      So make sure we return a proper non-zero error code if the fence pointer
      returned is NULL.
      
      Cc: <stable@vger.kernel.org>
      Fixes: ae2a1040: ("vmwgfx: Implement fence objects")
      Signed-off-by: 's avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: Deepak's avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      547dd71c
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Fix an uninitialized fence handle value · 0075a474
      Thomas Hellstrom authored
      commit 51fdbeb4 upstream.
      
      if vmw_execbuf_fence_commands() fails, The handle value will be
      uninitialized and a bogus fence handle might be copied to user-space.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 2724b2d5: ("drm/vmwgfx: Use new validation interface for the modesetting code v2")
      Reported-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: 's avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: Brian Paul <brianp@vmware.com> #v1
      Reviewed-by: Sinclair Yeh <syeh@vmware.com> #v1
      Reviewed-by: Deepak's avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0075a474
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Fix setting of dma masks · 64d569f5
      Thomas Hellstrom authored
      commit 4cbfa1e6 upstream.
      
      Previously we set only the dma mask and not the coherent mask. Fix that.
      Also, for clarity, make sure both are initially set to 64 bits.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 0d00c488: ("drm/vmwgfx: Fix the driver for large dma addresses")
      Signed-off-by: 's avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: Deepak's avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64d569f5
    • Lucas De Marchi's avatar
      drm/i915: always return something on DDI clock selection · 7b9ded22
      Lucas De Marchi authored
      commit 2a121030 upstream.
      
      Even if we don't have the correct clock and get a warning, we should not
      skip the return.
      
      v2: improve commit message (from Joonas)
      
      Fixes: 1fa11ee2 ("drm/i915/icl: start adding the TBT pll")
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: 's avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: 's avatarMika Kahola <mika.kahola@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190125222444.19926-3-lucas.demarchi@intel.com
      (cherry picked from commit 7a61a6de)
      Signed-off-by: 's avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b9ded22
    • Gustavo A. R. Silva's avatar
      drm/amd/powerplay: Fix missing break in switch · f76ee750
      Gustavo A. R. Silva authored
      commit 2f10d823 upstream.
      
      Add missing break statement in order to prevent the code from falling
      through to the default case.
      
      The resoning for this is that pclk_vol_table is an automatic variable.
      So, it makes no sense to update it just before falling through to the
      default case and return -EINVAL.
      
      This bug was found thanks to the ongoing efforts to enabling
      -Wimplicit-fallthrough.
      
      Fixes: cd70f3d6 ("drm/amd/powerplay: PP/DAL interface changes for dynamic clock switch")
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: 's avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f76ee750
    • Sandy Huang's avatar
      drm/rockchip: rgb: update SPDX license identifier · 34b3b2a8
      Sandy Huang authored
      commit 053ff09f upstream.
      
      Update SPDX License Identifier from GPL-2.0+ to GPL-2.0
      and drop some GPL text.
      This fixes a mismatch between the existing SPDX headers and GPL
      boilerplate text.
      
      Fixes: 1f0f0151 ("Add support for Rockchip Soc RGB output interface")
      Cc: stable@vger.kernel.org
      Reported-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarSandy Huang <hjc@rock-chips.com>
      Signed-off-by: 's avatarHeiko Stuebner <heiko@sntech.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/1548238479-171491-1-git-send-email-hjc@rock-chips.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34b3b2a8
    • Tina Zhang's avatar
      drm/modes: Prevent division by zero htotal · c5ee84d5
      Tina Zhang authored
      commit a2fcd5c8 upstream.
      
      This patch prevents division by zero htotal.
      
      In a follow-up mail Tina writes:
      
      > > How did you manage to get here with htotal == 0? This needs backtraces (or if
      > > this is just about static checkers, a mention of that).
      > > -Daniel
      >
      > In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
      > (a.k.a htotal=0), then we met the following kernel panic:
      >
      > [   32.832048] divide error: 0000 [#1] SMP PTI
      > [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
      > [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
      > [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.836004] Call Trace:
      > [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
      > [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
      > [   32.836004]  intel_modeset_init+0x905/0x1db0
      > [   32.836004]  i915_driver_load+0xb8c/0x1120
      > [   32.836004]  i915_pci_probe+0x4d/0xb0
      > [   32.836004]  local_pci_probe+0x44/0xa0
      > [   32.836004]  ? pci_assign_irq+0x27/0x130
      > [   32.836004]  pci_device_probe+0x102/0x1c0
      > [   32.836004]  driver_probe_device+0x2b8/0x480
      > [   32.836004]  __driver_attach+0x109/0x110
      > [   32.836004]  ? driver_probe_device+0x480/0x480
      > [   32.836004]  bus_for_each_dev+0x67/0xc0
      > [   32.836004]  ? klist_add_tail+0x3b/0x70
      > [   32.836004]  bus_add_driver+0x1e8/0x260
      > [   32.836004]  driver_register+0x5b/0xe0
      > [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
      > [   32.836004]  do_one_initcall+0x4d/0x1eb
      > [   32.836004]  kernel_init_freeable+0x197/0x237
      > [   32.836004]  ? rest_init+0xd0/0xd0
      > [   32.836004]  kernel_init+0xa/0x110
      > [   32.836004]  ret_from_fork+0x35/0x40
      > [   32.836004] Modules linked in:
      > [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
      > [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      >
      > Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0.
      Signed-off-by: 's avatarTina Zhang <tina.zhang@intel.com>
      Cc: Adam Jackson <ajax@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      [danvet: Add additional explanations + cc: stable.]
      Cc: stable@vger.kernel.org
      Signed-off-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5ee84d5
    • Felix Fietkau's avatar
      mac80211: ensure that mgmt tx skbs have tailroom for encryption · 18665055
      Felix Fietkau authored
      commit 9d0f50b8 upstream.
      
      Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
      frames need to be software encrypted. Since normal data packets are still
      encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
      after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
      which don't have the necessary tailroom for software encryption.
      
      Change the code to add tailroom for encrypted management packets, even if
      crypto_tx_tailroom_needed_cnt is 0.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: Felix Fietkau's avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: 's avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18665055
    • Vincent Whitchurch's avatar
      mic: vop: Fix use-after-free on remove · 0cd65820
      Vincent Whitchurch authored
      commit 70ed7148 upstream.
      
      KASAN detects a use-after-free when vop devices are removed.
      
      This problem was introduced by commit 0063e8bb ("virtio_vop:
      don't kfree device on register failure").  That patch moved the freeing
      of the struct _vop_vdev to the release function, but failed to ensure
      that vop holds a reference to the device when it doesn't want it to go
      away.  A kfree() was replaced with a put_device() in the unregistration
      path, but the last reference to the device is already dropped in
      unregister_virtio_device() so the struct is freed before vop is done
      with it.
      
      Fix it by holding a reference until cleanup is done.  This is similar to
      the fix in virtio_pci in commit 2989be09 ("virtio_pci: fix use
      after free on release").
      
       ==================================================================
       BUG: KASAN: use-after-free in vop_scan_devices+0xc6c/0xe50 [vop]
       Read of size 8 at addr ffff88800da18580 by task kworker/0:1/12
      
       CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc4+ #53
       Workqueue: events vop_hotplug_devices [vop]
       Call Trace:
        dump_stack+0x74/0xbb
        print_address_description+0x5d/0x2b0
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        kasan_report+0x152/0x1aa
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        vop_scan_devices+0xc6c/0xe50 [vop]
        ? vop_loopback_free_irq+0x160/0x160 [vop_loopback]
        process_one_work+0x7c0/0x14b0
        ? pwq_dec_nr_in_flight+0x2d0/0x2d0
        ? do_raw_spin_lock+0x120/0x280
        worker_thread+0x8f/0xbf0
        ? __kthread_parkme+0x78/0xf0
        ? process_one_work+0x14b0/0x14b0
        kthread+0x2ae/0x3a0
        ? kthread_park+0x120/0x120
        ret_from_fork+0x3a/0x50
      
       Allocated by task 12:
        kmem_cache_alloc_trace+0x13a/0x2a0
        vop_scan_devices+0x473/0xe50 [vop]
        process_one_work+0x7c0/0x14b0
        worker_thread+0x8f/0xbf0
        kthread+0x2ae/0x3a0
        ret_from_fork+0x3a/0x50
      
       Freed by task 12:
        kfree+0x104/0x310
        device_release+0x73/0x1d0
        kobject_put+0x14f/0x420
        unregister_virtio_device+0x32/0x50
        vop_scan_devices+0x19d/0xe50 [vop]
        process_one_work+0x7c0/0x14b0
        worker_thread+0x8f/0xbf0
        kthread+0x2ae/0x3a0
        ret_from_fork+0x3a/0x50
      
       The buggy address belongs to the object at ffff88800da18008
        which belongs to the cache kmalloc-2k of size 2048
       The buggy address is located 1400 bytes inside of
        2048-byte region [ffff88800da18008, ffff88800da18808)
       The buggy address belongs to the page:
       page:ffffea0000368600 count:1 mapcount:0 mapping:ffff88801440dbc0 index:0x0 compound_mapcount: 0
       flags: 0x4000000000010200(slab|head)
       raw: 4000000000010200 ffffea0000378608 ffffea000037a008 ffff88801440dbc0
       raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
        ffff88800da18480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff88800da18500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       >ffff88800da18580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                          ^
        ffff88800da18600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff88800da18680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ==================================================================
      
      Fixes: 0063e8bb ("virtio_vop: don't kfree device on register failure")
      Signed-off-by: 's avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0cd65820
    • Aneesh Kumar K.V's avatar
      powerpc/radix: Fix kernel crash with mremap() · ae71d7ba
      Aneesh Kumar K.V authored
      commit 579b9239 upstream.
      
      With support for split pmd lock, we use pmd page pmd_huge_pte pointer
      to store the deposited page table. In those config when we move page
      tables we need to make sure we move the deposited page table to the
      correct pmd page. Otherwise this can result in crash when we withdraw
      of deposited page table because we can find the pmd_huge_pte NULL.
      
      eg:
      
        __split_huge_pmd+0x1070/0x1940
        __split_huge_pmd+0xe34/0x1940 (unreliable)
        vma_adjust_trans_huge+0x110/0x1c0
        __vma_adjust+0x2b4/0x9b0
        __split_vma+0x1b8/0x280
        __do_munmap+0x13c/0x550
        sys_mremap+0x220/0x7e0
        system_call+0x5c/0x70
      
      Fixes: 675d9952 ("powerpc/book3s64: Enable split pmd ptlock.")
      Cc: stable@vger.kernel.org # v4.18+
      Signed-off-by: 's avatarAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae71d7ba
    • Oliver O'Halloran's avatar
      powerpc/papr_scm: Use the correct bind address · 28e2e6ca
      Oliver O'Halloran authored
      commit 5a3840a4 upstream.
      
      When binding an SCM volume to a physical address the hypervisor has the
      option to return early with a continue token with the expectation that
      the guest will resume the bind operation until it completes. A quirk of
      this interface is that the bind address will only be returned by the
      first bind h-call and the subsequent calls will return
      0xFFFF_FFFF_FFFF_FFFF for the bind address.
      
      We currently do not save the address returned by the first h-call. As a
      result we will use the junk address as the base of the bound region if
      the hypervisor decides to split the bind across multiple h-calls. This
      bug was found when testing with very large SCM volumes where the bind
      process would take more time than they hypervisor's internal h-call time
      limit would allow. This patch fixes the issue by saving the bind address
      from the first call.
      
      Cc: stable@vger.kernel.org
      Fixes: b5beae5e ("powerpc/pseries: Add driver for PAPR SCM regions")
      Signed-off-by: 's avatarOliver O'Halloran <oohall@gmail.com>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28e2e6ca
    • Sudeep Holla's avatar
      firmware: arm_scmi: provide the mandatory device release callback · 480cbf71
      Sudeep Holla authored
      commit 46edb8d1 upstream.
      
      The device/driver model clearly mandates that bus driver that discover
      and allocate the device must set the release callback. This callback
      will be used to free the device after all references have gone away.
      
      scmi bus driver is missing the obvious callback which will result in
      the following warning if the device is unregistered:
      
      Device 'scmi_dev.1' does not have a release() function, it is broken and
      must be fixed. See Documentation/kobject.txt.
      WARNING at drivers/base/core.c:922 device_release+0x8c/0xa0
      Hardware name: ARM LTD Juno Development Platform BIOS EDK II Jan 21 2019
      Workqueue: events deferred_probe_work_func
      pstate: 60000005 (nZCv daif -PAN -UAO)
      pc : device_release+0x8c/0xa0
      lr : device_release+0x8c/0xa0
      Call trace:
       device_release+0x8c/0xa0
       kobject_put+0x8c/0x208
       device_unregister+0x30/0x78
       scmi_device_destroy+0x28/0x50
       scmi_probe+0x354/0x5b0
       platform_drv_probe+0x58/0xa8
       really_probe+0x2c4/0x3e8
       driver_probe_device+0x12c/0x148
       __device_attach_driver+0xac/0x150
       bus_for_each_drv+0x78/0xd8
       __device_attach+0xe0/0x168
       device_initial_probe+0x24/0x30
       bus_probe_device+0xa0/0xa8
       deferred_probe_work_func+0x8c/0xe0
       process_one_work+0x1f0/0x478
       worker_thread+0x22c/0x450
       kthread+0x134/0x138
       ret_from_fork+0x10/0x1c
      ---[ end trace 420bdb7f6af50937 ]---
      
      Fix the issue by providing scmi_device_release callback. We have
      everything required for device release already in scmi_device_destroy,
      so we just need to move freeing of the device to scmi_device_release.
      
      Fixes: 933c5044 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
      Signed-off-by: 's avatarSudeep Holla <sudeep.holla@arm.com>
      Cc: stable@vger.kernel.org # 4.17+
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      480cbf71
    • Bartosz Golaszewski's avatar
      ARM: dts: da850: fix interrupt numbers for clocksource · d4481b6a
      Bartosz Golaszewski authored
      commit e3966a76 upstream.
      
      The timer interrupts specified in commit 3652e274 ("ARM: dts:
      da850: Add clocks") are wrong but since the current timer code
      hard-codes them, the bug was never spotted.
      
      This patch must go into stable since, once we introduce a proper
      clocksource driver, devices with buggy device tree will stop booting.
      
      Fixes: 3652e274 ("ARM: dts: da850: Add clocks")
      Cc: stable@vger.kernel.org
      Signed-off-by: Bartosz Golaszewski's avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: 's avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4481b6a
    • Marc Gonzalez's avatar
      ARM: tango: Improve ARCH_MULTIPLATFORM compatibility · 5724edab
      Marc Gonzalez authored
      commit d0f9f167 upstream.
      
      Calling platform-specific code unconditionally blows up when running
      an ARCH_MULTIPLATFORM kernel on a different platform. Don't do it.
      Reported-by: 's avatarPaolo Pisati <p.pisati@gmail.com>
      Signed-off-by: 's avatarMarc Gonzalez <marc.w.gonzalez@free.fr>
      Acked-by: Pavel Machek's avatarPavel Machek <pavel@ucw.cz>
      Cc: stable@vger.kernel.org # v4.8+
      Fixes: a30eceb7 ("ARM: tango: add Suspend-to-RAM support")
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5724edab
    • Russell King's avatar
      ARM: iop32x/n2100: fix PCI IRQ mapping · b9a7d516
      Russell King authored
      commit db409092 upstream.
      
      Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
      PCI, due to n2100_pci_map_irq() having been discarded during boot.
      Signed-off-by: 's avatarRussell King <rmk+kernel@armlinux.org.uk>
      Cc: stable@vger.kernel.org # 2.6.18+
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9a7d516
    • Paul Burton's avatar
      MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds · 3789f08f
      Paul Burton authored
      commit 67fc5dc8 upstream.
      
      When generating vdso-o32.lds & vdso-n32.lds for use with programs
      running as compat ABIs under 64b kernels, we previously haven't included
      the compiler flags that are supposedly common to all ABIs - ie. those in
      the ccflags-vdso variable.
      
      This is problematic in cases where we need to provide the -m%-float flag
      in order to ensure that we don't attempt to use a floating point ABI
      that's incompatible with the target CPU & ABI. For example a toolchain
      using current gcc trunk configured --with-fp-32=xx fails to build a
      64r6el_defconfig kernel with the following error:
      
        cc1: error: '-march=mips1' requires '-mfp32'
        make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
      
      Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
      included for the native VDSO .lds & when compiling objects for the
      compat VDSOs. This ensures we consistently provide the -msoft-float flag
      amongst others, avoiding the problem by ensuring we're agnostic to the
      toolchain defaults.
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
      Cc: linux-mips@vger.kernel.org
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Maciej W . Rozycki <macro@linux-mips.org>
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3789f08f
    • Yifeng Li's avatar
      mips: loongson64: remove unreachable(), fix loongson_poweroff(). · f8b08c9e
      Yifeng Li authored
      commit 8a96669d upstream.
      
      On my Yeeloong 8089, I noticed the machine fails to shutdown
      properly, and often, the function mach_prepare_reboot() is
      unexpectedly executed, thus the machine reboots instead. A
      wait loop is needed to ensure the system is in a well-defined
      state before going down.
      
      In commit 997e93d4 ("MIPS: Hang more efficiently on
      halt/powerdown/restart"), a general superset of the wait loop for all
      platforms is already provided, so we don't need to implement our own.
      
      This commit simply removes the unreachable() compiler marco after
      mach_prepare_reboot(), thus allowing the execution of machine_hang().
      My test shows that the machine is now able to shutdown successfully.
      
      Please note that there are two different bugs preventing the machine
      from shutting down, another work-in-progress commit is needed to
      fix a lockup in cpufreq / i8259 driver, please read Reference, this
      commit does not fix that bug.
      
      Reference: https://lkml.org/lkml/2019/2/5/908Signed-off-by: 's avatarYifeng Li <tomli@tomli.me>
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: stable@vger.kernel.org # v4.17+
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8b08c9e
    • Paul Burton's avatar
      MIPS: VDSO: Use same -m%-float cflag as the kernel proper · 1699a0ca
      Paul Burton authored
      commit 0648e50e upstream.
      
      The MIPS VDSO build currently doesn't provide the -msoft-float flag to
      the compiler as the kernel proper does. This results in an attempt to
      use the compiler's default floating point configuration, which can be
      problematic in cases where this is incompatible with the target CPU's
      -march= flag. For example decstation_defconfig fails to build using
      toolchains in which gcc was configured --with-fp-32=xx with the
      following error:
      
          LDS     arch/mips/vdso/vdso.lds
        cc1: error: '-march=r3000' requires '-mfp32'
        make[2]: *** [scripts/Makefile.build:379: arch/mips/vdso/vdso.lds] Error 1
      
      The kernel proper avoids this error because we build with the
      -msoft-float compiler flag, rather than using the compiler's default.
      Pass this flag through to the VDSO build so that it too becomes agnostic
      to the toolchain's floating point configuration.
      
      Note that this is filtered out from KBUILD_CFLAGS rather than simply
      always using -msoft-float such that if we switch the kernel to use
      -mno-float in the future the VDSO will automatically inherit the change.
      
      The VDSO doesn't actually include any floating point code, and its
      .MIPS.abiflags section is already manually generated to specify that
      it's compatible with any floating point ABI. As such this change should
      have no effect on the resulting VDSO, apart from fixing the build
      failure for affected toolchains.
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Reported-by: Kevin Hilman's avatarKevin Hilman <khilman@baylibre.com>
      Reported-by: 's avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: Kevin Hilman's avatarKevin Hilman <khilman@baylibre.com>
      References: https://lore.kernel.org/linux-mips/1477843551-21813-1-git-send-email-linux@roeck-us.net/
      References: https://kernelci.org/build/id/5c4e4ae059b5142a249ad004/logs/
      Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1699a0ca
    • Aaro Koskinen's avatar
      MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled · 36e53ed8
      Aaro Koskinen authored
      commit dcf300a6 upstream.
      
      Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
      of the MSI irqchip later on, and saves a bit of memory.
      Signed-off-by: 's avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Fixes: a214720c ("Disable MSI also when pcie-octeon.pcie_disable on")
      Cc: stable@vger.kernel.org # v3.3+
      Cc: linux-mips@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36e53ed8
    • Paul Burton's avatar
      MIPS: Use lower case for addresses in nexys4ddr.dts · 97da4897
      Paul Burton authored
      commit 047f2d94 upstream.
      
      DTC introduced an i2c_bus_reg check in v1.4.7, used since Linux v4.20,
      which complains about upper case addresses used in the unit name.
      
      nexys4ddr.dts names an I2C device node "ad7420@4B", leading to:
      
        arch/mips/boot/dts/xilfpga/nexys4ddr.dts:109.16-112.8: Warning
          (i2c_bus_reg): /i2c@10A00000/ad7420@4B: I2C bus unit address format
          error, expected "4b"
      
      Fix this by switching to lower case addresses throughout the file, as is
      *mostly* the case in the file already & fairly standard throughout the
      tree.
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Cc: stable@vger.kernel.org # v4.20+
      Cc: linux-mips@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97da4897
    • Vladimir Kondratiev's avatar
      mips: cm: reprime error cause · d80d76c6
      Vladimir Kondratiev authored
      commit 05dc6001 upstream.
      
      Accordingly to the documentation
      ---cut---
      The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
      fields can be cleared by either a reset or by writing the current
      value of GCR_ERROR_CAUSE.ERR_TYPE to the
      GCR_ERROR_CAUSE.ERR_TYPE register.
      ---cut---
      Do exactly this. Original value of cm_error may be safely written back;
      it clears error cause and keeps other bits untouched.
      
      Fixes: 3885c2b4 ("MIPS: CM: Add support for reporting CM cache errors")
      Signed-off-by: 's avatarVladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d80d76c6
    • Andreas Ziegler's avatar
      tracing: uprobes: Fix typo in pr_fmt string · ac8a0a24
      Andreas Ziegler authored
      commit ea6eb5e7 upstream.
      
      The subsystem-specific message prefix for uprobes was also
      "trace_kprobe: " instead of "trace_uprobe: " as described in
      the original commit message.
      
      Link: http://lkml.kernel.org/r/20190117133023.19292-1-andreas.ziegler@fau.de
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Acked-by: 's avatarMasami Hiramatsu <mhiramat@kernel.org>
      Fixes: 72576341 ("tracing/probe: Show subsystem name in messages")
      Signed-off-by: 's avatarAndreas Ziegler <andreas.ziegler@fau.de>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac8a0a24
    • Andreas Ziegler's avatar
      tracing/uprobes: Fix output for multiple string arguments · 2e47e83a
      Andreas Ziegler authored
      commit 0722069a upstream.
      
      When printing multiple uprobe arguments as strings the output for the
      earlier arguments would also include all later string arguments.
      
      This is best explained in an example:
      
      Consider adding a uprobe to a function receiving two strings as
      parameters which is at offset 0xa0 in strlib.so and we want to print
      both parameters when the uprobe is hit (on x86_64):
      
      $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
          /sys/kernel/debug/tracing/uprobe_events
      
      When the function is called as func("foo", "bar") and we hit the probe,
      the trace file shows a line like the following:
      
        [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
      
      Note the extra "bar" printed as part of arg1. This behaviour stacks up
      for additional string arguments.
      
      The strings are stored in a dynamically growing part of the uprobe
      buffer by fetch_store_string() after copying them from userspace via
      strncpy_from_user(). The return value of strncpy_from_user() is then
      directly used as the required size for the string. However, this does
      not take the terminating null byte into account as the documentation
      for strncpy_from_user() cleary states that it "[...] returns the
      length of the string (not including the trailing NUL)" even though the
      null byte will be copied to the destination.
      
      Therefore, subsequent calls to fetch_store_string() will overwrite
      the terminating null byte of the most recently fetched string with
      the first character of the current string, leading to the
      "accumulation" of strings in earlier arguments in the output.
      
      Fix this by incrementing the return value of strncpy_from_user() by
      one if we did not hit the maximum buffer size.
      
      Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 5baaa59e ("tracing/probes: Implement 'memory' fetch method for uprobes")
      Acked-by: 's avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: 's avatarAndreas Ziegler <andreas.ziegler@fau.de>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e47e83a