Run `bazel run @//common:kernel_aarch64_abi_update_protected_exports` on
latest kernel to clean up the protected exports list. This is blocking
updating the ABI since this list needs to be accurate before updating
the ABI.
Bug: 287170531
Change-Id: I8173060087cad060314ae0e494e30b71052e1d8f
Signed-off-by: Will McVicker <willmcvicker@google.com>
Patch series "Per-VMA lock support for swap and userfaults", v7.
When per-VMA locks were introduced in [1] several types of page faults
would still fall back to mmap_lock to keep the patchset simple. Among
them are swap and userfault pages. The main reason for skipping those
cases was the fact that mmap_lock could be dropped while handling these
faults and that required additional logic to be implemented. Implement
the mechanism to allow per-VMA locks to be dropped for these cases.
First, change handle_mm_fault to drop per-VMA locks when returning
VM_FAULT_RETRY or VM_FAULT_COMPLETED to be consistent with the way
mmap_lock is handled. Then change folio_lock_or_retry to accept vm_fault
and return vm_fault_t which simplifies later patches. Finally allow swap
and uffd page faults to be handled under per-VMA locks by dropping per-VMA
and retrying, the same way it's done under mmap_lock. Naturally, once VMA
lock is dropped that VMA should be assumed unstable and can't be used.
This patch (of 6):
Commit [1] introduced IO polling support duding swapin to reduce swap read
latency for block devices that can be polled. However later commit [2]
removed polling support. Therefore it seems safe to remove do_poll
parameter in read_swap_cache_async and always call swap_readpage with
synchronous=false waiting for IO completion in folio_lock_or_retry.
[1] commit 23955622ff ("swap: add block io poll in swapin path")
[2] commit 9650b453a3 ("block: ignore RWF_HIPRI hint for sync dio")
Link: https://lkml.kernel.org/r/20230630211957.1341547-1-surenb@google.com
Link: https://lkml.kernel.org/r/20230630211957.1341547-2-surenb@google.com
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Suggested-by: "Huang, Ying" <ying.huang@intel.com>
Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Hillf Danton <hdanton@sina.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Michel Lespinasse <michel@lespinasse.org>
Cc: Minchan Kim <minchan@google.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Punit Agrawal <punit.agrawal@bytedance.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 4296c6a817b421061d6e0b9c654c7d4d5a038a5b
https: //git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable)
Bug: 161210518
Change-Id: I3d647ba4d6093f4e3db2c4ff759e5ce59b45b0e1
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Commit ef7dfac51d upstream.
We selectively grab the ctx->uring_lock for poll update/removal, but
we really should grab it from the start to fully synchronize with
linked timeouts. Normally this is indeed the case, but if requests
are forced async by the application, we don't fully cover removal
and timer disarm within the uring_lock.
Make this simpler by having consistent locking state for poll removal.
Bug: 290270326
Cc: stable@vger.kernel.org # 6.1+
Reported-by: Querijn Voet <querijnqyn@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 24f473769e)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I6632b7d78493b0dfc0fb26204d34823045c03f72
This adds passthrough support for flock on fuse-bpf files. It does not
give any control via a bpf filter. The flock will act as though it was
taken on the lower file.
Bug: 289882899
Test: fuse_test -t32 (flock_test)
Change-Id: Iba0b9630766cedbd3195532c5e929891593cfe30
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Presently the data buffer used to return the per-UID timeout description
is created based on information provided by the user. It is expected
that the user populates a variable called 'timeouts_array_size' which is
heavily scrutinised to ensure the value provided is appropriate i.e.
smaller than the largest possible value but large enough to contain all
of the data we wish to pass back.
The issue is that the aforementioned scrutiny is imposed on a different
variable to the one expected. Contrary to expectation, the data buffer
is actually being allocated to the size specified in a variable named
'timeouts_array_size_out'. A variable originally designed to only
contain the output information i.e. the size of the data actually copied
to the user for consumption. This value is also user provided and is
not given the same level of scrutiny as the former.
The fix in this case is simple. Ignore 'timeouts_array_size_out' until
it is time to populate (over-write) it ourselves and use
'timeouts_array_size' to shape the buffer as intended.
Bug: 281547360
Change-Id: I95e12879a33a2355f9e4bc0ce2bfc3f229141aa8
Signed-off-by: Lee Jones <joneslee@google.com>
(cherry picked from commit 5a4d20a3eb4e651f88ed2f1f08cee066639ca801)
[ Upstream commit 504a10d9e4 ]
On corrupt gfs2 file systems the evict code can try to reference the
journal descriptor structure, jdesc, after it has been freed and set to
NULL. The sequence of events is:
init_journal()
...
fail_jindex:
gfs2_jindex_free(sdp); <------frees journals, sets jdesc = NULL
if (gfs2_holder_initialized(&ji_gh))
gfs2_glock_dq_uninit(&ji_gh);
fail:
iput(sdp->sd_jindex); <--references jdesc in evict_linked_inode
evict()
gfs2_evict_inode()
evict_linked_inode()
ret = gfs2_trans_begin(sdp, 0, sdp->sd_jdesc->jd_blocks);
<------references the now freed/zeroed sd_jdesc pointer.
The call to gfs2_trans_begin is done because the truncate_inode_pages
call can cause gfs2 events that require a transaction, such as removing
journaled data (jdata) blocks from the journal.
This patch fixes the problem by adding a check for sdp->sd_jdesc to
function gfs2_evict_inode. In theory, this should only happen to corrupt
gfs2 file systems, when gfs2 detects the problem, reports it, then tries
to evict all the system inodes it has read in up to that point.
Bug: 289870854
Reported-by: Yang Lan <lanyang0908@gmail.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 5ae4a618a1)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I501e8631e1b60479023f5e6ad957540f9e10bcd5
The 'mmu' parameter to enter_vmid_context() represents the target MMU
to switch to, so we should stash away the current MMU for restoration
by exit_vmid_context() rather than the one we're about to switch to!
Bug: 291568386
Fixes: 47318559bc ("ANDROID: KVM: arm64: Support TLB invalidation in guest context")
Tested-by: Mostafa Saleh <smostafa@google.com>
Reported-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I5d76c159424e32a6d70c598d0007f98ea80c1db4
This commit is for adding initial symbol list form ExynosAuto SoCs.
"abi_gki_aarch64_exynosauto" is generated from minimal configs for build.
Bug: 291172090
Signed-off-by: Bumyong Lee <bumyong.lee@samsung.com>
Change-Id: I9114e0ec6881d7d5bdbe61e505e21a379801f69d
If CONFIG_LOCKDEP is enabled, export `sched_domains_mutex` as it is
indirectly accessed by the macro `for_each_domain()`. This allows
vendors to call the `for_each_domain()` macro with CONFIG_LOCKDEP
enabled via the GKI_BUILD_CONFIG_FRAGMENT.
Bug: 176254015
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Change-Id: Ia9f2989de41b2224c63855f2fd129cbeeac4f195
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 7171a5de98)
(cherry picked from commit e2cdae06e2)
1 function symbol(s) added
'bool sk_capable(const struct sock*, int)'
This symbol is needed by bluetooth.ko.
Bug: 290584277
Change-Id: I9d8b42057d263f451caa36b7d176bdf2560cce38
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
As a supplement to commit 6c1c1552e6
("ANDROID: vendor_hook: add hooks to protect locking-tsk in cpu scheduler").
In rwsem read, we missed a lock-holding scenario, add it now.
Bug: 290868674
Change-Id: I718dd942b24b330a79283fc241dcbf47cc34c0c5
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
CONFIG_WWAN=m : WWAN driver core. This driver provides
a common framework for WWAN drivers.
Required to integrate modem devices with WWAN subsystem.
Selects CONFIG_WWAN_DEBUGFS=y; override to disable it
until it is required in the future.
Bug: 287170531
Change-Id: I18517a7aca17cfb5bdbb7ad0399fcb92c575a48e
Signed-off-by: lambert wang <lambert.wang@mediatek.com>
For global registers access, UNISOC have one special method called set/clear
mechanism that would avoid using hardware spinlock. But now regmap framework
does not support our set/clear mechanism, so add vendor hook to support
this feature.
Bug: 228907258
Signed-off-by: Xiaopeng Bai <xiaopeng.bai@unisoc.com>
Change-Id: I9a6651f07a048ffebd5c2d8e369a4e7b374bc182
(cherry picked from commit 53e342c183)
KASAN suppresses reports for bad accesses done by the KASAN reporting
code. The reporting code might access poisoned memory for reporting
purposes.
Software KASAN modes do this by suppressing reports during reporting via
current->kasan_depth, the same way they suppress reports during accesses
to poisoned slab metadata.
Hardware Tag-Based KASAN does not use current->kasan_depth, and instead
resets pointer tags for accesses to poisoned memory done by the reporting
code.
Despite that, a recursive report can still happen:
1. On hardware with faulty MTE support. This was observed by Weizhao
Ouyang on a faulty hardware that caused memory tags to randomly change
from time to time.
2. Theoretically, due to a previous MTE-undetected memory corruption.
A recursive report can happen via:
1. Accessing a pointer with a non-reset tag in the reporting code, e.g.
slab->slab_cache, which is what Weizhao Ouyang observed.
2. Theoretically, via external non-annotated routines, e.g. stackdepot.
To resolve this issue, resetting tags for all of the pointers in the
reporting code and all the used external routines would be impractical.
Instead, disable tag checking done by the CPU for the duration of KASAN
reporting for Hardware Tag-Based KASAN.
Without this fix, Hardware Tag-Based KASAN reporting code might deadlock.
[andreyknvl@google.com: disable preemption instead of migration, fix comment typo]
Link: https://lkml.kernel.org/r/d14417c8bc5eea7589e99381203432f15c0f9138.1680114854.git.andreyknvl@google.com
Link: https://lkml.kernel.org/r/59f433e00f7fa985e8bf9f7caf78574db16b67ab.1678491668.git.andreyknvl@google.com
Fixes: 2e903b9147 ("kasan, arm64: implement HW_TAGS runtime")
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Reported-by: Weizhao Ouyang <ouyangweizhao@zeku.com>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 254721825
(cherry picked from commit c6a690e0c9)
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Change-Id: Ifc5daf66f57dd16e85de73257cc0966565836269
INFO: ABI DIFFERENCES HAVE BEEN DETECTED!
INFO: 1 function symbol(s) added
'void cpufreq_update_policy(unsigned int)'
Bug: 290900322
Change-Id: Idcebf20a17a642e2b08021772a45003797062edd
Signed-off-by: wang qiankun <wangqiankun3@xiaomi.corp-partner.google.com>
Add the symbols needed by kmsg_dump to abi_gki_aarch64_unisoc, and node_states needs to be updated to google
symbols list:
kmsg_dump_get_buffer,
kmsg_dump_rewind,
kmsg_dump_register,
kmsg_dump_unregister.
filp_open_block,
get_zeroed_page,
mem_section,
node_states
Add the symbols needed by native_hang_monitor to abi_gki_aarch64_unisoc
access_process_vm,
down,
find_get_pid,
find_task_by_vpid,
mas_find,
put_pid,
send_sig_info,
up
1 variable symbol(s) added
'nodemask_t node_states[6]'
Bug: 290548918
Change-Id: I18f2c399ca0b6ad01ad9f1a976064d1c14af6577
Signed-off-by: tianming.wang <tianming.wang@unisoc.com>
In qualcomm display drivers, we need to call this function to interface
with the drm drivers. Add it to the symbol list.
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 1 Added
function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added
variable
2 function symbol(s) added
'struct dma_buf* drm_gem_prime_export(struct drm_gem_object*, int)'
'struct drm_plane* drm_plane_from_index(struct drm_device*, int)'
Bug: 289882890
Change-Id: Ie93e84725eb58337f7c96b277a597c96a80b4940
Signed-off-by: Shreyas K K <quic_shrekk@quicinc.com>
Commit 56124d6c87 ("fsverity: support enabling with tree block size <
PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read
the file's data, instead of direct pagecache accesses.
An unintended consequence of this is that the
'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in __kernel_read() became
reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called
on a fd opened with access mode 3, which means "ioctl access only".
Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But
ioctl-only fds are a weird Linux extension that is rarely used and that
few people even know about. (The documentation for FS_IOC_ENABLE_VERITY
even specifically says it requires O_RDONLY.) It's probably not
worthwhile to make the ioctl internally open a new fd just to handle
this case. Thus, just reject the ioctl on such fds for now.
Fixes: 56124d6c87 ("fsverity: support enabling with tree block size < PAGE_SIZE")
Reported-by: syzbot+51177e4144d764827c45@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=2281afcbbfa8fdb92f9887479cc0e4180f1c6b28
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230406215106.235829-1-ebiggers@kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 0483913921)
Change-Id: I3043d7295d59c05f487c05258cb6bb0113357c6e
The new Merkle tree construction algorithm is a bit fragile in that it
may overflow the 'root_hash' array if the tree actually generated does
not match the calculated tree parameters.
This should never happen unless there is a filesystem bug that allows
the file size to change despite deny_write_access(), or a bug in the
Merkle tree logic itself. Regardless, it's fairly easy to check for
buffer overflow here, so let's do so.
This is a robustness improvement only; this case is not currently known
to be reachable. I've added a Fixes tag anyway, since I recommend that
this be included in kernels that have the mentioned commit.
Fixes: 56124d6c87 ("fsverity: support enabling with tree block size < PAGE_SIZE")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230328041505.110162-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 39049b69ec)
Change-Id: I248fd8686a806f0099bed1ac83d52362af3e194e
This reverts commit 21061b7d0f.
Let's use the upstream version.
Bug: 280545073
Bug: 279916414
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: Idcdc94d6bd6b6272535a49c8639517ef1bddb246
[ Upstream commit 2b947f8769 ]
In renesas_usb3_probe, role_work is bound with renesas_usb3_role_work.
renesas_usb3_start will be called to start the work.
If we remove the driver which will call usbhs_remove, there may be
an unfinished work. The possible sequence is as follows:
CPU0 CPU1
renesas_usb3_role_work
renesas_usb3_remove
usb_role_switch_unregister
device_unregister
kfree(sw)
//free usb3->role_sw
usb_role_switch_set_role
//use usb3->role_sw
The usb3->role_sw could be freed under such circumstance and then
used in usb_role_switch_set_role.
This bug was found by static analysis. And note that removing a
driver is a root-only operation, and should never happen in normal
case. But the root user may directly remove the device which
will also trigger the remove function.
Fix it by canceling the work before cleanup in the renesas_usb3_remove.
Bug: 289003615
Fixes: 39facfa01c ("usb: gadget: udc: renesas_usb3: Add register of usb role switch")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20230320062931.505170-1-zyytlz.wz@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit df23805209)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I79a1dbeba9a90ee5daf94648ef6a32207b283561
When reading the arm64's PER_VMA_LOCK support code, I found a bit
difference between arm64 and other arch when calling handle_mm_fault()
during VMA lock-based page fault handling: the fault address is masked
before passing to handle_mm_fault(). This is also different from the
usage in mmap_lock-based handling. I think we need to pass the
original fault address to handle_mm_fault() as we did in
commit 84c5e23ede ("arm64: mm: Pass original fault address to
handle_mm_fault()").
If we go through the code path further, we can find that the "masked"
fault address can cause mismatched fault address between perf sw
major/minor page fault sw event and perf page fault sw event:
do_page_fault
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, ..., addr) // orig addr
handle_mm_fault
mm_account_fault
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, ...) // masked addr
Bug: 254441685
Fixes: cd7f176aea ("arm64/mm: try VMA lock-based page fault handling first")
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230524131305.2808-1-jszhang@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 0e2aba6948)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ie7622f6f7c0e9af5436361de85626e0465cef685
[ Upstream commit 3228cec23b ]
In rkvdec_probe, rkvdec->watchdog_work is bound with
rkvdec_watchdog_func. Then rkvdec_vp9_run may
be called to start the work.
If we remove the module which will call rkvdec_remove
to make cleanup, there may be a unfinished work.
The possible sequence is as follows, which will
cause a typical UAF bug.
Fix it by canceling the work before cleanup in rkvdec_remove.
CPU0 CPU1
|rkvdec_watchdog_func
rkvdec_remove |
rkvdec_v4l2_cleanup|
v4l2_m2m_release |
kfree(m2m_dev); |
|
| v4l2_m2m_get_curr_priv
| m2m_dev->curr_ctx //use
Bug: 289003637
Fixes: cd33c83044 ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 6a17add9c6)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ibdf4667315d98ac1cd42545f61e271c291893edd
In MCQ mode, when a device command uses a hardware queue shared
with other commands, a race condition may occur in the following scenario:
1. A device command is completed in CQx with CQE entry "e".
2. The interrupt handler copies the "cqe" pointer to "hba->dev_cmd.cqe"
and completes "hba->dev_cmd.complete".
3. The "ufshcd_wait_for_dev_cmd()" function is awakened and retrieves
the OCS value from "hba->dev_cmd.cqe".
However, there is a possibility that the CQE entry "e" will be overwritten
by newly completed commands in CQx, resulting in an incorrect OCS value
being received by "ufshcd_wait_for_dev_cmd()".
To avoid this race condition, the OCS value should be immediately copied
to the struct "lrb" of the device command. Then "ufshcd_wait_for_dev_cmd()"
can retrieve the OCS value from the struct "lrb".
Bug: 267974767
Fixes: 57b1c0ef89 ("scsi: ufs: core: mcq: Add support to allocate multiple queues")
Suggested-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Link: https://lore.kernel.org/r/20230610021553.1213-2-powen.kao@mediatek.com
Tested-by: Po-Wen Kao <powen.kao@mediatek.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: I835e435c8a5fffa63b02bd1481f7b41d2a16e706
(cherry picked from commit 0fef6bb730)
[powen: Keep hba->dev_cmd.cqe for KMI freeze]
commit f168420c62 ("blk-mq: don't redirect completion for hctx withs
only one ctx mapping") When nvme applies a 1:1 mapping of hctx and ctx,
there will be no remote request.
But for ufs, the submission and completion queues could be asymmetric.
(e.g. Multiple SQs share one CQ) Therefore, 1:1 mapping of hctx and
ctx won't complete request on the submission cpu. In this situation,
this nr_ctx check could violate the QUEUE_FLAG_SAME_FORCE, as a result,
check on cpu id when there is only one ctx mapping.
Bug: 267974767
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
Signed-off-by: Po-Wen Kao <powen.kao@mediatek.com>
Suggested-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230614002529.6636-1-ed.tsai@mediatek.com
[axboe: fixed up indentation]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 30654614f3)
Change-Id: If2b681b1c5163677b40c06735061406da88adc37
