The kernel does not use any keys besides IA so we don't need to
install IB/DA/DB/GA on kernel exit if we arrange to install them
on task switch instead, which we can expect to happen an order of
magnitude less often.
Furthermore we can avoid installing the user IA in the case where the
user task has IA disabled and just leave the kernel IA installed. This
also lets us avoid needing to install IA on kernel entry.
On an Apple M1 under a hypervisor, the overhead of kernel entry/exit
has been measured to be reduced by 15.6ns in the case where IA is
enabled, and 31.9ns in the case where IA is disabled.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Link: https://linux-review.googlesource.com/id/Ieddf6b580d23c9e0bed45a822dabe72d2ffc9a8e
Link: https://lore.kernel.org/r/2d653d055f38f779937f2b92f8ddd5cf9e4af4f4.1616123271.git.pcc@google.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 192536783
(cherry picked from commit b90e483938)
Change-Id: Ia01f55f50c55b53e65ea7089a3bb61ee7660e578
[quic_eberman@quicinc.com: resolve merge conflict in
arch/arm64/kernel/process.c]
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Peter Collingbourne <pcc@google.com>
This change introduces a prctl that allows the user program to control
which PAC keys are enabled in a particular task. The main reason
why this is useful is to enable a userspace ABI that uses PAC to
sign and authenticate function pointers and other pointers exposed
outside of the function, while still allowing binaries conforming
to the ABI to interoperate with legacy binaries that do not sign or
authenticate pointers.
The idea is that a dynamic loader or early startup code would issue
this prctl very early after establishing that a process may load legacy
binaries, but before executing any PAC instructions.
This change adds a small amount of overhead to kernel entry and exit
due to additional required instruction sequences.
On a DragonBoard 845c (Cortex-A75) with the powersave governor, the
overhead of similar instruction sequences was measured as 4.9ns when
simulating the common case where IA is left enabled, or 43.7ns when
simulating the uncommon case where IA is disabled. These numbers can
be seen as the worst case scenario, since in more realistic scenarios
a better performing governor would be used and a newer chip would be
used that would support PAC unlike Cortex-A75 and would be expected
to be faster than Cortex-A75.
On an Apple M1 under a hypervisor, the overhead of the entry/exit
instruction sequences introduced by this patch was measured as 0.3ns
in the case where IA is left enabled, and 33.0ns in the case where
IA is disabled.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Link: https://linux-review.googlesource.com/id/Ibc41a5e6a76b275efbaa126b31119dc197b927a5
Link: https://lore.kernel.org/r/d6609065f8f40397a4124654eb68c9f490b4d477.1616123271.git.pcc@google.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 192536783
(cherry picked from commit 201698626f)
Change-Id: Ic0a21c92a22575f9ec3599fb67bd2931a50b9f04
[quic_eberman@quicinc.com: Resolved merge conflict in
arch/arm64/kernel/process.c]
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Peter Collingbourne <pcc@google.com>
Add ANDROID_OEM_DATA to cleancache_ops which allows a new function call
between cleancache core and cleancache backend.
Bug: 192984560
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Change-Id: I99fb98f33b564fb288dc0d368b9d3049de5efdf9
Add ANDROID_OEM_DATA to block_device_operations which allows a new
vendor specific function call.
Bug: 193106408
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Change-Id: I472f1cc25698c841841822908c4827545b8593df
Psi polling mechanism is trying to minimize the number of wakeups to
run psi_poll_work and is currently relying on timer_pending() to detect
when this work is already scheduled. This provides a window of opportunity
for psi_group_change to schedule an immediate psi_poll_work after
poll_timer_fn got called but before psi_poll_work could reschedule itself.
Below is the depiction of this entire window:
poll_timer_fn
wake_up_interruptible(&group->poll_wait);
psi_poll_worker
wait_event_interruptible(group->poll_wait, ...)
psi_poll_work
psi_schedule_poll_work
if (timer_pending(&group->poll_timer)) return;
...
mod_timer(&group->poll_timer, jiffies + delay);
Prior to 461daba06b we used to rely on poll_scheduled atomic which was
reset and set back inside psi_poll_work and therefore this race window
was much smaller.
The larger window causes increased number of wakeups and our partners
report visible power regression of ~10mA after applying 461daba06b.
Bring back the poll_scheduled atomic and make this race window even
narrower by resetting poll_scheduled only when we reach polling expiration
time. This does not completely eliminate the possibility of extra wakeups
caused by a race with psi_group_change however it will limit it to the
worst case scenario of one extra wakeup per every tracking window (0.5s
in the worst case).
This patch also ensures correct ordering between clearing poll_scheduled
flag and obtaining changed_states using memory barrier. Correct ordering
between updating changed_states and setting poll_scheduled is ensured by
atomic_xchg operation.
By tracing the number of immediate rescheduling attempts performed by
psi_group_change and the number of these attempts being blocked due to
psi monitor being already active, we can assess the effects of this change:
Before the patch:
Run#1 Run#2 Run#3
Immediate reschedules attempted: 684365 1385156 1261240
Immediate reschedules blocked: 682846 1381654 1258682
Immediate reschedules (delta): 1519 3502 2558
Immediate reschedules (% of attempted): 0.22% 0.25% 0.20%
After the patch:
Run#1 Run#2 Run#3
Immediate reschedules attempted: 882244 770298 426218
Immediate reschedules blocked: 881996 769796 426074
Immediate reschedules (delta): 248 502 144
Immediate reschedules (% of attempted): 0.03% 0.07% 0.03%
The number of non-blocked immediate reschedules dropped from 0.22-0.25%
to 0.03-0.07%. The drop is attributed to the decrease in the race window
size and the fact that we allow this race only when psi monitors reach
polling window expiration time.
Fixes: 461daba06b ("psi: eliminate kthread_worker from psi trigger scheduling mechanism")
Reported-by: Kathleen Chang <yt.chang@mediatek.com>
Reported-by: Wenju Xu <wenju.xu@mediatek.com>
Reported-by: Jonathan Chen <jonathan.jmchen@mediatek.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Tested-by: SH Chen <show-hong.chen@mediatek.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Link: https://lore.kernel.org/patchwork/patch/1455172/
Bug: 191127654
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ie61547ca043e702442a9c6db1468cfb60ff2e729
Enable CONFIG_MEMCG config to provide a way to use memory cgroups with
GKI kernels. If not needed, memcgs can be disabled using
"group_disable=memory" kernel command-line option.
Bug: 191223209
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ife5cfe17576d92ac116dabd1a118bc0bb013b26f
Some vendors want to add a field when a 'sruct sock' is added so give a
hook to handle this. Any memory allocated when
trace_android_rvh_sk_alloc() is called needs to be freed when
trace_android_rvh_sk_free() is called.
Note, if trace_android_rvh_sk_alloc() fails, be sure to be able to
handle this in trace_android_rvh_sk_free(), but that should not be an
issue as that needs to be addressed in vendor code that runs for 'struct
sock' objects that have been created before the vendor code is loaded no
matter what.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I108a2f31d2dcc228f46159816deee6235afafbbd
Some vendors want to add a field when a 'sruct nf_conn' is added so give a
hook to handle this. Any memory allocated when
trace_android_rvh_nf_conn_alloc() is called needs to be freed when
trace_android_rvh_nf_conn_free() is called.
Note, if trace_android_rvh_nf_conn_alloc() fails, be sure to be able to
handle this in trace_android_rvh_nf_conn_free(), but that should not be
an issue as that needs to be addressed in vendor code that runs for
'struct nf_conn' objects that have been created before the vendor code
is loaded no matter what.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I4d2b025196a3df7ba4adec313c90483811cac728
Some vendors want to add things to 'struct sock', so give them a u64
where they can then have a pointer off to their private data and they
can do whatever they want to do without breaking or changing any abi for
anyone else.
Note, usually an android trace hook is also needed to use this properly,
so be aware that this will be required as well.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: Iab0b5570753d4a9722ecf9ca9eeb9b9887e2a9d9
Some vendors want to add things to 'struct nf_conn', so give them a u64
where they can then have a pointer off to their private data and they
can do whatever they want to do without breaking or changing any abi for
anyone else.
Note, usually an android trace hook is also needed to use this properly,
so be aware that this will be required as well.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I245c162ee3fb083e3f39cf7bec3bd78cb624e005
Add a field in mem_cgroup to record additional per-cgroup information
for memory policy tuning.
Bug: 192052083
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: I28c8bc1c2455d53e68a05555b57b76ded27af98a
Add a pglist_data field to record additional node parameters.
Bug: 192052083
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: I3d764ab298c71ab9aba245867ee529045551aef4
we found crash in dwc3_disconnect_gadget(),
it is because dwc->gadget_driver become NULL before async access.
7dc0c55e9f ('USB: UDC core: Add udc_async_callbacks gadget op')
suggest a common way to avoid such kind of issue.
this change implment the callback in dwc3 and
change related functions which have callback to usb gadget driver.
Signed-off-by: Linyu Yuan <linyyuan@codeaurora.org>
Bug: 193006095
Link: https://lore.kernel.org/linux-usb/20210629015118.7944-1-linyyuan@codeaurora.org
Change-Id: Id6774f7f6b7c8d31338128ffc33f01f5575f4d16
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Some devices have USB compositions which may require multiple endpoints
that support EP bursting. HW defined TX FIFO sizes may not always be
sufficient for these compositions. By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth. With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.
By introducing the check_config() callback, the resizing logic can fetch
the maximum number of endpoints used in the USB composition (can contain
multiple configurations), which helps ensure that the resizing logic can
fulfill the configuration(s), or return an error to the gadget layer
otherwise during bind time.
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1625908395-5498-4-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9f607a309fhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5066387ad4b434dd9dc31f119535d5d48e256a3a
'struct fscrypt_operations' shouldn't really be part of the KMI, as
there's no reason for loadable modules to use it. However, due to the
way MODVERSIONS calculates symbol CRCs by recursively dereferencing
structures, changes to 'struct fscrypt_operations' affect the CRCs of
KMI functions exported from certain core kernel files such as
fs/dcache.c. That brings it in-scope for the KMI freeze.
There is an OEM who wants to add fields to this struct, so add an
ANDROID_OEM_DATA_ARRAY for them to use.
Bug: 173475629
Change-Id: Idfc76884fce8a5fcc0837cd9363695d5428b1624
Signed-off-by: Eric Biggers <ebiggers@google.com>
'struct fscrypt_operations' shouldn't really be part of the KMI, as
there's no reason for loadable modules to use it. However, due to the
way MODVERSIONS calculates symbol CRCs by recursively dereferencing
structures, changes to 'struct fscrypt_operations' affect the CRCs of
KMI functions exported from certain core kernel files such as
fs/dcache.c. That brings it in-scope for the KMI freeze.
Therefore, add some reserved fields to this struct for LTS updates.
Bug: 151154716
Change-Id: Ic3bf66c93a9be167a0a5b257bd55e2719d99a1b4
Signed-off-by: Eric Biggers <ebiggers@google.com>
Commit 9975da5f43 ("ANDROID: mm: allow fast reclaim of shmem pages")
allows pages to add only to the tail of the inactive file lru for faster
reclaims. Extend the same to allow the pages added to the head of the
inactive file lru too. This will enable users to selectively add the
shmem file pages to head or tail of the inactive file lru.
Bug: 187798288
Change-Id: Icf167e1e3ea68257291478e1f16de678ecbf6320
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Enable configuration to set the networking process priority.
CONFIG_CGROUP_NET_PRIO=y
Bug: 190818101
Change-Id: I2c9344bd8650e58796cca0ef31e05c2d0b813356
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
The overhead of sysfs directory creation/teardown during
dma_buf_attach()/dma_buf_detach() is causing perf regressions for
certain drivers.
Bug: 192621117
Change-Id: I908aa3b2717bf2e183628be3446e0069ce24c68a
Fixes: 621f94a601 (BACKPORT: FROMLIST: dmabuf: Add the capability to
expose DMA-BUF stats in sysfs)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
in our vendor driver, we need the following three kernel variables:
include/linuc/mm.h:
extern unsigned long stack_guard_gap;
extern int sysctl_legacy_va_layout;
include/linux/security.h:
extern unsigned long mmap_min_addr;
Bug: 191439466
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I9d1759d8157ddd214475742e417dfb9e870d4b2e
The Gadget API has a theoretical race when a gadget driver is unbound.
Although the pull-up is turned off before the driver's ->unbind
callback runs, if the USB cable were to be unplugged at just the wrong
moment there would be nothing to prevent the UDC driver from invoking
the ->disconnect callback after the unbind has finished. In theory,
other asynchronous callbacks could also happen during the time before
the UDC driver's udc_stop routine is called, and the gadget driver
would not be prepared to handle any of them.
We need a way to tell UDC drivers to stop issuing asynchronous (that is,
->suspend, ->resume, ->disconnect, ->reset, or ->setup) callbacks at
some point after the pull-up has been turned off and before the
->unbind callback runs. This patch adds a new ->udc_async_callbacks
callback to the usb_gadget_ops structure for precisely this purpose,
and it adds the corresponding support to the UDC core.
Later patches in this series add support for udc_async_callbacks to
several UDC drivers.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20210520202144.GC1216852@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 192984564
Change-Id: Ib50e7292436fe2067cdd6d9e953549f74a2513a9
(cherry picked from commit 7dc0c55e9f)
Signed-off-by: Jack Pham <jackp@codeaurora.org>
There are a lot of different structures that need to have a "frozen" abi
for the next 5+ years. Add padding to a lot of them in order to be able
to handle any future changes that might be needed due to LTS and
security fixes that might come up.
It's a best guess, based on what has happened in the past from the
5.4.0..5.4.129 release (1 1/2 years). Yes, past changes do not mean
that future changes will also be needed in the same area, but that is a
hint that those areas are both well maintained and looked after, and
there have been previous problems found in them.
Also the list of structures that are being required based on OEM usage
in the android/ symbol lists were consulted as that's a larger list than
what has been changed in the past.
Hopefully we caught everything we need to worry about, only time will
tell...
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I880bbcda0628a7459988eeb49d18655522697664
Try to mitigate potential future driver core api changes by padding to
struct bus_type, struct device_driver, struct class, and struct device.
Based on a patch from Michal Marek <mmarek@suse.cz> from the SLES kernel
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6892cde6481ba775789f0c02239dcfde3a26b56e
Try to mitigate potential future driver core api changes by adding a
padding to struct elevator_mq_ops and struct elevator_type.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia4c2667fd5ca9e6dd2e0d30b95a0f8d5eb7921dc
Try to mitigate potential future driver core api changes by adding a
padding to struct scsi_cmnd, struct scsi_device, and struct
scsi_host_template.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie6a2b91970e8f9063bf00e96a0dff661f77b8e8d
Try to mitigate potential future driver core api changes by adding a
padding to struct work_struct and struct delayed_work
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5492a13e2430c1a5775aec52518144b7aa4f3268
Try to mitigate potential future driver core api changes by adding a
padding to struct user_struct and struct sched_domain.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie8f685122767b690a116193aefd8c5e3b6ef8f17
Try to mitigate potential future driver core api changes by adding a
padding to stuct phy_device and struct phy_driver
Inspired by the upstream changes in 5.4.26 and 4.19.111
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8dbc5f76e9eddfc5741f944168222aedacd0a8bb
Try to mitigate potential future driver core api changes by adding a
padding to a bunch of filesystem structures.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Change-Id: Ida6d98d30f292c980ab07e0250fec5268c4c87ed
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Try to mitigate potential future driver core api changes by adding a
padding to struct dentry and struct dentry_operations.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idde3c6e99bd4af3a91ba115b8ec148e3e1cdd4a9
Try to mitigate potential future driver core api changes by adding a
padding to struct bio_integrity_payload and struct bio_set.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0397ede2e11560ad9422cd7765434fcd4f7a6dd8
Do not sleep for retrying for __GFP_NORERY since it's failfast
mode approach. User could retry the allocation without the flag
by themselves if they see the failure.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ic6a857978fda8e353b9ed770d1e0ba1808fd201e
alloc_contig_range is supposed to work on max(MAX_ORDER_NR_PAGES,
or pageblock_nr_pages) granularity aligned range. If it fails
at a page and return error to user, user doesn't know what page
makes the allocation failure and keep retrying another allocation
with new range including the failed page and encountered error
again and again until it could escape the out of the granularity
block. Instead, let's make CMA aware of what pfn was troubled in
previous trial and then continue to work new pageblock out of the
failed page so it doesn't see the repeated error repeatedly.
Currently, this option works for only __GFP_NORETRY case for
safe for existing CMA users.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I0959c9df3d4b36408a68920abbb4d52d31026079
I found sometime cma allocation took a long time to be succeeded
because one of the pages is in the middle of zapping(e.g., munmap, exit)
so alloc_contig_range couldn't migrate the page because it was zero
page mapcount. So, CMA allocator need to wait it until tlb batching
frees the page and the batching free happens on the target process's
context which is quite random, sometimes, very low priority process
on little core. It makes CMA allocation very slow up to several hundreds
millisecond.
To solve the issue, let's make the TLB free batching aware of CMA
progress so whenever cma allocation is going on, TLB free batching
should bail out asap to minimize cma allocation latency.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ic76ecff795639085c4372791d922301467563a06
lru_cache_disable is not trivial cost since it should run work
from every cores in the system. Thus, repeated call of the
function whenever alloc_contig_range in the cma's allocation loop
is called is expensive.
This patch makes the lru_cache_disable smarter in that it will
not run __lru_add_drain_all since it knows the cache was already
disabled by someone else.
With that, user of alloc_contig_range can disable the lru cache
in advance in their context so that subsequent alloc_contig_range
for user's operation will avoid the costly function call.
This patch moves lru_cache APIs from swap.h to swap.c and export
it for vendor users.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I23da8599c55db49dc80226285972e4cd80dedcff
Currently, alloc_contig_range expects that even though a page fails
with -EBUSY from __alloc_contig_migrate_range, it want to check
those failed pages in test_pages_isolated again with hope that
those page would be freed soon so cma allocatoin would be succeeded.
However, it depends on the luck and I found sometimes test_page_isolated
constantly fails at the page repeatedly whenever cma_alloc retried.
Rather than burning out CPU to check the page's status in
test_pages_isolated for GFP_NORETRY allocation, just bail out and
relies on the user what they want to do.
Currently, this option works for only __GFP_NORETRY case for safe
of existing other users.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I9211452be06960dc7d8f854537e53b3fc5262c8e
alloc_contig_range is the core worker function for CMA allocation
so it has every information to be able to understand allocation
latency. For example, how many pages are migrated, how many time
unmap was needed to migrate pages, how many times it encountered
errors by some reasons.
This patch adds such statistics in the alloc_contig_range and
return it to user so user can use those information to analyize
latency. The cma_alloc is first user for the statistics, which
export the statistics as new trace event(i.e., cma_alloc_info).
It was really usefuli to optimize cma allocation work.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I7be43cc89d11078e2a324d2d06aada6d8e9e1cc9
Currently, pcplists are drained during set_migratetype_isolate() which
means once per pageblock processed start_isolate_page_range(). This is
somewhat wasteful. Moreover, the callers might need different guarantees,
and the draining is currently prone to races and does not guarantee that
no page from isolated pageblock will end up on the pcplist after the
drain.
Better guarantees are added by later patches and require explicit actions
by page isolation users that need them. Thus it makes sense to move the
current imperfect draining to the callers also as a preparation step.
Link: https://lkml.kernel.org/r/20201111092812.11329-7-vbabka@suse.cz
Suggested-by: David Hildenbrand <david@redhat.com>
Suggested-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7612921f23)
Change-Id: I10fc574024606c499ddda325d188d181aff7ceec
Add a hook to query from vendor's compress driver if it is support pause
in draining and if the platform need to keep in draining state.
Bug: 184020292
Bug: 178992384
Change-Id: Id2e2ff72d7ee66fc633473ec109ed3d8a2baaeff
Signed-off-by: Robert Lee <lerobert@google.com>
This vendor hook let us initialize payload of the request.
Bug: 188749221
Change-Id: I51d6a3010ac0ab36066dbe1368158592832112b7
Signed-off-by: Yang Yang <yang.yang@vivo.com>
This vendor hook let us attach oem data as payload to the request.
The payload is used by oem driver for debugging purpose.
Bug: 188749221
Change-Id: Iac598bd9cce836dac0efe9198a3e7752928f351a
Signed-off-by: Yang Yang <yang.yang@vivo.com>
