commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
/proc/iomem") wrongly assumed that memblock_reserve() would not be used to
reserve regions that aren't memory. It turns out, this is exactly what
early_init_dt_reserve_memory_arch() will do if it finds a reservation
that was also carved out of the memory node.
reserve_memblock_reserved_regions() now needs to cope with reserved regions
that aren't memory, which means we must walk two lists at once.
We can't use walk_system_ram_res() and reserve_region_with_split()
together, as the former hands its callback a copied resource on
the stack, where as the latter expects the in-tree resource to be
provided.
Allocate an array of struct resources during request_standard_resources()
so that we have all the 'System RAM' regions on hand.
Increasing the mem_idx cursor is optional as multiple memblock_reserved()
regions may exist in one System RAM region.
Because adjacent memblock_reserved() regions will be merged, we also need
to consider multiple System RAM regions for one span of memblock_reserved()
address space.
Fixes: 50d7ba36b916 ("arm64: export memblock_reserve()d regions via /proc/iomem")
Reported-by: John Stultz <email address hidden>
CC: Akashi Takahiro <email address hidden>
CC: Ard Biesheuvel <email address hidden>
Signed-off-by: James Morse <email address hidden>
Tested-by: John Stultz <email address hidden>
Signed-off-by: Paolo Pisati <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
Remove the usage of IRQ_TYPE_NONE to fix loud warnings from
patch (83a86fbb5b56b "irqchip/gic: Loudly complain about
the use of IRQ_TYPE_NONE").
Signed-off-by: Paolo Pisati <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
The front MIC on the Lenovo M715 can't record sound, after applying
the ALC294_FIXUP_LENOVO_MIC_LOCATION, the problem is fixed. So add
the pin configuration of this machine to the pin quirk table.
This adds a mode where the vcore scheduling logic in HV KVM limits itself
to scheduling only virtual cores from the same VM on any given physical
core. This is enabled via a new module parameter on the kvm-hv module
called "one_vm_per_core". For this to work on POWER9, it is necessary to
set indep_threads_mode=N. (On POWER8, hardware limitations mean that KVM
is never in independent threads mode, regardless of the indep_threads_mode
setting.)
Thus the settings needed for this to work are:
1. The host is in SMT1 mode.
2. On POWER8, the host is not in 2-way or 4-way static split-core mode.
3. On POWER9, the indep_threads_mode parameter is N.
4. The one_vm_per_core parameter is Y.
With these settings, KVM can run up to 4 vcpus on a core at the same
time on POWER9, or up to 8 vcpus on POWER8 (depending on the guest
threading mode), and will ensure that all of the vcpus belong to the
same VM.
This is intended for use in security-conscious settings where users are
concerned about possible side-channel attacks between threads which could
perhaps enable one VM to attack another VM on the same core, or the host.
Signed-off-by: Paul Mackerras <email address hidden>
(cherry picked from commit aa2278644ae54ff762ce33f9c9563d759e9cca9f linux-next)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
[Trace]
seen this in 4.4.x kernels and the same bug affects fscache in latest upstreams kernels.
Jun 25 11:32:08 kernel: [4740718.880898] FS-Cache:
Jun 25 11:32:08 kernel: [4740718.880920] FS-Cache: Assertion failed
Jun 25 11:32:08 kernel: [4740718.880934] FS-Cache: 0 > 0 is false
Jun 25 11:32:08 kernel: [4740718.881001] ------------[ cut here ]------------
Jun 25 11:32:08 kernel: [4740718.881017] kernel BUG at /usr/src/linux-4.4.0/fs/fscache/operation.c:449!
Jun 25 11:32:08 kernel: [4740718.881040] invalid opcode: 0000 [#1] SMP
...
Jun 25 11:32:08 kernel: [4740718.892659] Call Trace:
Jun 25 11:32:08 kernel: [4740718.893506] [<ffffffffc1464cf9>] cachefiles_read_copier+0x3a9/0x410 [cachefiles]
Jun 25 11:32:08 kernel: [4740718.894374] [<ffffffffc037e272>] fscache_op_work_func+0x22/0x50 [fscache]
Jun 25 11:32:08 kernel: [4740718.895180] [<ffffffff81096da0>] process_one_work+0x150/0x3f0
Jun 25 11:32:08 kernel: [4740718.895966] [<ffffffff8109751a>] worker_thread+0x11a/0x470
Jun 25 11:32:08 kernel: [4740718.896753] [<ffffffff81808e59>] ? __schedule+0x359/0x980
Jun 25 11:32:08 kernel: [4740718.897783] [<ffffffff81097400>] ? rescuer_thread+0x310/0x310
Jun 25 11:32:08 kernel: [4740718.898581] [<ffffffff8109cdd6>] kthread+0xd6/0xf0
Jun 25 11:32:08 kernel: [4740718.899469] [<ffffffff8109cd00>] ? kthread_park+0x60/0x60
Jun 25 11:32:08 kernel: [4740718.900477] [<ffffffff8180d0cf>] ret_from_fork+0x3f/0x70
Jun 25 11:32:08 kernel: [4740718.901514] [<ffffffff8109cd00>] ? kthread_park+0x60/0x60
[Problem] atomic_sub(n_pages, &op->n_pages);
if (atomic_read(&op->n_pages) <= 0) fscache_op_complete(&op->op, true);
The code in fscache_retrieval_complete is using atomic_sub followed by an atomic_read.
This causes two threads doing a decrement of pages to race with each other seeing the op->refcount 0 at same time,
and end up calling fscache_op_complete in both the threads leading to the OOPs.
[Fix]
The fix is trivial to use atomic_sub_return instead of two calls.
I have cleaned up the commit message a little bit and dropped a
whitespace change, but no other changes have been made.)
Signed-off-by: Daniel Axtens <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
Function call of phy_connect_direct will reinitialize phydev. Some
information like advertising will be lost. Phy_connect_direct only
needs to be called once. And driver can run well. This patch adds
some functions to ensure that phy_connect_direct is called only once
to solve the information of phydev lost problem occurring when we stop
the net and open it again.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support
Signed-off-by: Fuyun Liang <email address hidden>
Signed-off-by: Peng Li <email address hidden>
Signed-off-by: Salil Mehta <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit b01b7cf19bf4a677d5dd4e63b12d86a021db751d)
Signed-off-by: dann frazier <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
Call Frame Information is used by gdb for back-traces and inserting
breakpoints on function return for the "finish" command. This failed
when inside __kernel_clock_gettime. More concerning than difficulty
debugging is that CFI is also used by stack frame unwinding code to
implement exceptions. If you have an app that needs to handle
asynchronous exceptions for some reason, and you are unlucky enough to
get one inside the VDSO time functions, your app will crash.
What's wrong: There is control flow in __kernel_clock_gettime that
reaches label 99 without saving lr in r12. CFI info however is
interpreted by the unwinder without reference to control flow: It's a
simple matter of "Execute all the CFI opcodes up to the current
address". That means the unwinder thinks r12 contains the return
address at label 99. Disabuse it of that notion by resetting CFI for
the return address at label 99.
Note that the ".cfi_restore lr" could have gone anywhere from the
"mtlr r12" a few instructions earlier to the instruction at label 99.
I put the CFI as late as possible, because in general that's best
practice (and if possible grouped with other CFI in order to reduce
the number of CFI opcodes executed when unwinding). Using r12 as the
return address is perfectly fine after the "mtlr r12" since r12 on
that code path still contains the return address.
__get_datapage also has a CFI error. That function temporarily saves
lr in r0, and reflects that fact with ".cfi_register lr,r0". A later
use of r0 means the CFI at that point isn't correct, as r0 no longer
contains the return address. Fix that too.
Signed-off-by: Alan Modra <email address hidden>
Tested-by: Reza Arbab <email address hidden>
Signed-off-by: Paul Mackerras <email address hidden>
(cherry picked from commit 56d20861c027498b5a1112b4f9f05b56d906fdda linux-next)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
173c0ff...
by
"Aneesh Kumar K.V" <email address hidden>
powerpc/mm/radix: Only need the Nest MMU workaround for R -> RW transition
The Nest MMU workaround is only needed for RW upgrades. Avoid doing
that for other PTE updates.
We also avoid clearing the PTE while marking it invalid. This is
because other page table walkers will find this PTE none and can
result in unexpected behaviour due to that. Instead we clear
_PAGE_PRESENT and set the software PTE bit _PAGE_INVALID.
pte_present() is already updated to check for both bits. This makes
sure page table walkers will find the PTE present and things like
pte_pfn(pte) returns the right value.
Based on an original patch from Benjamin Herrenschmidt <email address hidden>
Signed-off-by: Aneesh Kumar K.V <email address hidden>
Reviewed-by: Nicholas Piggin <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(backported from commit f08d08f3db55452d31ba4a37c702da6245876b96
[jsalisbury: Patch was not expcting cpu_has_feature() check, so
merged it in.])
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
