~kmously/ubuntu/+source/linux/+git/disco:update-to-5.0.19

Last commit made on 2019-07-23
Get this branch:
git clone -b update-to-5.0.19 https://git.launchpad.net/~kmously/ubuntu/+source/linux/+git/disco
Only Khaled El Mously can upload to this branch. If you are Khaled El Mously please log in for upload directions.

Branch merges

Branch information

Name:
update-to-5.0.19
Repository:
lp:~kmously/ubuntu/+source/linux/+git/disco

Recent commits

107d1a6... by Greg Kroah-Hartman <email address hidden>

Linux 5.0.19

BugLink: https://bugs.launchpad.net/bugs/1837516

Signed-off-by: Khalid Elmously <email address hidden>

4726c6d... by Yifeng Li <email address hidden>

fbdev: sm712fb: fix memory frequency by avoiding a switch/case fallthrough

BugLink: https://bugs.launchpad.net/bugs/1837516

commit 9dc20113988b9a75ea6b3abd68dc45e2d73ccdab upstream.

A fallthrough in switch/case was introduced in f627caf55b8e ("fbdev:
sm712fb: fix crashes and garbled display during DPMS modesetting"),
due to my copy-paste error, which would cause the memory clock frequency
for SM720 to be programmed to SM712.

Since it only reprograms the clock to a different frequency, it's only
a benign issue without visible side-effect, so it also evaded Sudip
Mukherjee's code review and regression tests. scripts/checkpatch.pl
also failed to discover the issue, possibly due to nested switch
statements.

This issue was found by Stephen Rothwell by building linux-next with
-Wimplicit-fallthrough.

Reported-by: Stephen Rothwell <email address hidden>
Fixes: f627caf55b8e ("fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting")
Signed-off-by: Yifeng Li <email address hidden>
Cc: Sudip Mukherjee <email address hidden>
Cc: "Gustavo A. R. Silva" <email address hidden>
Cc: Kees Cook <email address hidden>
Signed-off-by: Bartlomiej Zolnierkiewicz <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

71f2760... by Daniel Borkmann

bpf, lru: avoid messing with eviction heuristics upon syscall lookup

BugLink: https://bugs.launchpad.net/bugs/1837516

commit 50b045a8c0ccf44f76640ac3eea8d80ca53979a3 upstream.

One of the biggest issues we face right now with picking LRU map over
regular hash table is that a map walk out of user space, for example,
to just dump the existing entries or to remove certain ones, will
completely mess up LRU eviction heuristics and wrong entries such
as just created ones will get evicted instead. The reason for this
is that we mark an entry as "in use" via bpf_lru_node_set_ref() from
system call lookup side as well. Thus upon walk, all entries are
being marked, so information of actual least recently used ones
are "lost".

In case of Cilium where it can be used (besides others) as a BPF
based connection tracker, this current behavior causes disruption
upon control plane changes that need to walk the map from user space
to evict certain entries. Discussion result from bpfconf [0] was that
we should simply just remove marking from system call side as no
good use case could be found where it's actually needed there.
Therefore this patch removes marking for regular LRU and per-CPU
flavor. If there ever should be a need in future, the behavior could
be selected via map creation flag, but due to mentioned reason we
avoid this here.

  [0] http://vger.kernel.org/bpfconf.html

Fixes: 29ba732acbee ("bpf: Add BPF_MAP_TYPE_LRU_HASH")
Fixes: 8f8449384ec3 ("bpf: Add BPF_MAP_TYPE_LRU_PERCPU_HASH")
Signed-off-by: Daniel Borkmann <email address hidden>
Acked-by: Martin KaFai Lau <email address hidden>
Signed-off-by: Alexei Starovoitov <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

d49425a... by Daniel Borkmann

bpf: add map_lookup_elem_sys_only for lookups from syscall side

BugLink: https://bugs.launchpad.net/bugs/1837516

commit c6110222c6f49ea68169f353565eb865488a8619 upstream.

Add a callback map_lookup_elem_sys_only() that map implementations
could use over map_lookup_elem() from system call side in case the
map implementation needs to handle the latter differently than from
the BPF data path. If map_lookup_elem_sys_only() is set, this will
be preferred pick for map lookups out of user space. This hook is
used in a follow-up fix for LRU map, but once development window
opens, we can convert other map types from map_lookup_elem() (here,
the one called upon BPF_MAP_LOOKUP_ELEM cmd is meant) over to use
the callback to simplify and clean up the latter.

Signed-off-by: Daniel Borkmann <email address hidden>
Acked-by: Martin KaFai Lau <email address hidden>
Signed-off-by: Alexei Starovoitov <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

6c47e14... by Chenbo Feng <email address hidden>

bpf: relax inode permission check for retrieving bpf program

BugLink: https://bugs.launchpad.net/bugs/1837516

commit e547ff3f803e779a3898f1f48447b29f43c54085 upstream.

For iptable module to load a bpf program from a pinned location, it
only retrieve a loaded program and cannot change the program content so
requiring a write permission for it might not be necessary.
Also when adding or removing an unrelated iptable rule, it might need to
flush and reload the xt_bpf related rules as well and triggers the inode
permission check. It might be better to remove the write premission
check for the inode so we won't need to grant write access to all the
processes that flush and restore iptables rules.

Signed-off-by: Chenbo Feng <email address hidden>
Signed-off-by: Alexei Starovoitov <email address hidden>
Signed-off-by: Daniel Borkmann <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

e48ced4... by John Garry

driver core: Postpone DMA tear-down until after devres release for probe failure

BugLink: https://bugs.launchpad.net/bugs/1837516

commit 0b777eee88d712256ba8232a9429edb17c4f9ceb upstream.

In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
devres release"), we changed the ordering of tearing down the device DMA
ops and releasing all the device's resources; this was because the DMA ops
should be maintained until we release the device's managed DMA memories.

However, we have seen another crash on an arm64 system when a
device driver probe fails:

  hisi_sas_v3_hw 0000:74:02.0: Adding to iommu group 2
  scsi host1: hisi_sas_v3_hw
  BUG: Bad page state in process swapper/0 pfn:313f5
  page:ffff7e0000c4fd40 count:1 mapcount:0
  mapping:0000000000000000 index:0x0
  flags: 0xfffe00000001000(reserved)
  raw: 0fffe00000001000 ffff7e0000c4fd48 ffff7e0000c4fd48
0000000000000000
  raw: 0000000000000000 0000000000000000 00000001ffffffff
0000000000000000
  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
  bad because of flags: 0x1000(reserved)
  Modules linked in:
  CPU: 49 PID: 1 Comm: swapper/0 Not tainted
5.1.0-rc1-43081-g22d97fd-dirty #1433
  Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI
RC0 - V1.12.01 01/29/2019
  Call trace:
  dump_backtrace+0x0/0x118
  show_stack+0x14/0x1c
  dump_stack+0xa4/0xc8
  bad_page+0xe4/0x13c
  free_pages_check_bad+0x4c/0xc0
  __free_pages_ok+0x30c/0x340
  __free_pages+0x30/0x44
  __dma_direct_free_pages+0x30/0x38
  dma_direct_free+0x24/0x38
  dma_free_attrs+0x9c/0xd8
  dmam_release+0x20/0x28
  release_nodes+0x17c/0x220
  devres_release_all+0x34/0x54
  really_probe+0xc4/0x2c8
  driver_probe_device+0x58/0xfc
  device_driver_attach+0x68/0x70
  __driver_attach+0x94/0xdc
  bus_for_each_dev+0x5c/0xb4
  driver_attach+0x20/0x28
  bus_add_driver+0x14c/0x200
  driver_register+0x6c/0x124
  __pci_register_driver+0x48/0x50
  sas_v3_pci_driver_init+0x20/0x28
  do_one_initcall+0x40/0x25c
  kernel_init_freeable+0x2b8/0x3c0
  kernel_init+0x10/0x100
  ret_from_fork+0x10/0x18
  Disabling lock debugging due to kernel taint
  BUG: Bad page state in process swapper/0 pfn:313f6
  page:ffff7e0000c4fd80 count:1 mapcount:0
mapping:0000000000000000 index:0x0
[ 89.322983] flags: 0xfffe00000001000(reserved)
  raw: 0fffe00000001000 ffff7e0000c4fd88 ffff7e0000c4fd88
0000000000000000
  raw: 0000000000000000 0000000000000000 00000001ffffffff
0000000000000000

The crash occurs for the same reason.

In this case, on the really_probe() failure path, we are still clearing
the DMA ops prior to releasing the device's managed memories.

This patch fixes this issue by reordering the DMA ops teardown and the
call to devres_release_all() on the failure path.

Reported-by: Xiang Chen <email address hidden>
Tested-by: Xiang Chen <email address hidden>
Signed-off-by: John Garry <email address hidden>
Reviewed-by: Robin Murphy <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

08d7c6d... by Nigel Croxon <email address hidden>

md/raid: raid5 preserve the writeback action after the parity check

BugLink: https://bugs.launchpad.net/bugs/1837516

commit b2176a1dfb518d870ee073445d27055fea64dfb8 upstream.

The problem is that any 'uptodate' vs 'disks' check is not precise
in this path. Put a "WARN_ON(!test_bit(R5_UPTODATE, &dev->flags)" on the
device that might try to kick off writes and then skip the action.
Better to prevent the raid driver from taking unexpected action *and* keep
the system alive vs killing the machine with BUG_ON.

Note: fixed warning reported by kbuild test robot <email address hidden>

Signed-off-by: Dan Williams <email address hidden>
Signed-off-by: Nigel Croxon <email address hidden>
Signed-off-by: Song Liu <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

2fc5144... by Song Liu <email address hidden>

Revert "Don't jump to compute_result state from check_result state"

BugLink: https://bugs.launchpad.net/bugs/1837516

commit a25d8c327bb41742dbd59f8c545f59f3b9c39983 upstream.

This reverts commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef.

Cc: Dan Williams <email address hidden>
Cc: Nigel Croxon <email address hidden>
Cc: Xiao Ni <email address hidden>
Signed-off-by: Song Liu <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

9b36324... by Jiri Olsa <email address hidden>

perf/x86/intel: Fix race in intel_pmu_disable_event()

BugLink: https://bugs.launchpad.net/bugs/1837516

[ Upstream commit 6f55967ad9d9752813e36de6d5fdbd19741adfc7 ]

New race in x86_pmu_stop() was introduced by replacing the
atomic __test_and_clear_bit() of cpuc->active_mask by separate
test_bit() and __clear_bit() calls in the following commit:

  3966c3feca3f ("x86/perf/amd: Remove need to check "running" bit in NMI handler")

The race causes panic for PEBS events with enabled callchains:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
  ...
  RIP: 0010:perf_prepare_sample+0x8c/0x530
  Call Trace:
   <NMI>
   perf_event_output_forward+0x2a/0x80
   __perf_event_overflow+0x51/0xe0
   handle_pmi_common+0x19e/0x240
   intel_pmu_handle_irq+0xad/0x170
   perf_event_nmi_handler+0x2e/0x50
   nmi_handle+0x69/0x110
   default_do_nmi+0x3e/0x100
   do_nmi+0x11a/0x180
   end_repeat_nmi+0x16/0x1a
  RIP: 0010:native_write_msr+0x6/0x20
  ...
   </NMI>
   intel_pmu_disable_event+0x98/0xf0
   x86_pmu_stop+0x6e/0xb0
   x86_pmu_del+0x46/0x140
   event_sched_out.isra.97+0x7e/0x160
  ...

The event is configured to make samples from PEBS drain code,
but when it's disabled, we'll go through NMI path instead,
where data->callchain will not get allocated and we'll crash:

          x86_pmu_stop
            test_bit(hwc->idx, cpuc->active_mask)
            intel_pmu_disable_event(event)
            {
              ...
              intel_pmu_pebs_disable(event);
              ...

EVENT OVERFLOW -> <NMI>
                     intel_pmu_handle_irq
                       handle_pmi_common
   TEST PASSES -> test_bit(bit, cpuc->active_mask))
                           perf_event_overflow
                             perf_prepare_sample
                             {
                               ...
                               if (!(sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY))
                                     data->callchain = perf_callchain(event, regs);

         CRASH -> size += data->callchain->nr;
                             }
                   </NMI>
              ...
              x86_pmu_disable_event(event)
            }

            __clear_bit(hwc->idx, cpuc->active_mask);

