It needs to export some symbols so that vendor module could reference.
Bug: 170507310
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I1b3c3ea8d0a11c01a1ca9e124e93f85e52856dc4
(cherry picked from commit a61271a41a2c2825a51bd7655fc446e16d23f5f6)
Signed-off-by: Will McVicker <willmcvicker@google.com>
This is to add capability for vendor to decide whether a cpufreq update
is needed, e.g. up/down rate limit.
Using restricted hook since it can be called from scheduler wakeup path.
Bug: 170511085
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: If9adea3a3e31efbf3858fbd009665a07dc70c638
(cherry picked from commit f9f3464532a045257f8138338b1beda86ef0a3be)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Upstream moved the sugov to DEADLINE class which has higher prio than RT
so it can potentially block many RT use case in Android.
Also currently iowait doesn't distinguish background/foreground tasks
and we have seen cases where device run to high frequency unnecessarily
when running some background I/O.
Bug: 171598214
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I21e9bfe9ef75a4178279574389e417c3f38e65ac
(cherry picked from commit 03177ef82bd942a3f163e826063491bae6ff0ac9)
Signed-off-by: Will McVicker <willmcvicker@google.com>
trace_sched_blocked_trace in CFS is really useful for debugging via
trace because it tell where the process was stuck on callstack.
For example,
<...>-6143 ( 6136) [005] d..2 50.278987: sched_blocked_reason: pid=6136 iowait=0 caller=SyS_mprotect+0x88/0x208
<...>-6136 ( 6136) [005] d..2 50.278990: sched_blocked_reason: pid=6142 iowait=0 caller=do_page_fault+0x1f4/0x3b0
<...>-6142 ( 6136) [006] d..2 50.278996: sched_blocked_reason: pid=6144 iowait=0 caller=SyS_prctl+0x52c/0xb58
<...>-6144 ( 6136) [006] d..2 50.279007: sched_blocked_reason: pid=6136 iowait=0 caller=vm_mmap_pgoff+0x74/0x104
However, sometime it gives pointless information like this.
RenderThread-2322 ( 1805) [006] d.s3 50.319046: sched_blocked_reason: pid=6136 iowait=1 caller=__lock_page_killable+0x17c/0x220
logd.writer-594 ( 587) [002] d.s3 50.334011: sched_blocked_reason: pid=6126 iowait=1 caller=wait_on_page_bit+0x194/0x208
kworker/u16:13-333 ( 333) [007] d.s4 50.343161: sched_blocked_reason: pid=6136 iowait=1 caller=__lock_page_killable+0x17c/0x220
Such wait_on_page_bit, __lock_page_killable are pointless because it doesn't
carry on higher information to identify the callstack.
The reason is page_lock and waitqueue are special synchronization method unlike
other normal locks(mutex, spinlock).
Let's mark them as "__sched" so get_wchan which used in trace_sched_blocked_trace
could detect it and skip them. It will produce more meaningful callstack
function like this.
<...>-2867 ( 1068) [002] d.h4 124.209701: sched_blocked_reason: pid=329 iowait=0 caller=worker_thread+0x378/0x470
<...>-2867 ( 1068) [002] d.s3 124.209763: sched_blocked_reason: pid=8454 iowait=1 caller=__filemap_fdatawait_range+0xa0/0x104
<...>-2867 ( 1068) [002] d.s4 124.209803: sched_blocked_reason: pid=869 iowait=0 caller=worker_thread+0x378/0x470
ScreenDecoratio-2364 ( 1867) [002] d.s3 124.209973: sched_blocked_reason: pid=8454 iowait=1 caller=f2fs_wait_on_page_writeback+0x84/0xcc
ScreenDecoratio-2364 ( 1867) [002] d.s4 124.209986: sched_blocked_reason: pid=869 iowait=0 caller=worker_thread+0x378/0x470
<...>-329 ( 329) [000] d..3 124.210435: sched_blocked_reason: pid=538 iowait=0 caller=worker_thread+0x378/0x470
kworker/u16:13-538 ( 538) [007] d..3 124.210450: sched_blocked_reason: pid=6 iowait=0 caller=worker_thread+0x378/0x470
Test: build pass and boot to home.
Bug: 144961676
Bug: 144713689
Bug: 172212772
Signed-off-by: Minchan Kim <minchan@google.com>
Signed-off-by: Jimmy Shiu <jimmyshiu@google.com>
Change-Id: I9c738802a16941ca767dcc37ae4463070b3fabf4
(cherry picked from commit 1e4de875d9e0cfaccf5131bcc709ae8646cdc168)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Add hooks for vendor specific find_energy_efficient_cpu logic.
Bug: 170507310
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I064b501017e32d4f22f8128bed8bf3a1508ab15b
(cherry picked from commit 2f108e2ec6e89609cbae32c5d13d6ad9f2e858cb)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Vendor cooling device driver need
arch_set_thermal_pressure/topology_set_thermal_pressure to notify
scheduler for thermal limit change.
Test: boot and check trace
Bug: 172387671
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I777cb652a98cb4ca457ccdc9a32300aae6c2b37f
(cherry picked from commit fb06869994d6f7efc411230c067aee7fb3bb25ac)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Below symbols would be used by vendor modules to make better placement
decisions when respective hooks are registered.
1. uclamp_eff_value
2. idle_cpu
Bug: 174219212
Change-Id: I2b41ce9a7c3fb67a8170c5c253985c722f06e85a
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
In the context of GKI we are exporting quite a few internal kernel
symbols, some of which may be static functions (yes this is bad, but
technically it works). As such, we need to be careful about conflicts
and we really should not allow a symbol to be exported more than once.
To ensure this is the case, turn the modpost check 'fatal' to bail out
immediately when such a situation is detected.
Bug: 174214891
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I674c9c9c327849503e94d79654e6288411a830af
Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
Modpost currently reports that as a warning, but clearly this is not a
pattern we should allow, and all in-tree occurences should have been
fixed by now. So, promote the warn() message to fatal() to make sure
this never happens again.
Bug: 174214891
Link: https://lore.kernel.org/lkml/20201124182420.2202514-1-qperret@google.com/
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ic1382bfa24db556161cf1a184a4d44724d7849a1
Bug: 170682696
Test: boot to home and thermal_genl_send_event worked properly.
Change-Id: I3764f6f8eaa47eab6f0941617bf6268bb3b4db4d
Signed-off-by: davidchao <davidchao@google.com>
(cherry picked from commit e8173a7565113b7ccdb32a9719f7ab028e070b02)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
android_rvh_sched_nohz_balancer_kick hook allows vendor modules to
select the busiest CPU in a group during load balance. When the
load balancer could not pull tasks from this busiest CPU due to
affinity restriction, the CPU is cleared from env->cpu. This must
be passed to the vendor module, otherwise we keep selecting the
exempted CPU as the busiest CPU.
Bug: 174338902
Change-Id: Iedaa389a51849da4c3e094d731fe5e39cd909d81
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
TD.4.7.3. Try SNK DRP Connect Try.SRC DRP fails. The compliance
tester mimics being a Try.SRC USB-C port.
The failure is due to TCPM exiting SNK_TRY_WAIT_DEBOUNCE_CHECK_VBUS
when VBUS is not present eventhough when SNK.Rp is seen. Exit to
SRC_TRYWAIT from SNK_TRY_WAIT_DEBOUNCE_CHECK_VBUS only when SNK.Rp
is not seen for PD_T_TRY_CC_DEBOUNCE.
>From the spec:
The port shall then transition to Attached.SNK when the SNK.Rp state
is detected on exactly one of the CC1 or CC2 pins for at least
tTryCCDebounce and VBUS is detected. Alternatively, the port shall
transition to TryWait.SRC if SNK.Rp state is not detected for
tTryCCDebounce.
Bug: 158724104
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201125014804.1596719-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 733315532b90d8dccfdc2d0d2744db4559d40e80
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit ee1142f3cbf23af75db98d235b5cbf950421ad9c)
(cherry picked from commit a723b4dd4fb4e44d4925ac52b1cca512f47bb1ab)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 10a1f26e421c83c7a3590a7c41211773ffd74a5f)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: Ieee7069dab909604291c331d7468e1408ada0a5e
During PR_SWAP sequence, when TCPM is waiting in PR_SWAP_SNK_SRC_SOURCE_ON
for the vbus source to ramp up, TCPM would prematurely exit
PR_SWAP_SNK_SRC_SOURCE_ON and transition to SNK_UNATTACHED state when a
vbus off notification is received. This should not be the case as vbus
can still be off while in PR_SWAP_SNK_SRC_SOURCE_ON and the vbus source
has PD_T_NEWSRC to ramp up.
Bug: 168555244
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201125020703.1604979-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3f461fba1f8f07d1a93c6489136b44c7300bb016
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I598c75bcca2d2b878897036f8a8dd6a1fc1d6fa3
BoringSSL does not implement the ENGINE API. In Android we do not seem
to rely on the PKCS#11 -> DER extraction. Hence, make this conditional
on the SSL library used.
Bug: 135570712
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I84af6633dd470083497087c7dd1a2734480e2b0e
vImplement callbacks for enabling/disabling
POWER_CONTROL.AutoDischargeDisconnect.
Programs VBUS_SINK_DISCONNECT_THRESHOLD based on the
voltage requested as sink, mode of operation.
The programmed threshold is based on vSinkDisconnect and
vSinkDisconnectPD values.
Add auto_discharge_disconnect to tdata to allow TCPC chip
level drivers enable AutoDischargeDisconnect.
Bug: 168555244
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201029063138.1429760-9-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e1a97bf80ahttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit 33936ca3f6348db3e2e79776b01bc8339c446c80)
(cherry picked from commit 3622a289e91fe57a4a6b8ca210119c1b645444ea)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 8285bc18a7fbf2409001ea1066136dd167a9cd97)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I896d47412ec6eaa23b87c38be545618f811253c8
TCPCI spec allows TCPC hardware to autonomously discharge the vbus
capacitance upon disconnect. The expectation is that the TCPM enables
AutoDischargeDisconnect while entering SNK/SRC_ATTACHED states. Hardware
then automously discharges vbus when the vbus falls below a certain
threshold i.e. VBUS_SINK_DISCONNECT_THRESHOLD.
Apart from enabling the vbus discharge circuit, AutoDischargeDisconnect
is also used a flag to move TCPCI based TCPC implementations into
Attached.Snk/Attached.Src state as mentioned in
Figure 4-15. TCPC State Diagram before a Connection of the
USB Type-C Port Controller Interface Specification.
In such TCPC implementations, setting AutoDischargeDisconnect would
prevent TCPC into entering "Connection_Invalid" state as well.
Bug: 168555244
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201029063138.1429760-8-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f321a02caehttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit e9a276bd2a70537eab1b4162cca9b7eeb0f1514a)
(cherry picked from commit a53a13168af75458cc57fe1e7a0e1129562fcd1a)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 303a32911f5aca961031f4c1d57ee9c713f9e6cb)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I3e25e9045c335b48cefaddb70329dd4df7e0fd94
Background:
We can allocate buffer from ion_system_heap for general case,
if the buffer is needed to access by HW, we need to map/unmap
dma_address by iommu driver before and after HW engine access for
iommu case. For example, if the same buffer is accessed by three
HW engines, then every device driver needs to map/unmap dma_address
by iommu driver respectively.
For MTK platform, all the multimedia HW engines use the same
iommu HW and share the same iommu page table, so multiple map/unmap
dma_address by iommu driver maybe reduce performance seriously for
above case, especially for big size buffer. In order to improve
performance for MTK platform, we want to add ion_mtk_iommu_heap
and implement map/unmap dma_address by ion_mtk_iommu_heap:
a.heap->buf_ops.map_dma_buf: If more than one attachments map
dma_address by iommu driver about the same buffer, the function
only map once in first attachment, the other attachments of buffer
copy sg_table which has already mapped to respective sg_table directly
and don't mapping dma_address truly.
b.heap->buf_ops.unmap_dma_buf: Do nothing.
c.heap->buf_ops.release: unmap dma_address by iommu driver about buffer
and free the buffer.
Based on above description:
We will build ion_mtk_iommu_heap as a kernel module and ion_mtk_iommu_heap
also use some APIs like ion_system_heap but they not do export symbol
ion_page_pool_alloc()
ion_page_pool_free()
ion_page_pool_nr_pages()
ion_page_pool_shrink()
ion_page_pool_create()
ion_page_pool_destroy()
Bug: 158729041
Bug: 170264063
Change-Id: If3897d5e0105edefe03a51ac52c7b3d423aaa988
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
(cherry picked from commit 34364883b1f7cf8aed0e3a36e38aa7803c73b203)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit 48979298f2c9f814293323e05754a9c1f2038146)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 4dad2d6066b354f9fb087430fca714ffdc05790f)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The begin[end]_cpu_access handles cache coherency.
However the kmap is always called here and it just
makes unnecessary overhead of kmap.
We don't need to call kmap on begin[end]_cpu_access
because ION no longer supports dma_buf_kmap callback
on ion dma, so remove it.
Bug: 158635261
Bug: 170264063
Signed-off-by: Hyesoo YU <hyesoo.yu@samsung.com>
Change-Id: I8a9a1715da2c0d7df59a3abe8790614b07f55fe6
(cherry picked from commit 0eb5f60e7dc89ed757b5fc29c488b21cc8a5a846)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit eb41cb99df24eaa68c936f1b62ae3afca4728014)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 2419380051284d5d00e6c053e69e13e977c41b0e)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
ion_dma_buf_unmap() interprets the priv pointer in the
attachment structure as a pointer to an ion_dma_buf_attachment
structure, and modifies the "mapped" field of that structure.
In cases where the heap specifies its own dma-buf ops, this
is not correct, as the priv pointer in the attachment structure
may point to a structure that is not an ion_dma_buf_attachment
structure, and thus, the current implementation of
ion_dma_buf_unmap() will modify the unknown structure--potentially
putting it in an inconsistent state--prior to calling the heap's
dma-buf unmap operation.
Thus, modify the structure pointed to by the priv field in the
attachment structure only if the heap doesn't provide its own
implementation of the unmap operation, as that guarantees that
the priv field points to an ion_dma_buf_attachment structure.
Bug: 157163668
Bug: 170264063
Change-Id: If79a90ae1ca54762bbead6e23518b21076efd44b
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
(cherry picked from commit 01b0584902c56d12569423ef8cdb37d3a132a629)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit af44ead94861b441f815786a55a6f6fcedb85b4e)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 2466e97c83568d752e56cec619488b891ca6e34c)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The non-cached ion buffer is flushed when allocated.
And then, that is is always mapped as non-cached after allocation.
In the absence of caching, cache maintenance operations
become unnecessary. However dma_buf_ops tries to maintain
cache coherency for non-cached buffer on begin[end]_cpu_access
and map[unmap]_dma_buf functions.
It creates unnecessary overhead, so let's remove it.
Bug: 151775080
Bug: 170264063
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Change-Id: I168117c7002aec7930c84168d15816a09750b7d8
Signed-off-by: Hridya Valsaraju <hridya@google.com>
(cherry picked from commit 2c3b4cba8ab38d7eb9f474c78f9b4c70867bf71d)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit 70c2ed5eefe64293a100a2c1c07445a708dde15c)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 4f71346c250416c3a6799458d773c4525a3d2ed6)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The [un]map_dma_buf receives dma_buf_attachment by
parameter. The caller could set the dma_map_attrs
on dma_buf_attachment such as DMA_ATTR_SKIP_CPU_SYNC,
and expects that attributes are applied.
The dma_[un]map_sg is changed into dma_[un]map_sg_attrs
to send the attributes.
Bug: 151775080
Bug: 170264063
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Change-Id: Id5ca12ff120bfeac53a84ffad91e7a219e2180cd
(cherry picked from commit 16ce0bda52c9948d52e5676359b6cade2662580f)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit da654356c8bfdd9420eb8a2ec1b60da034fb10b2)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit e53e099e2a849be6cf171d2d3c56715b415e3fc1)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Export the ion_query_heaps_kernel to allow the module
to get the registered heap information.
Bug: 149961819
Bug: 170264063
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Change-Id: I3756ef0cbd17611593c8d2f45e46476a864faaec
(cherry picked from commit 62060692112ba17dff2757dfcb7f9d40d1cc0016)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit d19d2506e5a9aad1001a6b8e49c2ddbf9f7204cd)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 021629f579df13eece231b5c8ace30f0a5c150d5)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Pull power management fix from Rafael Wysocki:
"Fix a recently introduced build issue in the cpufreq SCMI driver
(Sudeep Holla)"
* tag 'pm-5.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: scmi: Fix build for !CONFIG_COMMON_CLK
Adds the necessary SuperSpeed Plus support for f_accessory.
[Not upstream as this file is not upstream.]
Bug: 170925797
Signed-off-by: taehyun.cho <taehyun.cho@samsung.com>
Change-Id: Ia2a5f4a6cefac2418f8f29bf1a56355b96d80fc0
(cherry picked from commit 00572be28ec474d7953f1b9dd681cc2dd290d9bf)
[willmcvicker: only cherry-pick f_accessory from original patch]
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 4d7ced0819d3f30acbde46991393249049cefa05)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add CONFIG_PSTORE_PMSG for last logcat support.
Bug: 171852252
Signed-off-by: Jonglin Lee <jonglin@google.com>
Change-Id: I3b130886a2223598700a2da45c70932b11a174d8
(cherry picked from commit 6c412f5b2c4dfce5c607b6535f09281fd27b238d)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Userspace leverages the transient trigger for vibrators.
Signed-off-by: Harpreet Eli Sangha <eliptus@google.com>
Change-Id: Iff727bb955c690f0e195efd476fa9801678d49b8
(cherry picked from commit b01bffe951bf7376a6c661ede682e7c7709f78cd)
Signed-off-by: Will McVicker <willmcvicker@google.com>
0day reported one -22.7% regression for will-it-scale page_fault2
case [1] on a 4 sockets 144 CPU platform, and bisected to it to be
caused by Waiman's optimization (commit bd0b230fe1) of saving one
'struct page_counter' space for 'struct mem_cgroup'.
Initially we thought it was due to the cache alignment change introduced
by the patch, but further debug shows that it is due to some hot data
members ('vmstats_local', 'vmstats_percpu', 'vmstats') sit in 2 adjacent
cacheline (2N and 2N+1 cacheline), and when adjacent cache line prefetch
is enabled, it triggers an "extended level" of cache false sharing for
2 adjacent cache lines.
So exchange the 2 member blocks, while keeping mostly the original
cache alignment, which can restore and even enhance the performance,
and save 64 bytes of space for 'struct mem_cgroup' (from 2880 to 2816,
with 0day's default RHEL-8.3 kernel config)
[1]. https://lore.kernel.org/lkml/20201102091543.GM31092@shao2-debian/
Fixes: bd0b230fe1 ("mm/memcg: unify swap and memsw page counters")
Reported-by: kernel test robot <rong.a.chen@intel.com>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Acked-by: Waiman Long <longman@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Thread ID and CPU ID is useful to distinguish printk
callers from different threads/cpus. Enable config
to prepend the information to printk statements.
Bug: 171425082
Bug: 170888438
Signed-off-by: Jonglin Lee <jonglin@google.com>
Change-Id: Ia5b3396971c689618ae8235b9c75a9f8d07774f2
(cherry picked from commit db79bb68e2955f8d3974823e6a6391934bfd443d)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Pull media fixes from Mauro Carvalho Chehab:
- a rand Kconfig fixup for mtk-vcodec
- a fix at h264 handling at cedrus codec driver
- some warning fixes when config PM is not enabled at marvell-ccic
- two fixes at venus codec driver: one related to codec profile and the
other one related to a bad error path which causes an OOPS on module
re-bind
* tag 'media/v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
media: venus: pm_helpers: Fix kernel module reload
media: venus: venc: Fix setting of profile and level
media: cedrus: h264: Fix check for presence of scaling matrix
media: media/platform/marvell-ccic: fix warnings when CONFIG_PM is not enabled
media: mtk-vcodec: fix build breakage when one of VPU or SCP is enabled
media: mtk-vcodec: move firmware implementations into their own files
The following patches are now queued in f2fs/dev for 5.11, but
android-mainline and android12-5.4 have an old version of them:
libfs: Add generic function for setting dentry_ops
fscrypt: Have filesystems handle their d_ops
f2fs: Handle casefolding with Encryption
Get them up-to-date.
Link: https://lore.kernel.org/linux-f2fs-devel/20201119060904.463807-1-drosen@google.com
Bug: 161184936
Test: kvm-xfstests -c f2fs/default,f2fs/encrypt -g casefold
Change-Id: I359bf4f23631c1b8175de8d5f12d0787fd7f42bd
Signed-off-by: Eric Biggers <ebiggers@google.com>
Pull cifs fixes from Steve French:
"Four smb3 fixes for stable: one fixes a memleak, the other three
address a problem found with decryption offload that can cause a use
after free"
* tag '5.10-rc5-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
smb3: Handle error case during offload read path
smb3: Avoid Mid pending list corruption
smb3: Call cifs reconnect from demultiplex thread
cifs: fix a memleak with modefromsid
Twice now, when exercising ext4 looped on shmem huge pages, I have crashed
on the PF_ONLY_HEAD check inside PageWaiters(): ext4_finish_bio() calling
end_page_writeback() calling wake_up_page() on tail of a shmem huge page,
no longer an ext4 page at all.
The problem is that PageWriteback is not accompanied by a page reference
(as the NOTE at the end of test_clear_page_writeback() acknowledges): as
soon as TestClearPageWriteback has been done, that page could be removed
from page cache, freed, and reused for something else by the time that
wake_up_page() is reached.
https://lore.kernel.org/linux-mm/20200827122019.GC14765@casper.infradead.org/
Matthew Wilcox suggested avoiding or weakening the PageWaiters() tail
check; but I'm paranoid about even looking at an unreferenced struct page,
lest its memory might itself have already been reused or hotremoved (and
wake_up_page_bit() may modify that memory with its ClearPageWaiters()).
Then on crashing a second time, realized there's a stronger reason against
that approach. If my testing just occasionally crashes on that check,
when the page is reused for part of a compound page, wouldn't it be much
more common for the page to get reused as an order-0 page before reaching
wake_up_page()? And on rare occasions, might that reused page already be
marked PageWriteback by its new user, and already be waited upon? What
would that look like?
It would look like BUG_ON(PageWriteback) after wait_on_page_writeback()
in write_cache_pages() (though I have never seen that crash myself).
Matthew Wilcox explaining this to himself:
"page is allocated, added to page cache, dirtied, writeback starts,
--- thread A ---
filesystem calls end_page_writeback()
test_clear_page_writeback()
--- context switch to thread B ---
truncate_inode_pages_range() finds the page, it doesn't have writeback set,
we delete it from the page cache. Page gets reallocated, dirtied, writeback
starts again. Then we call write_cache_pages(), see
PageWriteback() set, call wait_on_page_writeback()
--- context switch back to thread A ---
wake_up_page(page, PG_writeback);
... thread B is woken, but because the wakeup was for the old use of
the page, PageWriteback is still set.
Devious"
And prior to 2a9127fcf2 ("mm: rewrite wait_on_page_bit_common() logic")
this would have been much less likely: before that, wake_page_function()'s
non-exclusive case would stop walking and not wake if it found Writeback
already set again; whereas now the non-exclusive case proceeds to wake.
I have not thought of a fix that does not add a little overhead: the
simplest fix is for end_page_writeback() to get_page() before calling
test_clear_page_writeback(), then put_page() after wake_up_page().
Was there a chance of missed wakeups before, since a page freed before
reaching wake_up_page() would have PageWaiters cleared? I think not,
because each waiter does hold a reference on the page. This bug comes
when the old use of the page, the one we do TestClearPageWriteback on,
had *no* waiters, so no additional page reference beyond the page cache
(and whoever racily freed it). The reuse of the page has a waiter
holding a reference, and its own PageWriteback set; but the belated
wake_up_page() has woken the reuse to hit that BUG_ON(PageWriteback).
Reported-by: syzbot+3622cea378100f45d59f@syzkaller.appspotmail.com
Reported-by: Qian Cai <cai@lca.pw>
Fixes: 2a9127fcf2 ("mm: rewrite wait_on_page_bit_common() logic")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org # v5.8+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull s390 fix from Heiko Carstens:
"Disable interrupts when restoring fpu and vector registers, otherwise
KVM guests might see corrupted register contents"
* tag 's390-5.10-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: fix fpu restore in entry.S
Pull ARC fixes from Vineet Gupta:
"A couple more stack unwinder related fixes:
- More stack unwinding updates
- Misc minor fixes"
* tag 'arc-5.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: stack unwinding: reorganize how initial register state setup
ARC: stack unwinding: don't assume non-current task is sleeping
ARC: mm: fix spelling mistakes
ARC: bitops: Remove unecessary operation and value
Remove leftovers from previous rebase conflict.
This change doesn't affect the kernel functionality as it deletes
what already commented out but not removed by mistake.
Fixes: f37e05049b ("ANDROID: vfs: d_canonical_path for stacked FS")
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: Ic536b8ededb56833c17a5aacdd444d3a162a149d
