Since it's not stable until it could be merged into Linus's tree
lets make it as experimental. If a vendor want to use it, they
should carry on cma_sysfs.experimental=Y on kernel parameter.
Otherwise, it will be disabled.
If some vendor enables it, it means they know this is experimental
faeture so Android never guarantee it in the future.
Bug: 179256052
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ic6566197a7865dfcab6964d008103d3686c9d14b
Since CMA is getting used more widely, it's more important to
keep monitoring CMA statistics for system health since it's
directly related to user experience.
This patch introduces sysfs statistics for CMA, in order to provide
some basic monitoring of the CMA allocator.
* the number of CMA page successful allocations
* the number of CMA page allocation failures
These two values allow the user to calcuate the allocation
failure rate for each CMA area.
e.g.)
/sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail]
/sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail]
/sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]
The cma_stat was intentionally allocated by dynamic allocation
to harmonize with kobject lifetime management.
https://lore.kernel.org/linux-mm/YCOAmXqt6dZkCQYs@kroah.com/
Link: https://lore.kernel.org/linux-mm/20210324230759.2213957-1-minchan@kernel.org/
Bug: 179256052
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Link: https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.king@canonical.com/
Addresses-Coverity: ("Dereference after null check")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I86239db91c7853a62a22b2161d1bf8c9099152b7
The hook may modify index. In that case, target_state and
related values should be assigned and pre-processing should
be executed according to the modified index.
Bug: 183690687
Signed-off-by: Choonghoon Park <choong.park@samsung.com>
Change-Id: Ie641270f9560d0e4a5b4890b7f63ccc5a31277db
This is an incompatible ABI XML version change.
Bitfield offsets are now correct.
Bug: 183612421
Change-Id: I8871009e3a129c075b70d95612a55822b0f9d9e3
Signed-off-by: Giuliano Procida <gprocida@google.com>
Leaf changes summary: 2669 artifacts changed
Changed leaf types summary: 20 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 2563 Changed, 29 Added functions
Removed/Changed/Added variables summary: 0 Removed, 50 Changed, 7 Added variables
29 Added functions:
[A] 'function void* android_debug_per_cpu_symbol(android_debug_per_cpu_symbol)'
[A] 'function void* android_debug_symbol(android_debug_symbol)'
[A] 'function long int copy_from_kernel_nofault(void*, void*, unsigned long int)'
[A] 'function irq_desc** ipi_desc_get()'
[A] 'function int is_dma_buf_file(file*)'
[A] 'function unsigned int kstat_irqs_cpu(unsigned int, int)'
[A] 'function unsigned int kstat_irqs_usr(unsigned int)'
[A] 'function char* log_buf_addr_get()'
[A] 'function u32 log_buf_len_get()'
[A] 'function int nr_ipi_get()'
[A] 'function int pci_dev_present(const pci_device_id*)'
[A] 'function phys_addr_t per_cpu_ptr_to_phys(void*)'
[A] 'function int register_die_notifier(notifier_block*)'
[A] 'function int register_module_notifier(notifier_block*)'
[A] 'function int sched_setattr(task_struct*, const sched_attr*)'
[A] 'function int seq_buf_printf(seq_buf*, const char*, ...)'
[A] 'function int sysfs_emit(char*, const char*, ...)'
[A] 'function int unregister_die_notifier(notifier_block*)'
[A] 'function int unregister_module_notifier(notifier_block*)'
[A] 'function xhci_command* xhci_alloc_command(xhci_hcd*, bool, unsigned int)'
[A] 'function int xhci_alloc_erst(xhci_hcd*, xhci_ring*, xhci_erst*, gfp_t)'
[A] 'function void xhci_free_command(xhci_hcd*, xhci_command*)'
[A] 'function void xhci_free_erst(xhci_hcd*, xhci_erst*)'
[A] 'function unsigned int xhci_get_endpoint_index(usb_endpoint_descriptor*)'
[A] 'function int xhci_queue_stop_endpoint(xhci_hcd*, xhci_command*, int, unsigned int, int)'
[A] 'function xhci_ring* xhci_ring_alloc(xhci_hcd*, unsigned int, unsigned int, xhci_ring_type, unsigned int, gfp_t)'
[A] 'function void xhci_ring_cmd_db(xhci_hcd*)'
[A] 'function void xhci_ring_free(xhci_hcd*, xhci_ring*)'
[A] 'function long long unsigned int xhci_trb_virt_to_dma(xhci_segment*, xhci_trb*)'
2563 functions with some sub-type change:
[C] 'function void* PDE_DATA(const inode*)' at proc_fs.h:112:1 has some sub-type changes:
CRC (modversions) changed from 0x8f0b8b7c to 0xb095f157
[C] 'function void __ClearPageMovable(page*)' at compaction.c:138:1 has some sub-type changes:
CRC (modversions) changed from 0xb9a01cb4 to 0x8d0d1323
[C] 'function void __SetPageMovable(page*, address_space*)' at compaction.c:130:1 has some sub-type changes:
CRC (modversions) changed from 0x8981e72b to 0x33d724d0
... 2560 omitted; 2563 symbols have only CRC changes
7 Added variables:
[A] 'tracepoint __tracepoint_android_vh_ftrace_dump_buffer'
[A] 'tracepoint __tracepoint_android_vh_ftrace_format_check'
[A] 'tracepoint __tracepoint_android_vh_ftrace_oops_enter'
[A] 'tracepoint __tracepoint_android_vh_ftrace_oops_exit'
[A] 'tracepoint __tracepoint_android_vh_ftrace_size_check'
[A] 'kernel_stat kstat'
[A] 'int nr_irqs'
50 Changed variables:
[C] 'task_struct init_task' was changed at init_task.c:64:1:
size of symbol changed from 4288 to 4480
CRC (modversions) changed from 0x81ecaff to 0x4b41d5a6
type of variable changed:
type size changed from 34304 to 35840 (in bits)
8 data member insertions:
'u64 task_struct::android_kabi_reserved1', at offset 26176 (in bits) at sched.h:1374:1
'u64 task_struct::android_kabi_reserved2', at offset 26240 (in bits) at sched.h:1375:1
'u64 task_struct::android_kabi_reserved3', at offset 26304 (in bits) at sched.h:1376:1
'u64 task_struct::android_kabi_reserved4', at offset 26368 (in bits) at sched.h:1377:1
'u64 task_struct::android_kabi_reserved5', at offset 26432 (in bits) at sched.h:1378:1
'u64 task_struct::android_kabi_reserved6', at offset 26496 (in bits) at sched.h:1379:1
'u64 task_struct::android_kabi_reserved7', at offset 26560 (in bits) at sched.h:1380:1
'u64 task_struct::android_kabi_reserved8', at offset 26624 (in bits) at sched.h:1381:1
there are data member changes:
type 'struct sched_entity' of 'task_struct::se' changed:
type size changed from 3584 to 4096 (in bits)
4 data member insertions:
'u64 sched_entity::android_kabi_reserved1', at offset 3584 (in bits) at sched.h:490:1
'u64 sched_entity::android_kabi_reserved2', at offset 3648 (in bits) at sched.h:491:1
'u64 sched_entity::android_kabi_reserved3', at offset 3712 (in bits) at sched.h:492:1
'u64 sched_entity::android_kabi_reserved4', at offset 3776 (in bits) at sched.h:493:1
2622 impacted interfaces
type 'struct sched_rt_entity' of 'task_struct::rt' changed:
type size changed from 384 to 640 (in bits)
4 data member insertions:
'u64 sched_rt_entity::android_kabi_reserved1', at offset 384 (in bits) at sched.h:513:1
'u64 sched_rt_entity::android_kabi_reserved2', at offset 448 (in bits) at sched.h:514:1
'u64 sched_rt_entity::android_kabi_reserved3', at offset 512 (in bits) at sched.h:515:1
'u64 sched_rt_entity::android_kabi_reserved4', at offset 576 (in bits) at sched.h:516:1
2622 impacted interfaces
and offset changed from 5120 to 5632 (in bits) (by +512 bits)
133 ('task_group* task_struct::sched_task_group' .. 'tlbflush_unmap_batch task_struct::tlb_ubc') offsets changed (by +768 bits)
anonymous data member 'union {refcount_t rcu_users; callback_head rcu;}' offset changed from 19648 to 20416 (in bits) (by +768 bits)
20 ('pipe_inode_info* task_struct::splice_pipe' .. 'u64 task_struct::android_oem_data1[6]') offsets changed (by +768 bits)
'thread_struct task_struct::thread' offset changed (by +1280 bits)
2622 impacted interfaces
[C] 'task_group root_task_group' was changed at core.c:7335:1:
CRC (modversions) changed from 0x88b74fcd to 0xa2be3823
type of variable changed:
type size hasn't changed
4 data member insertions:
'u64 task_group::android_kabi_reserved1', at offset 3200 (in bits) at sched.h:433:1
'u64 task_group::android_kabi_reserved2', at offset 3264 (in bits) at sched.h:434:1
'u64 task_group::android_kabi_reserved3', at offset 3328 (in bits) at sched.h:435:1
'u64 task_group::android_kabi_reserved4', at offset 3392 (in bits) at sched.h:436:1
2622 impacted interfaces
[C] 'rq runqueues' was changed at core.c:49:1:
CRC (modversions) changed from 0xc91ed962 to 0xed491a1
type of variable changed:
type size hasn't changed
4 data member insertions:
'u64 rq::android_kabi_reserved1', at offset 32832 (in bits) at sched.h:1072:1
'u64 rq::android_kabi_reserved2', at offset 32896 (in bits) at sched.h:1073:1
'u64 rq::android_kabi_reserved3', at offset 32960 (in bits) at sched.h:1074:1
'u64 rq::android_kabi_reserved4', at offset 33024 (in bits) at sched.h:1075:1
2622 impacted interfaces
[C] 'bus_type amba_bustype' was changed at bus.c:215:1:
CRC (modversions) changed from 0x51184ff2 to 0x5e5bc98f
[C] 'const clk_ops clk_fixed_factor_ops' was changed at clk-fixed-factor.c:60:1:
CRC (modversions) changed from 0x3c1cb271 to 0xd048978b
[C] 'const clk_ops clk_fixed_rate_ops' was changed at clk-fixed-rate.c:46:1:
CRC (modversions) changed from 0xd36c1692 to 0x6b88426a
... 44 omitted; 47 symbols have only CRC changes
'struct class at class.h:54:1' changed:
type size changed from 960 to 1024 (in bits)
1 data member insertion:
'u64 class::android_kabi_reserved1', at offset 960 (in bits) at class.h:79:1
2622 impacted interfaces
'struct device_link at device.h:571:1' changed:
type size changed from 6976 to 7104 (in bits)
2 data member insertions:
'u64 device_link::android_kabi_reserved1', at offset 6976 (in bits) at device.h:585:1
'u64 device_link::android_kabi_reserved2', at offset 7040 (in bits) at device.h:586:1
2 impacted interfaces
'struct device_node at of.h:51:1' changed (indirectly):
type size changed from 1920 to 1984 (in bits)
there are data member changes:
type 'struct fwnode_handle' of 'device_node::fwnode' changed:
type size changed from 512 to 576 (in bits)
1 data member insertion:
'u64 fwnode_handle::android_kabi_reserved1', at offset 512 (in bits) at fwnode.h:38:1
2622 impacted interfaces
8 ('property* device_node::properties' .. 'void* device_node::data') offsets changed (by +64 bits)
2622 impacted interfaces
'struct fwnode_handle at fwnode.h:30:1' changed:
details were reported earlier
'struct iommu_flush_ops at io-pgtable.h:39:1' changed:
type size changed from 256 to 192 (in bits)
1 data member deletion:
'void (unsigned long int, typedef size_t, typedef size_t, void*)* iommu_flush_ops::tlb_flush_leaf', at offset 128 (in bits) at io-pgtable.h:43:1
there are data member changes:
'void (iommu_iotlb_gather*, unsigned long int, typedef size_t, void*)* iommu_flush_ops::tlb_add_page' offset changed (by -64 bits)
one impacted interface
'struct iommu_ops at iommu.h:248:1' changed:
type size hasn't changed
there are data member changes:
type 'void (iommu_domain*)*' of 'iommu_ops::iotlb_sync_map' changed:
pointer type changed from: 'void (iommu_domain*)*' to: 'void (iommu_domain*, unsigned long int, typedef size_t)*'
2622 impacted interfaces
'struct module at module.h:366:1' changed:
type size hasn't changed
4 data member insertions:
'u64 module::android_kabi_reserved1', at offset 7232 (in bits) at module.h:550:1
'u64 module::android_kabi_reserved2', at offset 7296 (in bits) at module.h:551:1
'u64 module::android_kabi_reserved3', at offset 7360 (in bits) at module.h:552:1
'u64 module::android_kabi_reserved4', at offset 7424 (in bits) at module.h:553:1
2622 impacted interfaces
'struct root_domain at sched.h:777:1' changed:
type size changed from 14848 to 15104 (in bits)
4 data member insertions:
'u64 root_domain::android_kabi_reserved1', at offset 14848 (in bits) at sched.h:838:1
'u64 root_domain::android_kabi_reserved2', at offset 14912 (in bits) at sched.h:839:1
'u64 root_domain::android_kabi_reserved3', at offset 14976 (in bits) at sched.h:840:1
'u64 root_domain::android_kabi_reserved4', at offset 15040 (in bits) at sched.h:841:1
2622 impacted interfaces
'struct rq at sched.h:897:1' changed:
details were reported earlier
'struct sched_entity at sched.h:452:1' changed:
details were reported earlier
'struct sched_rt_entity at sched.h:490:1' changed:
details were reported earlier
'struct signal_struct at signal.h:82:1' changed:
type size changed from 8448 to 8704 (in bits)
4 data member insertions:
'u64 signal_struct::android_kabi_reserved1', at offset 8448 (in bits) at signal.h:240:1
'u64 signal_struct::android_kabi_reserved2', at offset 8512 (in bits) at signal.h:241:1
'u64 signal_struct::android_kabi_reserved3', at offset 8576 (in bits) at signal.h:242:1
'u64 signal_struct::android_kabi_reserved4', at offset 8640 (in bits) at signal.h:243:1
2622 impacted interfaces
'struct sk_buff at skbuff.h:714:1' changed:
type size hasn't changed
2 data member insertions:
'__u8 sk_buff::from_ingress', at offset 1 (in bits) at skbuff.h:857:1
'__u8 sk_buff::redirected', at offset 2 (in bits) at skbuff.h:856:1
343 impacted interfaces
'struct sock at sock.h:347:1' changed:
type size changed from 6144 to 6656 (in bits)
8 data member insertions:
'u64 sock::android_kabi_reserved1', at offset 6144 (in bits) at sock.h:525:1
'u64 sock::android_kabi_reserved2', at offset 6208 (in bits) at sock.h:526:1
'u64 sock::android_kabi_reserved3', at offset 6272 (in bits) at sock.h:527:1
'u64 sock::android_kabi_reserved4', at offset 6336 (in bits) at sock.h:528:1
'u64 sock::android_kabi_reserved5', at offset 6400 (in bits) at sock.h:529:1
'u64 sock::android_kabi_reserved6', at offset 6464 (in bits) at sock.h:530:1
'u64 sock::android_kabi_reserved7', at offset 6528 (in bits) at sock.h:531:1
'u64 sock::android_kabi_reserved8', at offset 6592 (in bits) at sock.h:532:1
284 impacted interfaces
'struct task_group at sched.h:379:1' changed:
details were reported earlier
'struct task_struct at sched.h:641:1' changed:
details were reported earlier
'struct vfsmount at mount.h:71:1' changed:
type size changed from 192 to 448 (in bits)
4 data member insertions:
'u64 vfsmount::android_kabi_reserved1', at offset 192 (in bits) at mount.h:77:1
'u64 vfsmount::android_kabi_reserved2', at offset 256 (in bits) at mount.h:78:1
'u64 vfsmount::android_kabi_reserved3', at offset 320 (in bits) at mount.h:79:1
'u64 vfsmount::android_kabi_reserved4', at offset 384 (in bits) at mount.h:80:1
2622 impacted interfaces
'struct vm_area_struct at mm_types.h:306:1' changed:
type size changed from 1600 to 1856 (in bits)
4 data member insertions:
'u64 vm_area_struct::android_kabi_reserved1', at offset 1600 (in bits) at mm_types.h:388:1
'u64 vm_area_struct::android_kabi_reserved2', at offset 1664 (in bits) at mm_types.h:389:1
'u64 vm_area_struct::android_kabi_reserved3', at offset 1728 (in bits) at mm_types.h:390:1
'u64 vm_area_struct::android_kabi_reserved4', at offset 1792 (in bits) at mm_types.h:391:1
2622 impacted interfaces
'struct vsock_sock at af_vsock.h:27:1' changed (indirectly):
type size changed from 10176 to 10688 (in bits)
there are data member changes:
type 'struct sock' of 'vsock_sock::sk' changed, as reported earlier
25 ('const vsock_transport* vsock_sock::transport' .. 'void* vsock_sock::trans') offsets changed (by +512 bits)
30 impacted interfaces
'struct zone at mmzone.h:450:1' changed:
type size hasn't changed
4 data member insertions:
'u64 zone::android_kabi_reserved1', at offset 12544 (in bits) at mmzone.h:606:1
'u64 zone::android_kabi_reserved2', at offset 12608 (in bits) at mmzone.h:607:1
'u64 zone::android_kabi_reserved3', at offset 12672 (in bits) at mmzone.h:608:1
'u64 zone::android_kabi_reserved4', at offset 12736 (in bits) at mmzone.h:609:1
2622 impacted interfaces
Bug: 183612421
Change-Id: I22fb5e4bf670ae630a439678055a92b7f9f6e363
Vendors want to get en/dequeueing information and update
some vendor-managed data to modifiy DVFS or scheduling behavior.
But in the current hooking positions, vendors get the information
after all behaviors they want to modify are done.
So need to move the hooks before en/dequeue callbacks
to achieve the "true" goals.
Bug: 183543978
Signed-off-by: Choonghoon Park <choong.park@samsung.com>
Change-Id: I12f8e77054d12a855df10ca9d13a52d417343666
Patch series "arch, mm: improve robustness of direct map manipulation", v7.
During recent discussion about KVM protected memory, David raised a
concern about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC
scope [1].
Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is
possible that __kernel_map_pages() would fail, but since this function is
void, the failure will go unnoticed.
Moreover, there's lack of consistency of __kernel_map_pages() semantics
across architectures as some guard this function with #ifdef
DEBUG_PAGEALLOC, some refuse to update the direct map if page allocation
debugging is disabled at run time and some allow modifying the direct map
regardless of DEBUG_PAGEALLOC settings.
This set straightens this out by restoring dependency of
__kernel_map_pages() on DEBUG_PAGEALLOC and updating the call sites
accordingly.
Since currently the only user of __kernel_map_pages() outside
DEBUG_PAGEALLOC is hibernation, it is updated to make direct map accesses
there more explicit.
[1] https://lore.kernel.org/lkml/2759b4bf-e1e3-d006-7d86-78a40348269d@redhat.com
This patch (of 4):
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded with with debug_pagealloc_enabled().
The only place that calls __kernel_map_pages() without checking whether
DEBUG_PAGEALLOC is enabled is the hibernation code that presumes
availability of this function when ARCH_HAS_SET_DIRECT_MAP is set. Still,
on arm64, __kernel_map_pages() will bail out when DEBUG_PAGEALLOC is not
enabled but set_direct_map_invalid_noflush() may render some pages not
present in the direct map and hibernation code won't be able to save such
pages.
To make page allocation debugging and hibernation interaction more robust,
the dependency on DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP has to be
made more explicit.
Start with combining the guard condition and the call to
__kernel_map_pages() into debug_pagealloc_map_pages() and
debug_pagealloc_unmap_pages() functions to emphasize that
__kernel_map_pages() should not be called without DEBUG_PAGEALLOC and use
these new functions to map/unmap pages when page allocation debugging is
enabled.
Link: https://lkml.kernel.org/r/20201109192128.960-1-rppt@kernel.org
Link: https://lkml.kernel.org/r/20201109192128.960-2-rppt@kernel.org
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 77bc7fd607https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I9f0dac574bc3a7ea7d88bff051b77eca19610ce9
CONFIG_PAGE_POISONING_ZERO uses the zero pattern instead of 0xAA. It was
introduced by commit 1414c7f4f7 ("mm/page_poisoning.c: allow for zero
poisoning"), noting that using zeroes retains the benefit of sanitizing
content of freed pages, with the benefit of not having to zero them again
on alloc, and the downside of making some forms of corruption (stray
writes of NULLs) harder to detect than with the 0xAA pattern. Together
with CONFIG_PAGE_POISONING_NO_SANITY it made possible to sanitize the
contents on free without checking it back on alloc.
These days we have the init_on_free() option to achieve sanitization with
zeroes and to save clearing on alloc (and without checking on alloc).
Arguably if someone does choose to check the poison for corruption on
alloc, the savings of not clearing the page are secondary, and it makes
sense to always use the 0xAA poison pattern. Thus, remove the
CONFIG_PAGE_POISONING_ZERO option for being redundant.
Link: https://lkml.kernel.org/r/20201113104033.22907-6-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Mateusz Nosek <mateusznosek0@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit f289041ed4https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I57e19d1dd77d3d5eec40f94c1b64a877c3710baa
commit 6471384af2 ("mm: security: introduce init_on_alloc=1 and
init_on_free=1 boot options") resulted with init_on_alloc=1 in all pages
leaving the buddy via alloc_pages() and friends to be
initialized/cleared/zeroed on allocation.
However, the same logic is currently not applied to alloc_contig_pages():
allocated pages leaving the buddy aren't cleared with init_on_alloc=1 and
init_on_free=0. Let's also properly clear pages on that allocation path.
To achieve that, let's move clearing into post_alloc_hook(). This will
not only affect alloc_contig_pages() allocations but also any pages used
as migration target in compaction code via compaction_alloc().
While this sounds sub-optimal, it's the very same handling as when
allocating migration targets via alloc_migration_target() - pages will get
properly cleared with init_on_free=1. In case we ever want to optimize
migration in that regard, we should tackle all such migration users - if
we believe migration code can be fully trusted.
With this change, we will see double clearing of pages in some cases. One
example are gigantic pages (either allocated via CMA, or allocated
dynamically via alloc_contig_pages()) - which is the right thing to do
(and to be optimized outside of the buddy in the callers) as discussed in:
https://lkml.kernel.org/r/20201019182853.7467-1-gpiccoli@canonical.com
This change implies that with init_on_alloc=1
- All CMA allocations will be cleared
- Gigantic pages allocated via alloc_contig_pages() will be cleared
- virtio-mem memory to be unplugged will be cleared. While this is
suboptimal, it's similar to memory balloon drivers handling, where
all pages to be inflated will get cleared as well.
- Pages isolated for compaction will be cleared
Link: https://lkml.kernel.org/r/20201120180452.19071-1-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 862b6dee20https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: Ie400a475598a5fae888d6bad32f32355a2d153b7
Page poisoning used to be incompatible with hibernation, as the state of
poisoned pages was lost after resume, thus enabling CONFIG_HIBERNATION
forces CONFIG_PAGE_POISONING_NO_SANITY. For the same reason, the
poisoning with zeroes variant CONFIG_PAGE_POISONING_ZERO used to disable
hibernation. The latter restriction was removed by commit 1ad1410f63
("PM / Hibernate: allow hibernation with PAGE_POISONING_ZERO") and
similarly for init_on_free by commit 18451f9f9e ("PM: hibernate: fix
crashes with init_on_free=1") by making sure free pages are cleared after
resume.
We can use the same mechanism to instead poison free pages with
PAGE_POISON after resume. This covers both zero and 0xAA patterns. Thus
we can remove the Kconfig restriction that disables page poison sanity
checking when hibernation is enabled.
Link: https://lkml.kernel.org/r/20201113104033.22907-4-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [hibernation]
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Mateusz Nosek <mateusznosek0@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 03b6c9a3e8https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: Ieea49ebb4d3eeddd18eb2040f13b8121978facca
Commit 11c9c7edae ("mm/page_poison.c: replace bool variable with static
key") changed page_poisoning_enabled() to a static key check. However,
the function is not inlined, so each check still involves a function call
with overhead not eliminated when page poisoning is disabled.
Analogically to how debug_pagealloc is handled, this patch converts
page_poisoning_enabled() back to boolean check, and introduces
page_poisoning_enabled_static() for fast paths. Both functions are
inlined.
The function kernel_poison_pages() is also called unconditionally and does
the static key check inside. Remove it from there and put it to callers.
Also split it to two functions kernel_poison_pages() and
kernel_unpoison_pages() instead of the confusing bool parameter.
Also optimize the check that enables page poisoning instead of
debug_pagealloc for architectures without proper debug_pagealloc support.
Move the check to init_mem_debugging_and_hardening() to enable a single
static key instead of having two static branches in
page_poisoning_enabled_static().
Link: https://lkml.kernel.org/r/20201113104033.22907-3-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Mateusz Nosek <mateusznosek0@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 8db26a3d47https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: Ifc3fdf5cd58f3b8346bf81480df3836811e7458b
Patch series "cleanup page poisoning", v3.
I have identified a number of issues and opportunities for cleanup with
CONFIG_PAGE_POISON and friends:
- interaction with init_on_alloc and init_on_free parameters depends on
the order of parameters (Patch 1)
- the boot time enabling uses static key, but inefficienty (Patch 2)
- sanity checking is incompatible with hibernation (Patch 3)
- CONFIG_PAGE_POISONING_NO_SANITY can be removed now that we have
init_on_free (Patch 4)
- CONFIG_PAGE_POISONING_ZERO can be most likely removed now that we
have init_on_free (Patch 5)
This patch (of 5):
Enabling page_poison=1 together with init_on_alloc=1 or init_on_free=1
produces a warning in dmesg that page_poison takes precedence. However,
as these warnings are printed in early_param handlers for
init_on_alloc/free, they are not printed if page_poison is enabled later
on the command line (handlers are called in the order of their
parameters), or when init_on_alloc/free is always enabled by the
respective config option - before the page_poison early param handler is
called, it is not considered to be enabled. This is inconsistent.
We can remove the dependency on order by making the init_on_* parameters
only set a boolean variable, and postponing the evaluation after all early
params have been processed. Introduce a new
init_mem_debugging_and_hardening() function for that, and move the related
debug_pagealloc processing there as well.
As a result init_mem_debugging_and_hardening() knows always accurately if
init_on_* and/or page_poison options were enabled. Thus we can also
optimize want_init_on_alloc() and want_init_on_free(). We don't need to
check page_poisoning_enabled() there, we can instead not enable the
init_on_* static keys at all, if page poisoning is enabled. This results
in a simpler and more effective code.
Link: https://lkml.kernel.org/r/20201113104033.22907-1-vbabka@suse.cz
Link: https://lkml.kernel.org/r/20201113104033.22907-2-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mateusz Nosek <mateusznosek0@gmail.com>
Cc: Laura Abbott <labbott@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 04013513cchttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
[glider: resolved a minor conflict in init/main.c - API change]
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I6c0ffcb0d8e2f56a688986aa1dc201adf89de067
During boot, all non-reserved memblock memory is exposed to page_alloc via
memblock_free_pages->__free_pages_core(). This results in
kasan_free_pages() being called, which poisons that memory.
Poisoning all that memory lengthens boot time. The most noticeable effect
is observed with the HW_TAGS mode. A boot-time impact may potentially
also affect systems with large amount of RAM.
This patch changes the tag-based modes to not poison the memory during the
memblock->page_alloc transition.
An exception is made for KASAN_GENERIC. Since it marks all new memory as
accessible, not poisoning the memory released from memblock will lead to
KASAN missing invalid boot-time accesses to that memory.
With KASAN_SW_TAGS, as it uses the invalid 0xFE tag as the default tag for
all memory, it won't miss bad boot-time accesses even if the poisoning of
memblock memory is removed.
With KASAN_HW_TAGS, the default memory tags values are unspecified.
Therefore, if memblock poisoning is removed, this KASAN mode will miss the
mentioned type of boot-time bugs with a 1/16 probability. This is taken
as an acceptable trafe-off.
Internally, the poisoning is removed as follows. __free_pages_core() is
used when exposing fresh memory during system boot and when onlining
memory during hotplug. This patch adds a new FPI_SKIP_KASAN_POISON flag
and passes it to __free_pages_ok() through free_pages_prepare() from
__free_pages_core(). If FPI_SKIP_KASAN_POISON is set, kasan_free_pages()
is not called.
All memory allocated normally when the boot is over keeps getting poisoned
as usual.
Link: https://lkml.kernel.org/r/a0570dc1e3a8f39a55aa343a1fc08cd5c2d4cad6.1613692950.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Branislav Rankov <Branislav.Rankov@arm.com>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit d07a05953b6067f4295dc1a81ee4cda10615f784
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I3b26994bb3e2b9d8e85d001d817a37892bf0477c
Currently, KASAN_SW_TAGS uses 0xFF as the default tag value for
unallocated memory. The underlying idea is that since that memory hasn't
been allocated yet, it's only supposed to be dereferenced through a
pointer with the native 0xFF tag.
While this is a good idea in terms on consistency, practically it doesn't
bring any benefit. Since the 0xFF pointer tag is a match-all tag, it
doesn't matter what tag the accessed memory has. No accesses through
0xFF-tagged pointers are considered buggy by KASAN.
This patch changes the default tag value for unallocated memory to 0xFE,
which is the tag KASAN uses for inaccessible memory. This doesn't affect
accesses through 0xFF-tagged pointer to this memory, but this allows KASAN
to detect wild and large out-of-bounds invalid memory accesses through
otherwise-tagged pointers.
This is a prepatory patch for the next one, which changes the tag-based
KASAN modes to not poison the boot memory.
Link: https://lkml.kernel.org/r/c8e93571c18b3528aac5eb33ade213bf133d10ad.1613692950.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Branislav Rankov <Branislav.Rankov@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Marco Elver <elver@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit 7b40fcc93f6139e8979d791580f84f79ea67c9d8
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: Ia06c03058a77e30ddd875fa0e189e679b8404333
To allow performing tag checks on page_alloc addresses obtained via
page_address(), tag-based KASAN modes store tags for page_alloc
allocations in page->flags.
Currently, the default tag value stored in page->flags is 0x00.
Therefore, page_address() returns a 0x00ffff... address for pages that
were not allocated via page_alloc.
This might cause problems. A particular case we encountered is a conflict
with KFENCE. If a KFENCE-allocated slab object is being freed via
kfree(page_address(page) + offset), the address passed to kfree() will get
tagged with 0x00 (as slab pages keep the default per-page tags). This
leads to is_kfence_address() check failing, and a KFENCE object ending up
in normal slab freelist, which causes memory corruptions.
This patch changes the way KASAN stores tag in page-flags: they are now
stored xor'ed with 0xff. This way, KASAN doesn't need to initialize
per-page flags for every created page, which might be slow.
With this change, page_address() returns natively-tagged (with 0xff)
pointers for pages that didn't have tags set explicitly.
This patch fixes the encountered conflict with KFENCE and prevents more
similar issues that can occur in the future.
Link: https://lkml.kernel.org/r/1a41abb11c51b264511d9e71c303bb16d5cb367b.1615475452.git.andreyknvl@google.com
Fixes: 2813b9c029 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc")
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Branislav Rankov <Branislav.Rankov@arm.com>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit e671110d7acf7936013d309ff47ebe645f880992
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 182930667
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I3cd514ed31d2742cf800ff85074c69930aec2771
Currently a non-root user may have the rights to create directories
in configfs, but they default to being owned by root, so you can't
create anything inside of the directories you yourself created.
phone:/config/usb_gadget/g1/configs $ id; mkdir b.2; ls -lZ; chown system:system b.2
uid=1000(system) gid=1000(system) groups=1000(system),1004(input),1007(log),1011(adb),...
drwxr-xr-x 3 system system u:object_r:configfs:s0 0 2020-12-28 06:03 b.1
drwxr-xr-x 3 root root u:object_r:configfs:s0 0 2020-12-28 06:51 b.2
chown: 'b.2' to 'system:system': Operation not permitted
phone:/config/usb_gadget/g1/configs $ ln -s ../../../../usb_gadget/g1/functions/ffs.adb b.2/function0
ln: cannot create symbolic link from '../../../../usb_gadget/g1/functions/ffs.adb' to 'b.2/function0': Permission denied
Test: With this change b.2 is owned by system:system and the ln succeeds.
Link: https://lore.kernel.org/lkml/20210123205516.2738060-1-zenczykowski@gmail.com/
Bug: 172793258
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia907b2def940197b44aa87b337d37c5dde9c5b91
These structures are fundamental to implementing fw_devlink and
sync_state(). Since they are still evolving, add some padding in case we
need to backport any important bug fixes.
struct device_link
struct class
struct fwnode_handle
struct fwnode_link
Bug: 183615740
Signed-off-by: Saravana Kannan <saravanak@google.com>
Change-Id: Id9daf7cf9ae5d94fb0134144f8220a241ccbaef8
This error path is supposed to return -EINVAL. It used to return
directly but we added some clean up and accidentally removed the
error code. Also I fixed a typo in the error message.
Fixes: c0b57581b7 ("iommu/mediatek: Add power-domain operation")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Link: https://lore.kernel.org/r/YB0+GU5akSdu29Vu@mwanda
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit a92a90ac62)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I65e9f85408625df6c827ef835089d847a8ab7257
After extending v7s, our pagetable already support iova reach
16GB(34bit). the master got the iova via dma_alloc_attrs may reach
34bits, but its HW register still is 32bit. then how to set the
bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
we separate whole 16GB iova to four banks:
bank: 0: 0~4G; 1: 4~8G; 2: 8-12G; 3: 12-16G;
The bank number is (iova >> 32).
We will preassign which bank the larbs belong to. currently we don't
have a interface for master to adjust its bank number.
Each a bank is a iova_region which is a independent iommu-domain.
the iova range for each iommu-domain can't cross 4G.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org> #for memory part
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-31-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 8d2c749e52)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I0d397b100026b04747c753233f0dea0a1d5cf2ee
Some HW IP(ex: CCU) require the special iova range. That means the iova
got from dma_alloc_attrs for that devices must locate in his special range.
In this patch, we prepare a iommu group(domain) for each a iova range
requirement.
Meanwhile we still use one pagetable which support 16GB iova.
After this patch, If the iova range of a master is over 4G, the master
should:
a) Declare its special dma-ranges in its dtsi node. For example, If we
preassign the iova 4G-8G for vcodec, then the vcodec dtsi node should
add this:
/*
* iova start at 0x1_0000_0000, pa still start at 0x4000_0000
* size is 0x1_0000_0000.
*/
dma-ranges = <0x1 0x0 0x0 0x40000000 0x1 0x0>; /* 4G ~ 8G */
Note: we don't have a actual bus concept here. the master doesn't have its
special parent node, thus this dma-ranges can only be put in the master's
node.
b) Update the dma_mask:
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(33));
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-29-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit c3045f3924)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Id104c9ffa0ffae47b13be5f9d71029bead0cd926
Add a new interface _get_domain_id from dev->dma_range_map,
The iommu consumer device will use dma-ranges in dtsi node to indicate
its dma address region requirement. In this iommu driver, we will get
the requirement and decide which iova domain it should locate.
In the lastest SoC, there will be several iova-regions(domains), we will
compare and calculate which domain is right. If the start/end of device
requirement equal some region. it is best fit of course. If it is inside
some region, it is also ok. the iova requirement of a device should not
be inside two or more regions.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-28-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 803cf9e5a6)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ic41106a406bcbb375aa8f507232ab847a2d9c4e0
Currently domain_alloc only has a parameter(type), We have no chance to
input some special data. This patch moves the domain_finalise into
attach_device which has the device information, then could update
the domain's geometry.aperture ranges for each a device.
Strictly, I should use the data from mtk_iommu_get_m4u_data as the
parameter of mtk_iommu_domain_finalise in this patch. but dom->data
only is used in tlb ops in which the data is get from the m4u_list, thus
it is ok here.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-25-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 4f956c97d2)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I1abc9d7a17eb7a4df5fae01b422525fd4f012384
In the previous SoC, the M4U HW is in the EMI power domain which is
always on. the latest M4U is in the display power domain which may be
turned on/off, thus we have to add pm_runtime interface for it.
When the engine work, the engine always enable the power and clocks for
smi-larb/smi-common, then the M4U's power will always be powered on
automatically via the device link with smi-common.
Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
If its power already is on, of course it is ok. if the power is off,
the main tlb will be reset while M4U power on, thus the tlb flush while
m4u power off is unnecessary, just skip it.
Therefore, we increase the ref_count for pm when pm status is ACTIVE,
otherwise, skip it. Meanwhile, the tlb_flush_range is called so often,
thus, update pm ref_count while the SoC has power-domain to avoid touch the
dev->power.lock. and the tlb_flush_all only is called when boot, so no
need check if the SoC has power-domain to keep code clean.
There will be one case that pm runctime status is not expected when tlb
flush. After boot, the display may call dma_alloc_attrs before it call
pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
at that time, I also think this is ok.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-21-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit c0b57581b7)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ice851a821fdc1c04cb2835a495e852a61bc9536f