Fixing this by disabling the event itself before setting
off the PEBS bit.

Signed-off-by: Jiri Olsa <email address hidden>
Cc: Alexander Shishkin <email address hidden>
Cc: Arnaldo Carvalho de Melo <email address hidden>
Cc: David Arcari <email address hidden>
Cc: Jiri Olsa <email address hidden>
Cc: Lendacky Thomas <email address hidden>
Cc: Linus Torvalds <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: Stephane Eranian <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Vince Weaver <email address hidden>
Fixes: 3966c3feca3f ("x86/perf/amd: Remove need to check "running" bit in NMI handler")
Link: http://<email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

832669e... by Leo Yan

perf cs-etm: Always allocate memory for cs_etm_queue::prev_packet

BugLink: https://bugs.launchpad.net/bugs/1837516

[ Upstream commit 35bb59c10a6d0578806dd500477dae9cb4be344e ]

Robert Walker reported a segmentation fault is observed when process
CoreSight trace data; this issue can be easily reproduced by the command
'perf report --itrace=i1000i' for decoding tracing data.

If neither the 'b' flag (synthesize branches events) nor 'l' flag
(synthesize last branch entries) are specified to option '--itrace',
cs_etm_queue::prev_packet will not been initialised. After merging the
code to support exception packets and sample flags, there introduced a
number of uses of cs_etm_queue::prev_packet without checking whether it
is valid, for these cases any accessing to uninitialised prev_packet
will cause crash.

As cs_etm_queue::prev_packet is used more widely now and it's already
hard to follow which functions have been called in a context where the
validity of cs_etm_queue::prev_packet has been checked, this patch
always allocates memory for cs_etm_queue::prev_packet.

Reported-by: Robert Walker <email address hidden>
Suggested-by: Robert Walker <email address hidden>
Signed-off-by: Leo Yan <email address hidden>
Tested-by: Robert Walker <email address hidden>
Cc: Alexander Shishkin <email address hidden>
Cc: Jiri Olsa <email address hidden>
Cc: Mathieu Poirier <email address hidden>
Cc: Mike Leach <email address hidden>
Cc: Namhyung Kim <email address hidden>
Cc: Suzuki K Poulouse <email address hidden>
Cc: <email address hidden>
Fixes: 7100b12cf474 ("perf cs-etm: Generate branch sample for exception packet")
Fixes: 24fff5eb2b93 ("perf cs-etm: Avoid stale branch samples when flush packet")
Link: http://<email address hidden>
Signed-off-by: Arnaldo Carvalho de Melo <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>