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 9fff139aeb11186fd8e75860c959c86cb43ab2f6
https://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 b0d5d2a71641bb50cada708cc8fdca946a837e9a
https://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 7ce1bb83a14019f8c396d57ec704d19478747716)
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: 6c59cb501b86 (scsi: ufs: ufshpb: Make eviction depend on region's reads)
(cherry picked from commit 10163cee1f06fc2e17bcf7bbc2982337202d1d5c
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: 33845a2d844b (scsi: ufs: ufshpb: Limit the number of in-flight map requests)
(cherry picked from commit 22aede9f48b6766fb67441610120db9b04adf109
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: 41d8a9333cc9 (scsi: ufs: ufshpb: Add HPB 2.0 support)
(cherry picked from commit 07106f86ae13d9197bfd38c2d47743304b14099e
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: 13c044e91678 (scsi: ufs: ufshpb: Add "cold" regions timer)
(cherry picked from commit 283e61c5a9bed2c2acde3f50a3f76f09816c0aab
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 2888f960d09f3af00d1e45f1facd311ccd5b778a)
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 fe4b8d3c687efcf27064e472730291edbd81dad6)
SPF patchset introduced an mmu_notifier imbalance by adding a new exit
path that skips mmu_notifier_invalidate_range_only_end after calling
mmu_notifier_invalidate_range_start. This triggers a BUG in KVM driver
checking for mmu_notifier_count to remain balanced
Fixes: afeec97a8d ("FROMLIST: mm: prepare for FAULT_FLAG_SPECULATIVE")
Bug: 161210518
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ibe9d1f0903a23b48c9d733b81249b190e5321c2f
FIPS 140-3 requires this for some reason.
Bug: 188620248
Change-Id: I7c286532097e1d8971faf4d8be31b801f9007e3b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit c14d52059bd86d27ce3c8e581196b011d0cc4d32)
The lab has confirmed that it is actually fine for users to keep using
non-FIPS code after the module has loaded if they were already using it
beforehand. So remove the code that tried to prevent this by updating
live algorithms in-place. Similarly, remove the call to
synchronize_rcu_tasks() which no longer has any purpose.
We still need to move the live algorithms to a private list, so keep
doing that. Keep appending "+orig" to cra_name as well, and start doing
the same for cra_driver_name too.
Bug: 188620248
Change-Id: I29c9faec7d7314484a03f9729924b2f892552c7c
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 54aecb72dba94d1bb68844af6e4790b5823fb6ce)
As per the new guidance from the lab, the module must block crypto
operations until the tests have completed. It's unclear what this means
exactly (given that technically this is impossible), but let's make some
changes that should be enough to comply with the requirement's intent.
First, register the library functions and update the live algorithms
after the tests rather than before the tests. This is a trivial change.
Much more problematic is the fact that the algorithms are registered
with the kernel's crypto framework before the tests run, as the tests
depend on the framework. Unfortunately, the lab believes that the
kernel isn't allowed to enforce the ordering here; the module itself
must. Moreover, trying to solve this by copying the crypto API
framework into the module proved to be heavily problematic.
Thus, implement an alternate solution: make the module override the tfm
initialization function of every algorithm it registers, so that it can
wait for the tests to complete before allowing the use of any algorithm.
This is sufficient if the user makes a supported sequence of API calls.
Bug: 153614920
Bug: 188620248
Change-Id: I11ffba90c08114dda4e91c4be7ce8b608c4e14c1
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 02e48f383b2acb42c85028563cc75453842f11ce)
Instead of having a special case in the core kernel's module loader that
treats a module called 'fips140.ko' in a special way, use a host tool to
tweak the ELF metadata of this module so that the RELA data is preserved
and accessible to the module init code.
This is done in the following way:
- each RELA section that we care about (the ones for .text and .rodata
at the moment) is copied into a new section called .init.rela.<name>
with the SHF_ALLOC attribute, so that the module loader will copy it
into __init memory at load time;
- for each such section, an offset/count tuple is added as a global
variable to the module;
- the count field of those tuples is populated directly by the host tool
based on the actual size of the RELA section in question;
- the offset field is decorated with a place-relative relocation against
the start of the copied RELA section via a weak symbol reference,
which causes an entry to be emitted into the ELF symbol table;
- these ELF symbol table entries are updated by the host tool and turned
into STT_SECTION type symbols with STB_GLOBAL linkage, carrying the
correct section index.
With these changes in place, the unmodified module loader will load all
required information into memory in a way that permits the module init
code to locate the relocations, and apply them in reverse.
Bug: 153614920
Bug: 188620248
Change-Id: I07d9704febdf913834502dd09c19aa4a04d983b1
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 502af6e3490d3ed51cf2131306303445b0d56579)
We currently only emit directives for handling the .text section into
the module linker script if both LTO and CFI are enabled, while for
other sections, we do this even if CFI is not enabled. This is
inconsistent at best, but as it also interferes with the assumption in
the fips140.ko module that the .text._start and .text._end input
sections are placed at the very start and end of the .text section,
which currently can only be relied upon if CFI is enabled.
So rearrange the #ifdef so that it only covers the .text.__cfi_check
input section. Note that aligning to page size is likely to be redundant
in any case, given that the .text section is laid out first, and module
allocations are page aligned to begin with, so making that part
unconditional is unlikely to make an observeable difference in the
output.
Bug: 153614920
Bug: 188620248
Fixes: 6be141eb36 ("ANDROID: crypto: fips140 - perform load time integrity check")
Change-Id: I3f9ed0ae8fa8fe5693c8d2964566cbb42c101aa7
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 6ae8277450ae86113cf7eea8b8348e509e2cc72d)
These flags are supposed to be used when building all source files for
the module.
Bug: 188620248
Fixes: b7397e89db ("ANDROID: fips140: add power-up cryptographic self-tests")
Change-Id: I41cacff040c8a8a0065dd3cfc537303f1ff18335
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 422bc2feb7e3e800a6c75a25795c7786794b7f2d)
Unfortunately, the AES-GCM implementations won't actually be able to be
FIPS-approved. One consequence of this is that the "cmac" template will
need to be tested with all underlying "aes" implementations, as the
equivalent test with "gcm" won't count as fulfilling the requirement to
test all AES implementations in an authenticated mode when supported.
Update the self-tests and comments accordingly.
Bug: 153614920
Bug: 188620248
Change-Id: I874b0718a5ff9d4e2dea2353448266e87f3f0d0b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit a9765fb6dc441dff749b1120ce13180c5561f69e)
Although jitterentropy doesn't necessarily need to be part of
fips140.ko, it does need to have the SP800-90B health tests enabled, and
that requires that it be compiled with the fips_enabled flag set. The
easiest way to do this is just to include a copy of it in fips140.ko.
Bug: 153614920
Bug: 188620248
Change-Id: I9dc0281e07e08e0650e3d340897c697722ad3b1a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit cae242110570eb204b1a332b717aaa35eb16647d)
AES-CMAC is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cmac" template. Add the "cmac" template
to fips140.ko too and add a self-test for AES-CMAC, so that we can
include AES-CMAC in the set of algorithms which will be certified.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms.
Bug: 153614920
Bug: 188620248
Change-Id: I6c1d9281fe848a7101d5ef94ab48e5a41bbcc6f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 038dc9f2cc956cab561bd9d50120920010867b75)
AES-CBC-CTS is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cts" template. Add the "cts" template
to fips140.ko too and add a self-test for AES-CBC-CTS, so that we can
include AES-CBC-CTS in the set of algorithms which will be certified.
There appears to be no support for CBC-CTS mode in pycryptodome or
python-cryptography, so I manually added the test vector.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms. Android uses AES-CBC-CTS for filenames
encryption, which may be relevant (though arguably this use case doesn't
actually require a FIPS approved algorithm).
Bug: 153614920
Bug: 188620248
Change-Id: I53ffbd1d38493592eeaf471bc0007978ec400878
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit e2cfdfbc51b442a9ca96d5fad8060fb02a364eb4)
The lab has confirmed that this test is not required.
Bug: 153614920
Bug: 188620248
Change-Id: Ie55031beacd00f093db3a7ba30fe0844a2ce363b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit ea902862eaeb9b84a94652656b95bf5ac4287a73)
By using the initial_value parameter when creating the pycryptodome
AES-CTR instance, we can use any 16-byte IV, like the other AES modes.
Therefore, there's no need for the last 4 bytes of the IV to be 0.
This doesn't really matter, but it seems nice to avoid this quirk.
Bug: 153614920
Bug: 188620248
Change-Id: If33de260b1119f2b3e004164199b08364781ab23
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fa5a44b364374dd3ed53215b9edf47ffee8a1a82)
Test all implementations of each algorithm rather than just the highest
priority implementation. This aligns with the revised guidance we have
received from the lab.
We can still skip some tests in some cases, as per the FIPS 140-2
Implementation Guidance document. See the comments for details.
To align with the new scope of the tests, the fips140.broken_alg module
parameter now must specify an implementation (e.g. "sha256-ce") rather
than an algorithm (e.g. "sha256").
No change to the DRBG tests is required, as it turns out the module only
includes HMAC_DRBG. However, clarify the comment about the DRBG tests.
On a Pixel device, this increases the running time of the fips140 tests
from 0.5ms to 3.1 ms (very roughly; there's a lot of variation). This
is still very fast, so it isn't expected to be a problem.
Bug: 153614920
Bug: 173104584
Bug: 188620248
Change-Id: I555b535dd45f0164b7744a2c9338c501bb88de86
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit abe07806964be48e8d0005e26f33632ace5e4152)
dpcm_end_walk_at_be() stops the graph walk when first BE is found for
the given FE component. In a component model we may want to connect
multiple DAIs from different components.
android_vh_snd_soc_card_get_comp_chain can be registered here
to allows DAI/component chaining.
Later PCM operations can be called for all these listed components for a
valid DAPM path.
ALSA machine driver can setup component_chaining like below code slice.
static void my_board_component_chaining_hook(void *data, bool *ret)
{
*ret = true;
}
static int my_board_dev_probe(struct platform_device *pdev)
{
register_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static int my_board_dev_remove(struct platform_device *pdev)
{
unregister_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static struct platform_driver my_board_driver = {
...
.probe = my_board_dev_probe,
.remove = my_board_dev_remove,
...
};
Bug: 198732156
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.com>
Change-Id: Ife5df291d40af9ec83d57462b6a08aba95d9119d
The ABI diff is essentially bogus, but included here for completeness.
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct xhci_hcd at xhci.h:1756:1' changed:
type size hasn't changed
1 data member deletion:
'union {xhci_vendor_ops* vendor_ops; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide322; union {};}', at offset 59392 (in bits) at xhci.h:1935:1
18 impacted interfaces
Bug: 210255585
Change-Id: Ic646e0edd2ab19fcd9b7b88b6e6a604299fc4824
Signed-off-by: Giuliano Procida <gprocida@google.com>
The __UNIQUE_ID() macro causes problems as it turns out to not be
deterministic across different compiler runs as it relies on the
__COUNTER__ macro which could have been used on other .h files previous
to this .h file being included.
This shows up specifically when building with "LTO=thin" vs. "LTO=full"
as different build paths seem to be triggered.
As the structure name isn't really needed at all here, we were just
including it for older compilers that could not handle anonymous
structures in a union, just drop the whole thing which resolves the abi
naming issue.
Bug: 210255585
Reported-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6b9449fa9d26ffc5d66b2f0f3b41e2d5f3003f68
Commit f1a0a376ca0c ("sched/core: Initialize the idle task with
preemption disabled") removed the init_idle() call from
idle_thread_get(). This was the sole call-path on hotplug that resets
the Shadow Call Stack (scs) Stack Pointer (sp).
Not resetting the scs-sp leads to scs overflow after enough hotplug
cycles. Therefore add an explicit scs_task_reset() to the hotplug code
to make sure the scs-sp does get reset on hotplug.
Fixes: f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled")
Signed-off-by: Woody Lin <woodylin@google.com>
[peterz: Changelog]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lore.kernel.org/r/20211012083521.973587-1-woodylin@google.com
(cherry picked from commit 63acd42c0d4942f74710b11c38602fb14dea7320)
Bug: 201047587
Bug: 201771367
Change-Id: I9e48270f8d4c698c140cc3f427cadae636acb6d7
Add define of cpuset_update_active_cpus_affine() for fix compile error
when not define CONFIG_CPUSETS.
Bug: 204347727
Fixes: 09bd9e940e ("ANDROID: cpuhp/pause: schedule cpu_hotplug_work on
resume cpu")
Change-Id: Icf79df5e22233d15e4e8257a5f54176efbcd975b
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
Enable the UVC function driver to allow USB gadgets
to connect as a standard video device to a host.
Bug: 200712777
Signed-off-by: Dan Vacura <w36195@motorola.com>
Change-Id: Ia037f8560664f9e98f28f3fede609764d5d5699d
The missing leading whitespace in android/abi_gki_aarch64_galaxy
caused its symbols to be dropped from the distribution
abi_symbollist file and the distribution vmlinux binary.
Bug: 203852249
Change-Id: I7854401e0a55ad89beacde588c24f1d1698e9e17
Signed-off-by: Giuliano Procida <gprocida@google.com>
This reverts commit 1aa1f6a7cf.
The hook android_vh_mpam_set is not used by any vendor, so remove
it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 165333282
Cc: C-J.Chen <C-J.Chen@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I18356743538df7d41a00f54479bf2a0bc3a62e06
On the android12-5.10 branch, commit 4a5cf92412 ("BACKPORT: FROMGIT:
userfaultfd: add UFFDIO_CONTINUE ioctl") added a new call site for the
function validate_range(). Meanwhile, on the 5.10 stable branch, commit
0b591c020d ("userfaultfd: do not untag user pointers") changed the
function signature of validate_range() and updated all call sites
accordingly. However, since these two commits happened on different
branches, the new call site in userfaultfd_continue() has not been
updated accordingly. This has arguably been missed in the merge commit
66379c1ee5 ("Merge tag 'android12-5.10.66_r00' into
android12-5.10").
This patch fixes the following build breakage
./common/fs/userfaultfd.c:1875:32: error: incompatible pointer to integer conversion passing '__u64 *' (aka 'unsigned long long *') to parameter of type '__u64' (aka 'unsigned long long'); remove & [-Werror,-Wint-conversion]
ret = validate_range(ctx->mm, &uffdio_continue.range.start,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./common/fs/userfaultfd.c:1245:14: note: passing argument to parameter 'start' here
__u64 start, __u64 len)
^
1 error generated.
Fixes: 66379c1ee5 ("Merge tag 'android12-5.10.66_r00' into android12-5.10")
Signed-off-by: Aaron Ding <aaronding@google.com>
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Change-Id: I7ad40df213897314c439480f22a2ef4712e84025
(cherry picked from commit 5ec931a85350cd1914f53949d32214583421e155)
Resume cpu need to run cpuset_hotplug_workfn which need take
about several milliseconds, and even more if the system have
more tasks.
This isn't suitable to run in the main task context of resume
cpu.
Due to the cpu which is resuming only have active mask,
but still not rebuild sched domain, make this slow
work run on resuming cpu can not take extra overload to
previous active cpus.
Bug: 203839955
Fixes: 1d3a64fbd2 ("ANDROID: cpu/hotplug: rebuild sched
domains immediately")
Change-Id: Ia7bdd077f982950c02696c3598a41b2482046220
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
