Allow the following command to be run to make a build of fips140.ko
that has CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING enabled:
BUILD_CONFIG=common/build.config.gki.aarch64.fips140_eval_testing ./build/build.sh
Bug: 188620248
Change-Id: I0e0be487974c6ad40f3135fc5fec6aa107aab78c
Signed-off-by: Eric Biggers <ebiggers@google.com>
To hot unplug a CPU, the idle task on that CPU calls a few layers of C
code before finally leaving the kernel. When KASAN is in use, poisoned
shadow is left around for each of the active stack frames, and when
shadow call stacks are in use. When shadow call stacks (SCS) are in use
the task's saved SCS SP is left pointing at an arbitrary point within
the task's shadow call stack.
When a CPU is offlined than onlined back into the kernel, this stale
state can adversely affect execution. Stale KASAN shadow can alias new
stackframes and result in bogus KASAN warnings. A stale SCS SP is
effectively a memory leak, and prevents a portion of the shadow call
stack being used. Across a number of hotplug cycles the idle task's
entire shadow call stack can become unusable.
We previously fixed the KASAN issue in commit:
e1b77c9298 ("sched/kasan: remove stale KASAN poison after hotplug")
... by removing any stale KASAN stack poison immediately prior to
onlining a CPU.
Subsequently in commit:
f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
... the refactoring left the KASAN and SCS cleanup in one-time idle
thread initialization code rather than something invoked prior to each
CPU being onlined, breaking both as above.
We fixed SCS (but not KASAN) in commit:
63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")
... but as this runs in the context of the idle task being offlined it's
potentially fragile.
To fix these consistently and more robustly, reset the SCS SP and KASAN
shadow of a CPU's idle task immediately before we online that CPU in
bringup_cpu(). This ensures the idle task always has a consistent state
when it is running, and removes the need to so so when exiting an idle
task.
Whenever any thread is created, dup_task_struct() will give the task a
stack which is free of KASAN shadow, and initialize the task's SCS SP,
so there's no need to specially initialize either for idle thread within
init_idle(), as this was only necessary to handle hotplug cycles.
I've tested this on arm64 with:
* gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK
* clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK
... offlining and onlining CPUS with:
| while true; do
| for C in /sys/devices/system/cpu/cpu*/online; do
| echo 0 > $C;
| echo 1 > $C;
| done
| done
Fixes: f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
Reported-by: Qian Cai <quic_qiancai@quicinc.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Tested-by: Qian Cai <quic_qiancai@quicinc.com>
Link: https://lore.kernel.org/lkml/20211115113310.35693-1-mark.rutland@arm.com/
Bug: 207346964
(cherry picked from commit dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/urgent)
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
Change-Id: Ia2db6477afddcc01fae00c6eb925fb3ec2791130
this critical region should be protected by pool->mutex.
Bug: 207658347
Fixes: e7dac4c323 ("ANDROID: dma-buf: heaps: Add a shrinker controlled page pool")
Signed-off-by: liuhailong <liuhailong@oppo.com>
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I6f129926c96176258a965964c24602fc647db61e
spi_mem_default_supports_op() rejects DTR ops by default to ensure that
the controller drivers that haven't been updated with DTR support
continue to reject them. It also makes sure that controllers that don't
support DTR mode at all (which is most of them at the moment) also
reject them.
This means that controller drivers that want to support DTR mode can't
use spi_mem_default_supports_op(). Driver authors have to roll their own
supports_op() function and mimic the buswidth checks. See
spi-cadence-quadspi.c for example. Or even worse, driver authors might
skip it completely or get it wrong.
Add spi_mem_dtr_supports_op(). It provides a basic sanity check for DTR
ops and performs the buswidth requirement check. Move the logic for
checking buswidth in spi_mem_default_supports_op() to a separate
function so the logic is not repeated twice.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20210204141218.32229-1-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 207737303
(cherry picked from commit 539cf68cd51bfcd2987ce1c44e628e9da69de7c8)
Change-Id: Iaa3951c2e3f51f265b9bea583a3c8bd4fed80bb7
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Enable SPI memory extension to provide high-level
interface to send memory-like commands, which are
used by vendor SPI controllers, like spi-nxp-fspi.
Bug: 207737303
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Change-Id: I9ea58edc1407bead42970c4cc74c5d4a93c99d13
Prevents mishandling USB requests that are no longer present.
Bug: 161010552
Fixes: 483cb5629e ("ANDROID: usb: gadget: f_accessory: Add Android Accessory function")
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I8ff24d6d49214c3bd10a1b5d5e72814ec2a91c61
Commit 94e5305a38 ("usb: ehci: handshake CMD_RUN instead of STS_HALT")
that got added into 5.10.79, added a new bitfield to the struct ehci_hcd
structure. This bitfield is only used by the ehci core, and does not
change the size of the structure overall at all, so comment it properly
so that the CRC of any ehci functions do not change, and update the .xml
file with the newly added bitfield:
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 ehci_hcd at ehci.h:111:1' changed:
type size hasn't changed
1 data member insertion:
'unsigned int is_aspeed', at offset 15 (in bits) at ehci.h:226:1
one impacted interface
Bug: 161946584
Fixes: 94e5305a38 ("usb: ehci: handshake CMD_RUN instead of STS_HALT")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id5d3a9324d9a15f8baaf4aefedda786ed6d949c2
commit 7f2d73788d9067fd4f677ac5f60ffd25945af7af upstream.
For Aspeed, HCHalted status depends on not only Run/Stop but also
ASS/PSS status.
Handshake CMD_RUN on startup instead.
Tested-by: Tao Ren <rentao.bupt@gmail.com>
Reviewed-by: Tao Ren <rentao.bupt@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Neal Liu <neal_liu@aspeedtech.com>
Link: https://lore.kernel.org/r/20210910073619.26095-1-neal_liu@aspeedtech.com
Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 94e5305a38)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I14c0553c973837c1eb0f57d4e4a7ec278ed5abb1
ZONE_DMA32 is enabled by default on android12-5.10, yet it is not
needed for all devices, nor is it desirable to have if not needed. For
instance, if a partner in GKI 1.0 did not use ZONE_DMA32, memory can
be lower for ZONE_NORMAL relative to older targets, such that memory
would run out more quickly in ZONE_NORMAL leading kswapd to be invoked
unnecessarily.
Correspondingly, provide a means of making ZONE_DMA32 empty via the
kernel command line when it is compiled in via CONFIG_ZONE_DMA32.
Bug: 199917449
Change-Id: I70ec76914b92e518d61a61072f0b3cb41cb28646
Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
The FIPS lab is required to test the service indicators and version
information services of the module, i.e. the
fips140_is_approved_service() and fips140_module_version() functions.
There are several ways we could support this:
- Implement the tests in the module ourselves. However it's unclear
that CMVP would allow this, and we would need the full list of tests,
which could change over time depending on what the lab decides to do.
- Support the lab writing, building, and loading a custom kernel module
(or a custom kernel image) that tests these functions.
- Provide a userspace interface to these services, restricted to builds
with CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING=y. This would allow
writing the tests in userspace, which would be much easier.
Implement the last solution, since it's the easier of the two solutions
that are "guaranteed" to be allowed. Make the module register a char
device which supports some ioctls, one per function that needs to be
tested. Also provide some sample userspace code in samples/crypto/.
Note: copy_to_user() would break the integrity check, so take some care
to exclude it. This is allowed since this is non-production code.
Bug: 188620248
Change-Id: Ic256d9c5bd4d0c57ede88a3e3e76e89554909b38
Signed-off-by: Eric Biggers <ebiggers@google.com>
The lab is required to test injecting an integrity error, so add a
module parameter fail_integrity_check=1 which does this. This parameter
is only supported when CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING=y.
Bug: 188620248
Change-Id: I1f3683837706dc1df2755ca5b6e88f21f7956135
Signed-off-by: Eric Biggers <ebiggers@google.com>
It turns out that we have to add more code to the module to support lab
evaluation testing, beyond the error injection support we currently
have. Therefore, rename CONFIG_CRYPTO_FIPS140_MOD_ERROR_INJECTION to
CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING, and move the relevant code into
a new file fips140-eval-testing.c which is conditionally compiled.
Also rename the "broken_alg" module parameter to "fail_selftest" so that
it is similar to "fail_integrity_check" which we'll be adding.
Bug: 188620248
Change-Id: I01bcbf7525690e277854ba4ed8dd89e7cd08d98e
Signed-off-by: Eric Biggers <ebiggers@google.com>
When a task yields, it relinquishes the cpu and
scheduler is tasked to find another task.
However our vendor scheduler logic implementation
could return the same task leading to a loop where
the yielded task gets to run back, so add hook point
in do_sched_yield() for vendor can do some work
before task is scheduled.
Bug: 205804537
Change-Id: I6528c3f4b0ee360559ef9c97cb1eb2b2d1357870
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Function fs endpoint file operations are synchronized via an interruptible
mutex wait. However we see threads that do ep file operations concurrently
are getting blocked for the mutex lock in __fdget_pos(). This is an
uninterruptible wait and we see hung task warnings and kernel panic
if hung_task_panic systcl is enabled if host does not send/receive
the data for long time.
The reason for threads getting blocked in __fdget_pos() is due to
the file position protection introduced by the commit 9c225f2655
("vfs: atomic f_pos accesses as per POSIX"). Since function fs
endpoint files does not have the notion of the file position, switch
to the stream mode. This will bypass the file position mutex and
threads will be blocked in interruptible state for the function fs
mutex.
It should not affects user space as we are only changing the task state
changes the task state from UNINTERRUPTIBLE to INTERRUPTIBLE while waiting
for the USB transfers to be finished. However there is a slight change to
the O_NONBLOCK behavior. Earlier threads that are using O_NONBLOCK are also
getting blocked inside fdget_pos(). Now they reach to function fs and error
code is returned. The non blocking behavior is actually honoured now.
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Link: https://lore.kernel.org/r/1636712682-1226-1-git-send-email-quic_pkondeti@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c76ef96fc00eb398c8fc836b0eb2f82bcc619dc7
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Bug: 206906138
Change-Id: Ifb99336a4da7587c7e71a6c45999a36948194d7a
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
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>
The OASIS virtio spec defines a sound device type ID that is not
present in the header yet.
Signed-off-by: Anton Yakovlev <anton.yakovlev@opensynergy.com>
Link: https://lore.kernel.org/r/20210302164709.3142702-2-anton.yakovlev@opensynergy.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 0ae0337f929a970ee8d83e0e95e6b8d05562ce3b
https://github.com/torvalds/linux.git master)
Change-Id: I486371e1ec8d25d42f85f710ce82e866367df4da
Signed-off-by: Hao Chen <chenhaosjtuacm@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: d65efd5b73dc ("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 4e0c1040758540aac34b753ed41792c8ad322a8c)
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 4d5b5539742d2554591751b4248b0204d20dcc9d)
[ 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 52f88693378a58094c538662ba652aff0253c4fe)
[ 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 29bc22ac5e5bc63275e850f0c8fc549e3d0e306b)
[ 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
Because dma-buf.name can be freed in func: "dma_buf_set_name",
so, we need to acquire lock first before we read/write dma_buf.name
to prevent Use After Free(UAF) issue.
Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/lkml/20211029021541.101157-1-guangming.cao@mediatek.com/T/
Bug: 205102180
(cherry picked from commit 8c0fd126263730c35927cc8445727afb79219a19
https://cgit.freedesktop.org/drm/drm-misc)
Change-Id: I4ba911137ad9dae7682230245d2fa2a19f7c209f
Signed-off-by: Yunfei Wang <yf.wang@mediatek.com>
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 ad216c0316ad6391d90f4de0a7f59396b2925a06
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
Change-Id: I450781b5734570d1b9e8c63ac29ad3635c8e49bb
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
