This patch will export some tracepoints so that vendor modules can use them.
Export these tracepoint functions to track IO data flow for performance tuning.
Bug: 205648026
Change-Id: Ia37b8f99b2d940cecce46c8bc24f724c14450517
Signed-off-by: Yang Yang <yang.yang@vivo.com>
GKI required the KMI_GENERATION to be added to the kernel version
string, but this only makes sense for GKI kernels, for non-GKI kernels
we don't need it. Leave all the other stuff we added, though, as it
seems useful.
Bug: 205897686
Change-Id: I2e7b3cb7ed5529f1e5e7c9d79a1f7ce4a1b6ee1f
Signed-off-by: Alistair Delva <adelva@google.com>
We want to get binder free space information in the binder
transaction, but this needs to hold the mutex lock. So we add
this restrict hook to do this.
Bug: 205648032
Change-Id: Ie1f377018da686bd62f5ac2d1e5421899741e6d5
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
Need to add additional symbol in execution path to ABI list.
Bug: 176077958
Change-Id: I676b4f9a016c825572d10de49b6062a90078f2f2
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
This reverts commit 20285dc271, which
causes serious performance downgrade because the calculated cpu
frequency will be much lower than before due to change of cpu util.
Bug: 205915994
Test: build pass
Change-Id: I68dced7a58547a3324fcfeebea6c02bb30c4182d
Signed-off-by: Rick Yiu <rickyiu@google.com>
sem->count will be negative after writer is killed
if flag RWSEM_FLAG_HANDOFF is not set, we shouldn't clean again
CPU2 CPU4
task A[reader] task B[writer]
down_read_killable[locked]
sem->count=0x100
down_write_killable
sem->count=0x102[wlist not empty]
up_read
count=0x2
sig kill received
down_read_killable
sem->count=0x102[wlist not empty]
goto branch out_nolock:
list_del(&waiter.list);
wait list is empty
sem->count-RWSEM_FLAG_HANDOFF
sem->count=0xFE
list_empty(&sem->wait_list) is TRUE
sem->count andnot RWSEM_FLAG_WAITERS
sem->count=0xFC
up_read
sem->count-=0x100
sem->count=0xFFFFFFFFFFFFFFFC
DEBUG_RWSEMS_WARN_ON(tmp < 0, sem);
Bug: 204595609
Link: https://lore.kernel.org/all/a630a9aa-8c66-31c9-21a0-3d30bde2c9df@redhat.com/T/
Signed-off-by: mazhenhua <mazhenhua@xiaomi.com>
Change-Id: Ife64c179335d74768a3d68e402c72d10148f3e7e
A recent change to use proc->cred instead of proc->tsk as the source
for sender_euid caused a failure in the CredentialsTest#CaptureLayersTest
test. Revert 1 line of the patch to fix the test. The rest of the patch
needs to remain since the subsequent patches rely on it.
Before fixing upstream, we need to investigate more since the code looks
correct so the issue may be a latent userspace bug.
Bug: 205938623
Fixes: d65efd5b73 ("UPSTREAM: binder: use euid from cred instead of using task")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I16543a50f43f79131234995fb0813de00795bd3d
Use the standard auto-generated kernel version string instead of a
manually assigned version number that will get out-of-date. There was
discussion of custom version numbers being needed for certification
purposes, but it appears that they won't be needed after all.
This will produce a version string like
"5.10.66-android12-9-00017-g0b8a0a4df237".
Bug: 188620248
Change-Id: Ia369e91e4a18f489418123c672686e05ca99063d
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 4e0c104075)
Use the 'struct cred' saved at binder_open() to lookup
the security ID via security_cred_getsecid(). This
ensures that the security context that opened binder
is the one used to generate the secctx.
Cc: stable@vger.kernel.org # 5.4+
Fixes: ec74136ded ("binder: create node flag to request sender's security context")
Signed-off-by: Todd Kjos <tkjos@google.com>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Bug: 200688826
(cherry picked from commit 4d5b553974)
[ refactored to avoid changing KMI: struct binder_proc ]
Change-Id: Ie023be3190caf20ca3901560455e9f027c9426cd
Since binder was integrated with selinux, it has passed
'struct task_struct' associated with the binder_proc
to represent the source and target of transactions.
The conversion of task to SID was then done in the hook
implementations. It turns out that there are race conditions
which can result in an incorrect security context being used.
Fix by using the 'struct cred' saved during binder_open and pass
it to the selinux subsystem.
Cc: stable@vger.kernel.org # 5.14 (need backport for earlier stables)
Fixes: 79af73079d ("Add security hooks to binder and implement the hooks for SELinux.")
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Bug: 200688826
(cherry picked from commit 52f8869337)
[ refactored to avoid changing KMI: struct binder_proc ]
Change-Id: I1664c1f0c2142c17e9ca0d6790bb94de79f531e3
Save the 'struct cred' associated with a binder process
at initial open to avoid potential race conditions
when converting to an euid.
Set a transaction's sender_euid from the 'struct cred'
saved at binder_open() instead of looking up the euid
from the binder proc's 'struct task'. This ensures
the euid is associated with the security context that
of the task that opened binder.
Cc: stable@vger.kernel.org # 4.4+
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Signed-off-by: Todd Kjos <tkjos@google.com>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Suggested-by: Jann Horn <jannh@google.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Bug: 200688826
(cherry picked from commit 29bc22ac5e)
[ refactored to avoid changing KMI: struct binder_proc ]
Change-Id: Icaf996a7f5543b7d6943dff3cbe89bfc3614044c
These hooks will do the following works:
a) Record the number of times when target_freq being clamped
b) Record the number of times when target_freq is greater than policy->cur
c) Make corresponding optimization strategies in different hooks
Bug: 205906618
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: I8eba66fd0c6d36393ca39045cf228b659834e0ae
Signed-off-by: xieliujie <xieliujie@oppo.com>
Export get_wchan to get the block reason
Bug: 205684022
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I7b65bb502b805e7dac13e5f9d725da1ff70fe306
These hooks will do the following works:
a) record the time of the process in various states
b) Make corresponding optimization strategies in different hooks
Bug: 205938967
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: Ia3c47bbf0aadd17337ce18fd910343b1b8c3ef93
cpufreq_times_record_transition() is not called when fast switch is
enabled, leading /proc/[pid]/time_in_state to attribute all time on a
cluster to a single frequency. To fix this, add a call to
cpufreq_times_record_transition() in the fast switch path.
Test: /proc/[pid]/time_in_state shows times for more than one freq per
cluster
Bug: 204726690
Signed-off-by: zhengding chen <chenzhengding@oppo.com>
Change-Id: Ief47ffb49fcc7fbf5408eea3056930e8791d2820
Add hooks to gather data of unusual aborts and summarize it with
other information.
Bug: 203187389
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: I37b3047e72f64dc210d3d3bffe5ee207daeba8d6
During the suspend is in process, thermal_zone_device_update bails out
thermal zone re-evaluation for any sensor trip violation without
setting next valid trip to that sensor. It assumes during resume
it will re-evaluate same thermal zone and update trip. But when it is
in suspend temperature goes down and on resume path while updating
thermal zone if temperature is less than previously violated trip,
thermal zone set trip function evaluates the same previous high and
previous low trip as new high and low trip. Since there is no change
in high/low trip, it bails out from thermal zone set trip API without
setting any trip. It leads to a case where sensor high trip or low
trip is disabled forever even though thermal zone has a valid high
or low trip.
During thermal zone device init, reset thermal zone previous high
and low trip. It resolves above mentioned scenario.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org>
Bug: 205496325
Link: https://lore.kernel.org/linux-pm/51de966a-9c9e-88a8-5c2c-96773a64d527@linaro.org/T/#u
Change-Id: Ib57ac6164811a566b497964701f23a3c209915e3
Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
A potential use after free can occur in _vm_unmap_aliases where an already
freed vmap_area could be accessed, Consider the following scenario:
Process 1 Process 2
__vm_unmap_aliases __vm_unmap_aliases
purge_fragmented_blocks_allcpus rcu_read_lock()
rcu_read_lock()
list_del_rcu(&vb->free_list)
list_for_each_entry_rcu(vb .. )
__purge_vmap_area_lazy
kmem_cache_free(va)
va_start = vb->va->va_start
Here Process 1 is in purge path and it does list_del_rcu on vmap_block and
later frees the vmap_area, since Process 2 was holding the rcu lock at
this time vmap_block will still be present in and Process 2 accesse it and
thereby it tries to access vmap_area of that vmap_block which was already
freed by Process 1 and this results in use after free.
Fix this by adding a check for vb->dirty before accessing vmap_area
structure since vb->dirty will be set to VMAP_BBMAP_BITS in purge path
checking for this will prevent the use after free.
Link: https://lkml.kernel.org/r/1616062105-23263-1-git-send-email-vjitta@codeaurora.org
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 205658047
(cherry picked from commit ad216c0316https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
Change-Id: I450781b5734570d1b9e8c63ac29ad3635c8e49bb
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
The following deadlock has been observed on a test setup:
* All tags allocated.
* The SCSI error handler calls ufshcd_eh_host_reset_handler()
* ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler()
* ufshcd_err_handler() locks up as follows:
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt
Call trace:
__switch_to+0x298/0x5d8
__schedule+0x6cc/0xa94
schedule+0x12c/0x298
blk_mq_get_tag+0x210/0x480
__blk_mq_alloc_request+0x1c8/0x284
blk_get_request+0x74/0x134
ufshcd_exec_dev_cmd+0x68/0x640
ufshcd_verify_dev_init+0x68/0x35c
ufshcd_probe_hba+0x12c/0x1cb8
ufshcd_host_reset_and_restore+0x88/0x254
ufshcd_reset_and_restore+0xd0/0x354
ufshcd_err_handler+0x408/0xc58
process_one_work+0x24c/0x66c
worker_thread+0x3e8/0xa4c
kthread+0x150/0x1b4
ret_from_fork+0x10/0x30
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved
request.
This patch is closely related to the upstream patch with the same title.
Bug: 205080886
Link: https://lore.kernel.org/linux-scsi/700f0463-23a9-8465-f712-1188cb884dea@acm.org/T/#u
Change-Id: I9e9ba3f45ba23ecf576380aa19701d3437af6cdd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Before reducing 'can_queue' from 32 to 31, make
ufshcd_change_queue_depth() restrict the queue depth to 'can_queue'
instead of hba->nutrs (32). This is a backport of a subset of the
following patch: "[PATCH 2/2] scsi: ufs: Fix a deadlock in the error
handler".
Bug: 205080886
Link: https://lore.kernel.org/linux-scsi/20211103000529.1549411-3-bvanassche@acm.org/
Change-Id: I6e694a9698f91293fc2987217e3f939726c397dd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Commit 4c22227e39 ("cfg80211: fix management registrations locking")
in 5.10.77, which is commit 09b1d5dc6c ("cfg80211: fix management
registrations locking") upstream, moved the mgmt_registrations_lock out
of struct wireless_dev. This did not change the structure size, but
caused a CRC change in the structure pointer, which tripped the abi
checker.
So restore the variable, and comment that this is not used anymore. No
driver should ever be touching this so it is safe.
Note, using a __GENKSYMS__ hack would work, as the overall structure
size remains the same when this variable is removed, BUT the warning
that the field is gone is reported by libabigail correctly, which would
require a .xml update, so it's not worth it.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibcfe743833860e6f75611d7ebed1036a77be0a69
The management registrations locking was broken, the list was
locked for each wdev, but cfg80211_mgmt_registrations_update()
iterated it without holding all the correct spinlocks, causing
list corruption.
Rather than trying to fix it with fine-grained locking, just
move the lock to the wiphy/rdev (still need the list on each
wdev), we already need to hold the wdev lock to change it, so
there's no contention on the lock in any case. This trivially
fixes the bug since we hold one wdev's lock already, and now
will hold the lock that protects all lists.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Fixes: 6cd536fe62 ("cfg80211: change internal management frame registration API")
Link: https://lore.kernel.org/r/20211025133111.5cf733eab0f4.I7b0abb0494ab712f74e2efcd24bb31ac33f7eee9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 204384349
(cherry picked from commit 09b1d5dc6c)
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id1bca68277be3a5f7c7329a8195018946f686bdb
When receiving a disconnect event from the UDC, the mass storage
function driver currently runs the handle_exception() routine
asynchronously. For UDCs that support runtime PM, there is a
possibility the UDC is already suspended by the time the
do_set_interface() is executed. This can lead to HW register access
while the UDC is already suspended.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Bug: 204343836
(cherry picked from commit 9fff139aebhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
Change-Id: I6c8011baddf02d6b0eadb5934416bc24b8a93f4a
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
The usb_ep_disable() and usb_ep_enable() routines are being widely
used in atomic/interrupt context by function drivers. Hence, the
statement about it being able to only run in process context may
not be true. Add an explicit comment mentioning that it can be used
in atomic context.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Bug: 204343836
(cherry picked from commit b0d5d2a716https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
Change-Id: I1adb5d074fe2f9e33ebfdb30d335283c56bc7b39
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
If CONFIG_CFI_CLANG=y, attempting to read an event histogram will cause
the kernel to panic due to failed CFI check.
1. echo 'hist:keys=common_pid' >> events/sched/sched_switch/trigger
2. cat events/sched/sched_switch/hist
3. kernel panics on attempting to read hist
This happens because the sort() function expects a generic
int (*)(const void *, const void *) pointer for the compare function.
To prevent this CFI failure, change tracing map cmp_entries_* function
signatures to match this.
Also, fix the build error reported by the kernel test robot [1].
[1] https://lore.kernel.org/r/202110141140.zzi4dRh4-lkp@intel.com/
Link: https://lkml.kernel.org/r/20211014045217.3265162-1-kaleshsingh@google.com
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Bug: 204946901
(cherry picked from commit 7ce1bb83a1)
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Change-Id: I4a1a39b086b5e306ddecabd9a6076e2fb14c3f70
In host control mode, eviction is precieved as an extreme measure.
There are several conditions that both the entering and exiting regions
should meet, so that eviction will take place.
The common case however, is that those conditions are rarely met, so it
is normal that the act of eviction fails. Therefore, Do not report an
error in host control mode if eviction fails.
Link: https://lore.kernel.org/r/20210808090024.21721-5-avri.altman@wdc.com
Fixes: 6c59cb501b (scsi: ufs: ufshpb: Make eviction depend on region's reads)
(cherry picked from commit 10163cee1f
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: Id6aa444ea5e2efd15c507bbd586c421018c75998
num_inflight_map_req should not be negative. It is incremented and
decremented without any protection, allowing it theoretically to be
negative, should some weird unbalanced count occur.
Verify that the those calls are properly serielized.
Link: https://lore.kernel.org/r/20210808090024.21721-4-avri.altman@wdc.com
Fixes: 33845a2d84 (scsi: ufs: ufshpb: Limit the number of in-flight map requests)
(cherry picked from commit 22aede9f48
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I8a8252c919e6678752b60bcd950cb08e765e6aed
In HPB2.0, if pre_req_min_tr_len < transfer_len < pre_req_max_tr_len
the driver is expected to send a HPB-WRITE-BUFFER companion to HPB-READ.
The upper bound should fit into a single byte, regardless of
bMAX_ DATA_SIZE_FOR_HPB_SINGLE_CMD which being an attribute (u32) can
be significantly larger.
To further illustrate the issue let us consider the following scenario:
- SCSI_DEFAULT_MAX_SECTORS is 1024 limiting the IO chunks to 512KB
- The OEM changes scsi_host_template .max_sectors to be 2048, which
allows a 1M requests: transfer_len = 256
- pre_req_max_tr_len = HPB_MULTI_CHUNK_HIGH = 256
- ufshpb_is_supported_chunk returns true (256 <= 256)
- WARN_ON_ONCE(transfer_len > HPB_MULTI_CHUNK_HIGH) doesn't warn
- ufshpb_set_hpb_read_to_upiu cast transfer_len to u8: transfer_len = 0
- the command is failing with illegal request
Link: https://lore.kernel.org/r/20210808090024.21721-3-avri.altman@wdc.com
Fixes: 41d8a9333c (scsi: ufs: ufshpb: Add HPB 2.0 support)
(cherry picked from commit 07106f86ae
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I0dc568020a0fe6c4ddf6952f89ad5230770fd7f3
The "cold"-timer purpose is not to hang-on to active regions with no
reads. Therefore the read-timeout should be re-wind on every read, and
not just when the region is activated.
Link: https://lore.kernel.org/r/20210808090024.21721-2-avri.altman@wdc.com
Fixes: 13c044e916 (scsi: ufs: ufshpb: Add "cold" regions timer)
(cherry picked from commit 283e61c5a9
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: If174a161028cf2382538d69e30181cda979a12de
Add vendor hooks to monitor more update load-avg point
where tasks on the run-queue will go through.
Bug: 204857484
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
Change-Id: I440d7b9686a37508bd7568454472ab014ba0d0c9
This is needed to meet a FIPS 140-3 requirement that modules provide a
service that retrieves their name and versioning information.
Bug: 188620248
Change-Id: I36049c839c4217e3616daab52ec536b46479c12a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 2888f960d0)
To satisfy the FIPS 140-3 "service indicators" requirement, add a
function which checks whether the given algorithm is "approved" or not.
Note that this function is a bit different from the module's other APIs
in that it is an exported symbol rather than a registration-based API.
This avoids needing to make kernel/KMI changes, so I think we should do
it this way if possible, given that it's unlikely this function will be
used in practice outside of the lab test. Built-in code can still call
this function via symbol_get() if it really wants to.
Bug: 188620248
Change-Id: I26c976258fa9446b34eb189bba7154142d85da16
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fe4b8d3c68)
