Currently, uinput doesn't use the input_set_timestamp API, so any
event injected using uinput is not accurately timestamped in terms of
measuring when the actual event happened. Hence, call the
input_set_timestamp API from uinput in order to provide a more
accurate sense of time for the event. Propagate only the timestamps
which are a) positive, b) within a pre-defined offset (10 secs) from
the current time, and c) not in the future.
Bug: 271946580
Bug: 277040837
Change-Id: I928be61d0114b78e2098995ee49eeb0376bef2a3
(cherry picked from commit 3a2df60200https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git master)
Signed-off-by: Biswarup Pal <biswarupp@google.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Siarhei Vishniakou <svv@google.com>
Link: https://lore.kernel.org/r/20230427000152.1407471-1-biswarupp@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit ee1f5fc55cc7bf1bca78edbb8a1f9d989d4ea03e)
The following crash is observed 100% of the time during resume from
the hibernation on a x86 QEMU system.
[ 12.931887] ? __die_body+0x1a/0x60
[ 12.932324] ? page_fault_oops+0x156/0x420
[ 12.932824] ? search_exception_tables+0x37/0x50
[ 12.933389] ? fixup_exception+0x21/0x300
[ 12.933889] ? exc_page_fault+0x69/0x150
[ 12.934371] ? asm_exc_page_fault+0x26/0x30
[ 12.934869] ? get_buffer.constprop.0+0xac/0x100
[ 12.935428] snapshot_write_next+0x7c/0x9f0
[ 12.935929] ? submit_bio_noacct_nocheck+0x2c2/0x370
[ 12.936530] ? submit_bio_noacct+0x44/0x2c0
[ 12.937035] ? hib_submit_io+0xa5/0x110
[ 12.937501] load_image+0x83/0x1a0
[ 12.937919] swsusp_read+0x17f/0x1d0
[ 12.938355] ? create_basic_memory_bitmaps+0x1b7/0x240
[ 12.938967] load_image_and_restore+0x45/0xc0
[ 12.939494] software_resume+0x13c/0x180
[ 12.939994] resume_store+0xa3/0x1d0
The commit being fixed introduced a bug in copying the zero bitmap
to safe pages. A temporary bitmap is allocated with PG_ANY flag in
prepare_image() to make a copy of zero bitmap after the unsafe pages
are marked. Freeing this temporary bitmap with PG_UNSAFE_KEEP later
results in an inconsistent state of unsafe pages. Since free bit is
left as is for this temporary bitmap after free, these pages are
treated as unsafe pages when they are allocated again. This results
in incorrect calculation of the number of pages pre-allocated for the
image.
nr_pages = (nr_zero_pages + nr_copy_pages) - nr_highmem - allocated_unsafe_pages;
The allocate_unsafe_pages is estimated to be higher than the actual
which results in running short of pages in safe_pages_list. Hence the
crash is observed in get_buffer() due to NULL pointer access of
safe_pages_list.
Fix this issue by creating the temporary zero bitmap from safe pages
(free bit not set) so that the corresponding free bits can be cleared
while freeing this bitmap.
Bug: 311131385
(cherry picked from commit b21f18ef96
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master)
Fixes: 005e8dddd4 ("PM: hibernate: don't store zero pages in the image file")
Suggested-by:: Brian Geffon <bgeffon@google.com>
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Reviewed-by: Brian Geffon <bgeffon@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change-Id: Id68699710e40c5e8eec227bfe0d8311c1e788d5e
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Signed-off-by: Mukesh Pilaniya <quic_mpilaniy@quicinc.com>
On ChromeOS we've observed a considerable number of in-use pages filled with
zeros. Today with hibernate it's entirely possible that saveable pages are just
zero filled. Since we're already copying pages word-by-word in do_copy_page it
becomes almost free to determine if a page was completely filled with zeros.
This change introduces a new bitmap which will track these zero pages. If a page
is zero it will not be included in the saved image, instead to track these zero
pages in the image file we will introduce a new flag which we will set on the
packed PFN list. When reading back in the image file we will detect these zero
page PFNs and rebuild the zero page bitmap.
When the image is being loaded through calls to write_next_page if we encounter
a zero page we will silently memset it to 0 and then continue on to the next
page. Given the implementation in snapshot_read_next/snapshot_write_next this
change will be transparent to non-compressed/compressed and swsusp modes of
operation.
To provide some concrete numbers from simple ad-hoc testing, on a device which
was lightly in use we saw that:
PM: hibernation: Image created (964408 pages copied, 548304 zero pages)
Of the approximately 6.2GB of saveable pages 2.2GB (36%) were just zero filled
and could be tracked entirely within the packed PFN list. The savings would
obviously be much lower for lzo compressed images, but even in the case of
compression not copying pages across to the compression threads will still
speed things up. It's also possible that we would see better overall compression
ratios as larger regions of "real data" would improve the compressibility.
Finally, such an approach could dramatically improve swsusp performance
as each one of those zero pages requires a write syscall to reload, by
handling it as part of the packed PFN list we're able to fully avoid
that.
Bug: 311131385
(cherry picked from commit 005e8dddd4
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master)
Signed-off-by: Brian Geffon <bgeffon@google.com>
[ rjw: Whitespace adjustments, removal of redundant parentheses ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change-Id: Ia42a965d10e3a9e3760c29eb1a31b48c575297b9
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Signed-off-by: Mukesh Pilaniya <quic_mpilaniy@quicinc.com>
The system memory map can change over a hibernation-restore cycle due
to a defect in the platform firmware, and some of the page frames used
by the kernel before hibernation may not be available any more during
the subsequent restore which leads to the error below.
[ T357] PM: Image loading progress: 0%
[ T357] PM: Read 2681596 kbytes in 0.03 seconds (89386.53 MB/s)
[ T357] PM: Error -14 resuming
[ T357] PM: Failed to load hibernation image, recovering.
[ T357] PM: Basic memory bitmaps freed
[ T357] OOM killer enabled.
[ T357] Restarting tasks ... done.
[ T357] PM: resume from hibernation failed (-14)
[ T357] PM: Hibernation image not present or could not be loaded.
Add an error message to the unpack() function to allow problematic
page frames to be identified and the source of the problem to be
diagnosed more easily. This can save developers quite a bit of
debugging time.
Bug: 311131385
(cherry picked from commit 3363e0adb3
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
Signed-off-by: Xueqin Luo <luoxueqin@kylinos.cn>
[ rjw: New subject, edited changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change-Id: I8283510db3d3217f679e3cda0c0991f3b9437c18
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Signed-off-by: Mukesh Pilaniya <quic_mpilaniy@quicinc.com>
dev_coredumpm() creates a devcoredump device and adds it
to the core kernel framework which eventually end up
sending uevent to the user space and later creates a
symbolic link to the failed device. An application
running in userspace may be interested in this symbolic
link to get the name of the failed device.
In a issue scenario, once uevent sent to the user space
it start reading '/sys/class/devcoredump/devcdX/failing_device'
to get the actual name of the device which might not been
created and it is in its path of creation.
To fix this, suppress sending uevent till the failing device
symbolic link gets created and send uevent once symbolic
link is created successfully.
Bug: 311580372
Link: https://lore.kernel.org/lkml/1700232572-25823-1-git-send-email-quic_mojha@quicinc.com
Change-Id: Iee739e29492056df9d664ef2294a7e0cdcc4458e
Fixes: 833c95456a ("device coredump: add new device coredump class")
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: stable@vger.kernel.org
Signed-off-by: Naman Jain <quic_namajain@quicinc.com>
In mcq mode, if cmd is pending in device and abort success, response
will not return from device. So we need clear this cmd right now,
else command timeout happen and next time use same tag will have
warning. WARN_ON(lrbp->cmd).
Below is error log:
<3>[ 2277.447611][T21376] ufshcd-mtk 112b0000.ufshci: ufshcd_try_to_abort_task: cmd pending in the device. tag = 7
<3>[ 2277.476954][T21376] ufshcd-mtk 112b0000.ufshci: Aborting tag 7 / CDB 0x2a succeeded
<6>[ 2307.551263][T30974] ufshcd-mtk 112b0000.ufshci: ufshcd_abort: Device abort task at tag 7
<4>[ 2307.623264][ T327] WARNING: CPU: 5 PID: 327 at source/drivers/ufs/core/ufshcd.c:3021 ufshcd_queuecommand+0x66c/0xe34
Bug: 311330965
Link: https://lore.kernel.org/all/20231115131024.15829-1-peter.wang@mediatek.com/
[Peter: Resolved minor conflict in drivers/ufs/core/ufshcd.c ]
Change-Id: I8e5ed6774a68faa4a663cc602dac56faf5e3317c
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
In 4way handshake offload, cfg80211_port_authorized enables driver
to indicate successful 4way handshake to cfg80211 layer. Currently
this path of port authorization is restricted to interface type
NL80211_IFTYPE_STATION and NL80211_IFTYPE_P2P_CLIENT. This patch
extends the support for NL80211_IFTYPE_AP and NL80211_IFTYPE_P2P_GO
interfaces to authorize peer STA/P2P_CLIENT, whenever authentication
is offloaded on the AP/P2P_GO interface.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
Link: https://lore.kernel.org/r/dee3b0a2b4f617e932c90bff4504a89389273632.1695721435.git.vinayak.yadawad@broadcom.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 301410304
(cherry picked from commit e4e7e3af73694380f0d9a742d13b80598a3393e9)
[chenpaul: adjust the format by checkpatch]
Signed-off-by: Paul Chen <chenpaul@google.com>
Change-Id: Id9704d7b412396f45e888895e42ba161ecb0ab56
Introduce new feature flags for OWE offload that driver can
advertise to indicate kernel/application space to avoid DH IE
handling. When this flag is advertised, the driver/device will
take care of DH IE inclusion and processing of peer DH IE to
generate PMK.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
Link: https://lore.kernel.org/r/f891cce4b52c939dfc6b71bb2f73e560e8cad287.1695374530.git.vinayak.yadawad@broadcom.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 301410304
(cherry picked from commit 5482c0a28b2634e7a7d8ddaca7feac183e74b528)
[chenpaul: use reserved fields instead of adding new one]
Signed-off-by: Paul Chen <chenpaul@google.com>
Change-Id: I8322e53b74d995471411967aba846a2b712e5d85
modprobe needs /proc/cmdline to pass module arguments to the module
loader. Sadly, so early in the boot, nothing mounts that FS.
Bug: 301483379
Change-Id: Iaab3000e3b7f908fc81f7f36adf2f73c7d3129a4
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
If open request sent to classic fuse, backing_file is null.
In fuse_release_initialize, fput will trigger a crash.
Bug: 297831741
Change-Id: I2d54d99d62b54c39a6dc9064f8f62488433aff6f
Signed-off-by: liujing40 <liujing40@xiaomi.corp-partner.google.com>
In case the leaf driver wants to use IRQ polling (irq = 0) and
IIR register shows that an interrupt happened in the 8250 hardware
the IRQ data can be NULL. In such a case we need to skip the wake
event as we came to this path from the timer interrupt and quite
likely system is already awake.
Without this fix we have got an Oops:
serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A
...
BUG: kernel NULL pointer dereference, address: 0000000000000010
RIP: 0010:serial8250_handle_irq+0x7c/0x240
Call Trace:
? serial8250_handle_irq+0x7c/0x240
? __pfx_serial8250_timeout+0x10/0x10
Fixes: 0ba9e3a13c ("serial: 8250: Add missing wakeup event reporting")
Cc: stable <stable@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20230831222555.614426-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 311265203
Change-Id: I36cdceb31da5a000f336a96347e99119df308064
(cherry picked from commit cce7fc8b29)
Signed-off-by: Yuan-Jen Cheng <cyuanjen@google.com>
On one error path, pin_user_pages has succeeded and should be
undone.
Bug: 310131277
Change-Id: I92fe0c54bb5b8005f848491f5e9be1090b61fbd1
Signed-off-by: Keir Fraser <keirf@google.com>
This patch adds GKI symbol list for Exynosauto SoC. We need to add
below 3 function symbols and it required by VLX driver.
3 function symbol(s) added
'struct work_struct* current_work()'
'int sigprocmask(int, sigset_t*, sigset_t*)'
'struct thermal_zone_device* thermal_of_zone_register(struct device_node*, int, void*, const struct thermal_zone_device_ops*)'
Bug: 310831391
Change-Id: Ibc0405f9e72eb1cc11095eab715130f4ec1ec0ee
Signed-off-by: Hang Wei <hang01.wei@samsung.com>
vendor may have the need to implement their own util_fits_cpu
function
Bug: 261704404
Change-Id: I0318f6cadd5c45a37f1acafdded479b25e520e6b
Signed-off-by: Chungkai Mei <chungkai@google.com>
allocated for each slab
We want to add an interface that can detect the number of pages
allocated by the slab, and if exceeds a threshold, trigger a
panic or other actions.
Bug: 302090264
Change-Id: I8fcae6a97046806376b95b66085dd5b852c2d1e8
Signed-off-by: Haonan Wang <haonan.wang@unisoc.com>
The purpose of these symbols is for getting irq/softirq latency. Currently we only have symbols for irq_handler_entry and irq_handler_exit. We would use these latency for further monitoring and debugging.
The related tracepoints were defined in trace/events/irq.h. We would use these tracepoints in vendor kernel module.
Bug: 227809911
Signed-off-by: Ziyi Cui <ziyic@google.com>
Change-Id: Idf4ccdede5232689b2752283539aee54a5f67866
Look at the passthrough file and check to see if its mount is read-only.
Bug: 297482438
Signed-off-by: Lyon Wang <lyon.wang@mediatek.com>
Change-Id: I0f483c6bcb1effe395eee07b6d721f343840d115
(cherry picked from commit dbeed23196)
According to UFSHCI 4.0 specification:
5.2 Host Controller Capabilities Registers
5.2.1 Offset 00h: CAP – Controller Capabilities:
"EHS Length in UTRD Supported (EHSLUTRDS): Indicates whether the host
controller supports EHS Length field in UTRD.
0 – Host controller takes EHS length from CMD UPIU, and SW driver use EHS
Length field in CMD UPIU.
1 – HW controller takes EHS length from UTRD, and SW driver use EHS
Length field in UTRD.
NOTE Recommend Host controllers move to taking EHS length from UTRD, and
in UFS-5, it will be mandatory."
So, when UFSHCI 4.0 doesn't support EHS Length field in UTRD, we could use
EHS Length field in CMD UPIU. Remove the limitation that advanced RPMB only
works when EHS length is supported in UTRD.
Bug: 254441685
Fixes: 6ff265fc5e ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg")
Co-developed-by: "jonghwi.rha" <jonghwi.rha@samsung.com>
Signed-off-by: "jonghwi.rha" <jonghwi.rha@samsung.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Link: https://lore.kernel.org/r/20230809181847.102123-2-beanhuo@iokpp.de
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit c91e585cfb)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I10ec989b7d02bed7d828d756fd11078cf73ff371
Add a mmc hook to support customizing mmc queue by vendor host
requirements
Bug: 306334321
Change-Id: I737485c3fc0438ef221cd3ffe81a66f7e3b66500
Signed-off-by: Qilin Tan <qilin.tan@mediatek.com>
Signed-off-by: Browse Zhang <browse.zhang@mediatek.com>
This reverts commit da4d6b9cf8.
Appears to cause stale dcache entries for inodes in /proc/$pid
filesystem resulting in ESRCH failures on access to files
under /proc/self
Bug: 305682813
Bug: 306055483
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I004338c043d7e777fdfef343e45ccb20ff4d503b
In some situations, we want to decrease readaround size for better
performance. So we add this hook.
Bug: 288216516
Change-Id: If2f5f75976c99ff1f82ce29d370f9216926055ab
Signed-off-by: Oven <liyangouwen1@oppo.com>
Tune ReadAhead size for better memory usage and performance.
accordding to Read-Ahead Efficiency on Mobile Devices: Observation,
Characterization, and Optimization form IEEE
Bug: 229839032
Change-Id: I91656bde5e616e181fd7557554d55e7ce1858136
Signed-off-by: liang zhang <liang.zhang@transsion.com>
Signed-off-by: Oven <liyangouwen1@oppo.com>
memory allocations
We add these hooks to avoid key threads blocked in memory allocation
path.
-android_vh_free_unref_page_bypass ----We create a memory pool for the
key threads. This hook determines whether a page should be free to the
pool or to buddy freelist. It works with a existing hook
`android_vh_alloc_pages_reclaim_bypass`, which takes pages out of the
pool.
-android_vh_kvmalloc_node_use_vmalloc ----For key threads, we perfer
not to run into direct reclaim. So we clear __GFP_DIRECT_RECLAIM flag.
For threads which are not that important, we perfer use vmalloc.
-android_vh_should_alloc_pages_retry ----Before key threads run into
direct reclaim, we want to retry with a lower watermark.
-android_vh_unreserve_highatomic_bypass ----We want to keep more
highatomic pages when unreserve them to avoid highatomic allocation
failures.
-android_vh_rmqueue_bulk_bypass ----We found sometimes when key threads
run into rmqueue_bulk, it took several milliseconds spinning at
zone->lock or filling per-cpu pages. We use this hook to take pages from
the mempool mentioned above, rather than grab zone->lock and fill a
batch of pages to per-cpu.
Bug: 288216516
Change-Id: I1656032d6819ca627723341987b6094775bc345f
Signed-off-by: Oven <liyangouwen1@oppo.com>
since we can't control all kvmalloc_node callsite's gfp_flags, we add
a vendor hook in kvmalloc_node to tune the reclaim behavior for some
really high-order allocation
Bug: 300857012
Change-Id: I5f0c4c2921d204289911704e3a205f6a1dc50d04
Signed-off-by: liwei <liwei1234@oppo.com>
commit 050d91c03b upstream.
The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can
lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,
which can lead to integer underflow. As a result, it leads to slab
out-of-bound access.
This patch adds back the IP_SET_HASH_WITH_NET0 macro to
ip_set_hash_netportnet to address the issue.
Bug: 302199939
Fixes: 886503f34d ("netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net")
Suggested-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Kyle Zeng <zengyhkyle@gmail.com>
Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a9e6142e5f)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I11cc1650e7df9d54041164b6bdb01f3a0de46de4
Add the symbol __netif_rx which is needed by rmnet modules.
Symbols added:
__netif_rx
Bug: 308756580
Change-Id: I26dfad610739a18764c9ac6dbd6edb798ba295b6
Signed-off-by: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
For sdcard failure diagnostics, add vendor hooks to monitor the sdcard
bus speed mode change and the sdcard reset failure in the request
recovery handling.
Bug: 303549480
Change-Id: Id40337ffb09a31199335cdb8a273d76618415649
Signed-off-by: Keita Aihara <keita.aihara@sony.com>
This reverts commit 5d0225cdf0.
Reason for revert: b/306244914
Change-Id: Iaf2bda1b0844cfce134c78598af0fca083f32947
Signed-off-by: Will Deacon <willdeacon@google.com>
When connecting to some DisplayPort partners, the initial status update
after entering DisplayPort Alt Mode notifies that the DFP_D/UFP_D is not in
the connected state. This leads to sending a configure message that keeps
the device in USB mode. The port partner then sets DFP_D/UFP_D to the
connected state and HPD to high in the same Attention message. Currently,
the HPD signal is dropped in order to handle configuration.
This patch saves changes to the HPD signal when the device chooses to
configure during dp_altmode_status_update, and invokes sysfs_notify if
necessary for HPD after configuring.
Fixes: 0e3bb7d689 ("usb: typec: Add driver for DisplayPort alternate mode")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/all/20230726020903.1409072-1-rdbabiera@google.com/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 288137625
(cherry picked from commit 5a5ccd61cf)
[rd: resolved minor conflict in displayport.c]
Signed-off-by: RD Babiera <rdbabiera@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:056a17677de932cccda77faf3f1c53a5b59c8cf5)
Merged-In: I26ef49949aa0681ea6b88d8c95f5ddd54fe84664
Change-Id: I26ef49949aa0681ea6b88d8c95f5ddd54fe84664
When a memcg is in the process of being released mem_cgroup_tryget will
fail because its reference count has already reached 0. This can happen
during reclaim if the memcg has already been offlined, and we reclaim all
remaining pages attributed to the offlined memcg. shrink_many attempts to
skip the empty memcg in this case, and continue reclaiming from the
remaining memcgs in the old generation. If there is only one memcg
remaining, or if all remaining memcgs are in the process of being released
then shrink_many will spin until all memcgs have finished being released.
The release occurs through a workqueue, so it can take a while before
kswapd is able to make any further progress.
This fix results in reductions in kswapd activity and direct reclaim in
a test where 28 apps (working set size > total memory) are repeatedly
launched in a random sequence:
A B delta ratio(%)
allocstall_movable 5962 3539 -2423 -40.64
allocstall_normal 2661 2417 -244 -9.17
kswapd_high_wmark_hit_quickly 53152 7594 -45558 -85.71
pageoutrun 57365 11750 -45615 -79.52
Bug: 254441685
Link: https://lkml.kernel.org/r/20230814151636.1639123-1-tjmercier@google.com
Fixes: e4dde56cd2 ("mm: multi-gen LRU: per-node lru_gen_folio lists")
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 6867c7a332)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I37a874d87cf5f2f8fad742f175bc6f603134e660
