Reported when cross compiled for Android
Bug: 174512003
Test: incfs_test passes, cross compiles for Android
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I043657192415e01293fe983e059a13fa12ae1f60
Roll report_uid feature flag into v2 feature flag
Bug: 174478527
Test: Feature flag present on boot
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I41ee9715904560004e25cc83a5ccc1eb1bdd2b1f
Add a restricted vendor hook when a set of tasks change the cgroups in
the cpu controller. This facilitates various scheduler value adds.
Bug: 175045928
Change-Id: I544046d631f4d6c9bc2b999e054b5a296ec31a81
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
This scheduler interface has been brought to allow the hotplug feature
paused_cpus to force tasks migration. It depends on migrate_tasks() which
is only available when CONFIG_HOTPLUG_CPU is set. sched_cpu_drain*()
functions should then also depend on this configuration.
Bug: 161210528
Fixes: e19b8ce (ANDROID: cpu/hotplug: add migration to paused_cpus)
Change-Id: I250cd0a8f382811604445600acc33ab4df4ad4da
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
As of commit 42d1d3ffd7 ("ANDROID: GKI: enable CONFIG_USB_DWC3
to be build in"), we no longer need CONFIG_USB_DWC3=m in the
db845c_gki.frament, as having it there, causing the module load
to fail (as its duplicative) and the boot to (unfortunately
silently) fail.
Fixes: 42d1d3ffd7 ("ANDROID: GKI: enable CONFIG_USB_DWC3 to be build in")
Change-Id: I089b91364868ef56ac3da158f62c0c5f5345a1a4
Signed-off-by: John Stultz <john.stultz@linaro.org>
This reverts commit cc47b201a8.
Bug: 173425293
Reason for revert: Android platform has adapted devices with and
without a dedicated recovery partition, so the ramdisk no longer
needs to be writable.
Change-Id: Ib743e94197eadccbe877811e3a78aaa969960ea8
Signed-off-by: Yifan Hong <elsk@google.com>
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.eide@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.
Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.
Before v5.0 (commit 55897af630 ("dma-direct: merge swiotlb_dma_ops
into the dma_direct code")) this was a problem as the dma-api (at least
the swiotlb_dma_ops on arm64) would use the potentially invalid
dma_address. How that failed depended on how the device handled physical
address 0. If 0 was a valid address to physical ram, that page would get
flushed a lot, while the actual pages in the buffer would not get synced
correctly. While if 0 is an invalid physical address it may cause a
fault and trigger a crash.
In v5.0 this was incidentally fixed by commit 55897af630 ("dma-direct:
merge swiotlb_dma_ops into the dma_direct code"), as this moved the
dma-api to use the page pointer in the sg_list, and (for Ion buffers at
least) this will always be valid if the sg_list exists at all.
But, this issue is re-introduced in v5.3 with
commit 449fa54d68 ("dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
behaviour and picks the dma_address that may be invalid.
dma-buf core doesn't ensure that the buffer is mapped on the device, and
thus have a valid sg_list, before calling the exporter's
begin_cpu_access.
Logic and commit message originally by: Ørjan Eide <orjan.eide@arm.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Liam Mark <lmark@codeaurora.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Daniel Mentz <danielmentz@google.com>
Cc: Chris Goldsworthy <cgoldswo@codeaurora.org>
Cc: Ørjan Eide <orjan.eide@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: James Jones <jajones@nvidia.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Bug: 173440990
(cherry picked from commit 4c68e499bb
git: //anongit.freedesktop.org/drm/drm-misc
tags/drm-misc-next-2020-11-27)
Link: https://lore.kernel.org/patchwork/patch/1343071/
Change-Id: If1c7312e437a8166a7d3e65bcd4c352f46cab718
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Pull ARM SoC fixes from Arnd Bergmann:
"There are a few more PHY mode changes for allwinner SoC based boards
with a Realtek PHY after the driver changed its behavior, I assume
there will be more of these in the future. Also on for Allwinner, the
Banana Pi M2 board had a regression that led to some devices not
working because of a slightly incorrect voltage being applied.
By popular demand, I picked up a change from Krzysztof Kozlowski to
actually list the SoC tree in the MAINTAINERS file. We don't want to
get Cc'd on normal patches that are picked up by platform maintainers,
but the lack of an entry has led to confusion in the past.
All the other changes are fairly benign, fixing boot-time or
compile-time warning messages in various places:
- A dtc warning on the OLPC XO-1.75
- A boot-time warning on i.MX6 wandboard
- A harmless compile-time warning
- A regression causing one of the i.MX6 SoCs to be identified as
another
- Missing SoC identification of Allwinner V3 and S3"
* tag 'arm-soc-fixes-v5.10-4b' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
firmware: xilinx: Mark pm_api_features_map with static keyword
ARM: dts: mmp2-olpc-xo-1-75: clear the warnings when make dtbs
MAINTAINERS: add a limited ARM and ARM64 SoC entry
MAINTAINERS: correct SoC Git address (formerly: arm-soc)
ARM: keystone: remove SECTION_SIZE_BITS/MAX_PHYSMEM_BITS
arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode rgmii-id
arm64: dts: allwinner: A64 Sopine: phy-mode rgmii-id
ARM: dts: imx6qdl-kontron-samx6i: fix I2C_PM scl pin
ARM: dts: imx6qdl-wandboard-revd1: Remove PAD_GPIO_6 from enetgrp
ARM: imx: Use correct SRC base address
ARM: dts: sun7i: pcduino3-nano: enable RGMII RX/TX delay on PHY
ARM: dts: sun8i: v3s: fix GIC node memory range
ARM: dts: sun8i: v40: bananapi-m2-berry: Fix ethernet node
ARM: dts: sun8i: r40: bananapi-m2-berry: Fix dcdc1 regulator
ARM: dts: sun7i: bananapi: Enable RGMII RX/TX delay on Ethernet PHY
ARM: dts: s3: pinecube: align compatible property to other S3 boards
ARM: sunxi: Add machine match for the Allwinner V3 SoC
arm64: dts: allwinner: h6: orangepi-one-plus: Fix ethernet
The check_spi_bus_bridge() in scripts/dtc/checks.c requires that the node
have "spi-slave" property must with "#address-cells = <0>" and
"#size-cells = <0>". But currently both "#address-cells" and "#size-cells"
properties are deleted, the corresponding default values are 2 and 1. As a
result, the check fails and below warnings is displayed.
arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): \
/soc/apb@d4000000/spi@d4037000: incorrect #address-cells for SPI bus
also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3
arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): \
/soc/apb@d4000000/spi@d4037000: incorrect #size-cells for SPI bus
also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dtb: Warning (spi_bus_reg): \
Failed prerequisite 'spi_bus_bridge'
Because the value of "#size-cells" is already defined as zero in the node
"ssp3: spi@d4037000" in arch/arm/boot/dts/mmp2.dtsi. So we only need to
explicitly add "#address-cells = <0>" and keep "#size-cells" no change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20201207084752.1665-2-thunder.leizhen@huawei.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull iommu fix from Will Deacon:
"Fix interrupt table length definition for AMD IOMMU.
It's actually a fix for a fix, where the size of the interrupt
remapping table was increased but a related constant for the
size of the interrupt table was forgotten"
* tag 'iommu-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
In current task abort routine, if task abort happens to the device W-LUN,
the code directly jumps to ufshcd_eh_host_reset_handler() to perform a full
reset and restore then returns FAIL or SUCCESS. Commands sent to the device
W-LUN are most likely the SSU cmds sent during UFS PM operations. If such
SSU cmd enters task abort routine when ufshcd_eh_host_reset_handler()
flushes eh_work, it will get stuck there since err_handler is serialized
with PM operations.
In order to unblock above call path, we merely clean up the lrb taken by
this cmd, queue the eh_work and return SUCCESS. Once the cmd is aborted,
the PM operation which sends out the cmd just errors out, then err_handler
shall be able to proceed with the full reset and restore.
In this scenario, the cmd is aborted even before it is actually cleared by
HW, set the lrb->in_use flag to prevent subsequent cmds, including SCSI
cmds and dev cmds, from taking the lrb released from abort. The flag shall
evetually be cleared in __ufshcd_transfer_req_compl() invoked by the full
reset and restore from err_handler.
[mkp: conflict with event logging series]
Link: https://lore.kernel.org/r/1606910644-21185-3-git-send-email-cang@codeaurora.org
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 174590161
Change-Id: I6db273481cd06f5ce0a64dcaa94c9c3d014d8421
(cherry picked from commit 7a7e66c65d
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.11/scsi-staging)
Signed-off-by: Can Guo <cang@codeaurora.org>
Everyone relies on the DWC3 USB host/gadget controller, so build the
core into the kernel to be shared by all.
If platform specific changes are needed, enable the platform-specific
dwc3 driver.
Bug: 157965270
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3fc2c4d05f46eebf30c2e222cb85928d9f6a83c5
This change adds vbus_vsafe0v which when set, makes TCPM
query for VSAFE0V by assigning the tcpc.is_vbus_vsafe0v callback.
Also enables ALERT.ExtendedStatus which is triggered when
status of EXTENDED_STATUS.vSafe0V changes.
EXTENDED_STATUS.vSafe0V is set when vbus is at vSafe0V and
cleared otherwise.
Bug: 173747861
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202040840.663578-2-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 766c485b86 usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I970d0be609b80cb2ae934d09cbbf6cc480e67294
TCPM at present lacks the notion of VSAFE0V. There
are three vbus threshold levels that are critical to track:
a. vSafe5V - VBUS “5 volts” as defined by the USB
PD specification.
b. vSinkDisconnect - Threshold used for transition from
Attached.SNK to Unattached.SNK.
c. vSafe0V - VBUS “0 volts” as defined by the USB
PD specification.
Tracking vSafe0V is crucial for entry into Try.SNK and
Attached.SRC and turning vbus back on by the source in
response to hard reset.
From "4.5.2.2.8.2 Exiting from AttachWait.SRC State" section
in the Type-C spec:
"The port shall transition to Attached.SRC when VBUS is at
vSafe0V and the SRC.Rd state is detected on exactly one of
the CC1 or CC2 pins for at least tCCDebounce."
"A DRP that strongly prefers the Sink role may optionally
transition to Try.SNK instead of Attached.SRC when VBUS
is at vSafe0V and the SRC.Rd state is detected on exactly
one of the CC1 or CC2 pins for at least tCCDebounce."
From "7.1.5 Response to Hard Resets" section in the PD spec:
"After establishing the vSafe0V voltage condition on VBUS,
the Source Shall wait tSrcRecover before re-applying VCONN
and restoring VBUS to vSafe5V."
vbus_present in the TCPM code tracks vSafe5V(vbus_present is true)
and vSinkDisconnect(vbus_present is false).
This change adds is_vbus_vsafe0v callback which when set makes
TCPM query for vSafe0V voltage level when needed.
Since not all TCPC controllers might have the capability
to report vSafe0V, TCPM assumes that vSafe0V is same as
vSinkDisconnect when is_vbus_vsafe0v callback is not set.
This allows TCPM to continue to support controllers which don't
have the support for reporting vSafe0V.
Introducing vSafe0V helps fix the failure reported at
"Step 15. CVS verifies PUT remains in AttachWait.SRC for 500ms"
of "TD 4.7.2 Try. SNK DRP Connect DRP Test" of
"Universal Serial Bus Type-C (USB Type-C) Functional Test
Specification Chapters 4 and 5". Here the compliance tester
intentionally maintains vbus at greater than vSafe0V and expects
the Product under test to stay in AttachWait.SRC till vbus drops
to vSafe0V.
Bug: 173747861
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202040840.663578-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 28b43d3d74 usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2386cd38d8355dc700f00919bbe7f1132f5041d6
tcpm_check_send_discover does not clear the send_discover flag
when any of the following conditions are not met.
1. data_role is TYPEC_HOST
2. link is pd_capable
Discovery indentity would anyways not be attempted during
the current session anymore when the above conditions are not
met. Hence clear the send_discover flag here to prevent
tcpm_enable_frs_work from rescheduling indefinetly.
Bug: 174693433
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201203031908.1491542-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3bac42f02d upstream)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I69d3137d373e303396cf37d885a9bb797331d13d
nRetryCount was updated from 3 to 2 between PD2.0 and PD3.0 spec.
nRetryCount in "Table 6-34 Counter parameters" of the PD 2.0
spec is set to 3, whereas, nRetryCount in "Table 6-59 Counter
parameters" is set to 2.
Pass down negotiated rev in pd_transmit so that low level chip
drivers can update the retry count accordingly before attempting
packet transmission.
This helps in passing "TEST.PD.PORT.ALL.02" of the
"Power Delivery Merged" test suite which was initially failing
with "The UUT did not retransmit the message nReryCount times"
In fusb302 & tcpci drivers, by default the driver sets the retry
count to 3 (Default for PD 2.0). Update this to 2,
if the negotiated rev is PD 3.0.
In wcove, since the retry count is intentionally set to max, leaving
it as is.
Bug: 156443424
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202031733.647808-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e4a9378083 usb-next)
Change-Id: I078d31c4e2d64e2e17ed8c50b78d90542462cd75
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Jann spotted the security hole due to race of mm ownership check.
If the task is sharing the mm_struct but goes through execve() before
mm_access(), it could skip process_madvise_behavior_valid check. That
makes *any advice hint* to reach into the remote process.
This patch removes the mm ownership check. With it, it will lose the
ability that local process could give *any* advice hint with vector
interface for some reason (e.g., performance). Since there is no
concrete example in upstream yet, it would be better to remove the
abiliity at this moment and need to review when such new advice comes
up.
Fixes: ecb8ac8b1f ("mm/madvise: introduce process_madvise() syscall: an external memory hinting API")
Reported-by: Jann Horn <jannh@google.com>
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There's a memory leak in afs_parse_source() whereby multiple source=
parameters overwrite fc->source in the fs_context struct without freeing
the previously recorded source.
Fix this by only permitting a single source parameter and rejecting with
an error all subsequent ones.
This was caught by syzbot with the kernel memory leak detector, showing
something like the following trace:
unreferenced object 0xffff888114375440 (size 32):
comm "repro", pid 5168, jiffies 4294923723 (age 569.948s)
backtrace:
slab_post_alloc_hook+0x42/0x79
__kmalloc_track_caller+0x125/0x16a
kmemdup_nul+0x24/0x3c
vfs_parse_fs_string+0x5a/0xa1
generic_parse_monolithic+0x9d/0xc5
do_new_mount+0x10d/0x15a
do_mount+0x5f/0x8e
__do_sys_mount+0xff/0x127
do_syscall_64+0x2d/0x3a
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 13fcc68370 ("afs: Add fs_context support")
Reported-by: syzbot+86dc6632faaca40133ab@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Will notes that .quad is too long; while we get the right lsl
instruction, the rest of the instruction stream is incorrect.
Bug: 175018033
Fixes: e58f084735 ("ANDROID: x86: entry: work around LLVM_IAS=1 bug in LSL")
Reported-by: Alistair Delva <adelva@google.com>
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: Ied2fd2351eee72ff95402d80cbb1cefb78c6880a
Pull sparc64 csum fix from Al Viro:
"Fix for a brown paperbag regression in sparc64"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
[regression fix] really dumb fuckup in sparc64 __csum_partial_copy() changes
~0U is -1, not 1
Reported-by: Anatoly Pugachev <matorola@gmail.com>
Tested-by: Anatoly Pugachev <matorola@gmail.com>
Fixes: fdf8bee96f "sparc64: propagate the calling convention changes down to __csum_partial_copy_...()"
X-brown-paperbag: yes
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Pull seq_file fix from Al Viro:
"This fixes a regression introduced in this cycle wrt iov_iter based
variant for reading a seq_file"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
fix return values of seq_read_iter()
This reverts commit 1243dc518c.
percpu_rwsem is an rcu based lock. Under loaded conditions
this lock will require that each cpu perform a switch, causing
exessive delays with long-running tasks on those CPUs.
In the case of hotplug/pause, this can slow down the ability
to activate/deactivate a CPU.
Revert the change from cpuset_mutex to percpu_rwsem, to
eliminate that overhead, and revert to a global lock.
Bug: 161210528
Change-Id: Id00dcaa6d601b561d1321d3e944b6c52e9663f1a
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
Incorporate a vendor hook in the resume cpus path
so that vendor specific activities may take place.
Bug: 161210528
Change-Id: I74d03247491b004e891dbcfe06a478d00a95ba9f
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
In the resume_cpus() path, cpus cannot be taken
advantage of until the cpus write lock is acquired,
and cpus are activated and domains rebuilt. This
can incurr significant delay in the unpause operation.
Additionally, if scheduled through the kworker thread,
the wait time for rebuilding sched domains becomes
large due to a busy system that can prevent the kworker
from executing.
Activate the cpus and call the cpuset_hotplug_workfn
directly within resume_cpus prior to getting the cpus
write lock, thereby eliminating delays associated
with scheduling this activity.
Bug: 161210528
Change-Id: Ie2521f28ed9078b22d421d792f08413016d4dd62
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
Signed-off-by: Todd Kjos <tkjos@google.com>
paused_cpus intending to force CPUs to go idle as quickly as possible,
adding a migration step, to drain the rq from any running task.
Two steps are actually needed. The first one, "lazy", will run before the
cpu_active_mask has been synced. The second one will run after. It is
possible for another CPU, to observe an outdated version of that mask and
to enqueue a task on a rq that has just been marked inactive. The second
migration is there to catch any of those spurious move, while the first
one will drain the rq as quickly as possible to let the CPU reach an idle
state.
Bug: 161210528
Change-Id: Ie26c2e4c42665dd61d41a899a84536e56bf2b887
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
pause_cpus intends to have a way to force a CPU to go idle and to resume
as quickly as possible, with as little disruption as possible on the
system. This is a way of saving energy or meet thermal constraints, for
which a full CPU hotunplug is too slow. A paused CPU is simply deactivated
from the scheduler point of view. This corresponds to the first hotunplug
step.
Each pause operation still needs some heavy synchronization. Allowing to
pause several CPUs in one go mitigate that issue.
Paused CPUs can be resumed with resume_cpus(), which also takes a cpumask
as an input.
Few limitations:
* It isn't possible to pause a CPU which is running SCHED_DEADLINE task.
* A paused CPU will be removed from any cpuset it is part of. Resuming
the CPU won't put back this CPU in the cpuset if using cgroup1.
Cgroup2 doesn't have this limitation.
* per-CPU kthreads are still allowed to run on a paused CPU.
Bug: 161210528
Change-Id: I1f5cb28190f8ec979bb8640a89b022f2f7266bcf
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
In the event of a partial _cpu_down, (i.e. _cpu_down(target) where
target > CPUHP_AP_OFFLINE), the cpu_online_mask won't be aligned with
cpu_active_mask. This is an issue when trying to offline the last CPU
from cpu_active_mask, while num_online_cpus() > 1.
Protect against this case by checking num_active_cpus() instead of
num_online_cpus().
Bug: 161210528
Change-Id: Ibe7d9ef69e5f91e99be0d98076614a7654bda094
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
In the event of a partial hotunplug, a stable state with a CPU set in the
online_mask and cleared from active_mask can happen. An online CPU, from a
scheduler point of view, should be part of the cpu_active_mask.
Bug: 161210528
Change-Id: I0d0aa6fca4c6dc145634c4aad6519045e0afc8e2
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Adding support in update_max_interval() for incomplete HP _cpu_down, where
cpu_active_mask != cpu_online_mask. This situation can happen in the event
of a partial _cpu_down. i.e. _cpu_down(target) where
target > CPUHP_AP_OFFLINE.
Bug: 161210528
Change-Id: Ia422057c65f16dc9aa8f6d272098b2308b00f0ac
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
In the event of a partial hotunplug, a stable state with a CPU set in the
online mask but cleared in the active can happen. This is problematic for
the window between the active mask clearing and the sched domains rebuild.
RT could bounce back a task, migrated off a hotunplugged CPU. Introducing
an intersection between lowest_mask and the cpu_active_mask to prevent a
such situation.
Bug: 161210528
Change-Id: I4f8cb782c2ca560c297b7f4bdb2336918c83a5a1
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
This new interface allows to trigger a stopper on a given CPU and wait
for the end of the work in a separated function cpu_stop_work_wait().
This differs from stop_one_cpu_nowait() by allowing the usage of the
cpu_stop completion mechanism.
Bug: 161210528
Change-Id: Ida51371e32897d008ece0639190fc21feabb0f28
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
