It is possible for sched_getattr() to incorrectly report the state of
the reset_on_fork flag when called on a deadline task.
Indeed, if the flag was set on a deadline task using sched_setattr()
with flags (SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_KEEP_PARAMS), then
p->sched_reset_on_fork will be set, but __setscheduler() will bail out
early, which means that the dl_se->flags will not get updated by
__setscheduler_params()->__setparam_dl(). Consequently, if
sched_getattr() is then called on the task, __getparam_dl() will
override kattr.sched_flags with the now out-of-date copy in dl_se->flags
and report the stale value to userspace.
To fix this, make sure to only copy the flags that are relevant to
sched_deadline to and from the dl_se->flags field.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210727101103.2729607-2-qperret@google.com
Bug: 190237315
(cherry picked from commit f95091536f
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I251a433e0ddde6b63881f92821bc0d47c1693a02
The UCLAMP_FLAG_IDLE flag is set on a runqueue when dequeueing the last
uclamp active task (that is, when buckets.tasks reaches 0 for all
buckets) to maintain the last uclamp.max and prevent blocked util from
suddenly becoming visible.
However, there is an asymmetry in how the flag is set and cleared which
can lead to having the flag set whilst there are active tasks on the rq.
Specifically, the flag is cleared in the uclamp_rq_inc() path, which is
called at enqueue time, but set in uclamp_rq_dec_id() which is called
both when dequeueing a task _and_ in the update_uclamp_active() path. As
a result, when both uclamp_rq_{dec,ind}_id() are called from
update_uclamp_active(), the flag ends up being set but not cleared,
hence leaving the runqueue in a broken state.
Fix this by clearing the flag in update_uclamp_active() as well.
Fixes: e496187da7 ("sched/uclamp: Enforce last task's UCLAMP_MAX")
Reported-by: Rick Yiu <rickyiu@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Qais Yousef <qais.yousef@arm.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://lore.kernel.org/r/20210805102154.590709-2-qperret@google.com
[ qperret: BACKPORT due to trivial cherry-pick conflict caused by
0213b7083e ("sched/uclamp: Fix uclamp_tg_restrict()") missing
from 5.10. ]
Bug: 192559209
(cherry picked from commit ca4984a7dd
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I7b3418e553ba0f06dd5ef6f0d38a99c3210ae897
Add a new helper function and export it for vendor module to
dynamically switch to an alternative half-life at runtime.
Bug: 195474490
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
Change-Id: Ife41997a032fe3384cfa126cbf7aee929c5c11cf
We noticed that the user interface of Android devices becomes very slow
under memory pressure. This is because Android uses the zram driver on top
of the loop driver for swapping, because under memory pressure the swap
code alternates reads and writes quickly, because mq-deadline is the
default scheduler for loop devices and because mq-deadline delays writes by
five seconds for such a workload with default settings. Fix this by making
the kernel select I/O scheduler 'none' from inside add_disk() for loop
devices. This default can be overridden at any time from user space,
e.g. via a udev rule. This approach has an advantage compared to changing
the I/O scheduler from userspace from 'mq-deadline' into 'none', namely
that synchronize_rcu() does not get called.
Additionally, this patch reduces the Android boot time on my test setup
with 0.5 seconds compared to configuring the loop I/O scheduler from user
space.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Bug: 194450129
(cherry picked from commit 2112f5c133 git://git.kernel.dk/linux-block/ for-5.15/block)
Change-Id: I6f9579b4cd2cb22fcb5c858d4f292f1870336fdd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
elevator_get_default() uses the following algorithm to select an I/O
scheduler from inside add_disk():
- In case of a single hardware queue or sharing hardware queues across
multiple request queues (BLK_MQ_F_TAG_HCTX_SHARED), use mq-deadline.
- Otherwise, use 'none'.
This is a good choice for most but not for all block drivers. Make it
possible to override the selection of mq-deadline with a new flag,
namely BLK_MQ_F_NO_SCHED_BY_DEFAULT.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Bug: 194450129
(cherry picked from commit 90b7198001 git://git.kernel.dk/linux-block/ for-5.15/block)
Change-Id: I4fb658957c193f350e74bdb5876c20a8f628fcb1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
If the device is already in the runtime suspended state, any call to
the pullup routine will issue a runtime resume on the DWC3 core
device. If the USB gadget is disabling the pullup, then avoid having
to issue a runtime resume, as DWC3 gadget has already been
halted/stopped.
This fixes an issue where the following condition occurs:
usb_gadget_remove_driver()
-->usb_gadget_disconnect()
-->dwc3_gadget_pullup(0)
-->pm_runtime_get_sync() -> ret = 0
-->pm_runtime_put() [async]
-->usb_gadget_udc_stop()
-->dwc3_gadget_stop()
-->dwc->gadget_driver = NULL
...
dwc3_suspend_common()
-->dwc3_gadget_suspend()
-->DWC3 halt/stop routine skipped, driver_data == NULL
This leads to a situation where the DWC3 gadget is not properly
stopped, as the runtime resume would have re-enabled EP0 and event
interrupts, and since we avoided the DWC3 gadget suspend, these
resources were never disabled.
Fixes: 77adb8bdf4 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1628058245-30692-1-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cb10f68ad8https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Bug: 195568631
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I98cb28c7cfbc2965aa6e470912e0eb6700a74be9
The list_for_each_entry_safe() macro saves the current item (n) and
the item after (n+1), so that n can be safely removed without
corrupting the list. However, when traversing the list and removing
items using gadget giveback, the DWC3 lock is briefly released,
allowing other routines to execute. There is a situation where, while
items are being removed from the cancelled_list using
dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable
routine is running in parallel (due to UDC unbind). As the cleanup
routine removes n, and the pullup disable removes n+1, once the
cleanup retakes the DWC3 lock, it references a request who was already
removed/handled. With list debug enabled, this leads to a panic.
Ensure all instances of the macro are replaced where gadget giveback
is used.
Example call stack:
Thread#1:
__dwc3_gadget_ep_set_halt() - CLEAR HALT
-> dwc3_gadget_ep_cleanup_cancelled_requests()
->list_for_each_entry_safe()
->dwc3_gadget_giveback(n)
->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]
->spin_unlock
->Thread#2 executes
...
->dwc3_gadget_giveback(n+1)
->Already removed!
Thread#2:
dwc3_gadget_pullup()
->waiting for dwc3 spin_lock
...
->Thread#1 released lock
->dwc3_stop_active_transfers()
->dwc3_remove_requests()
->fetches n+1 item from cancelled_list (n removed by Thread#1)
->dwc3_gadget_giveback()
->dwc3_gadget_del_and_unmap_request()- n+1
deleted[cancelled_list]
->spin_unlock
Fix this condition by utilizing list_replace_init(), and traversing
through a local copy of the current elements in the endpoint lists.
This will also set the parent list as empty, so if another thread is
also looping through the list, it will be empty on the next iteration.
Fixes: d4f1afe5e8 ("usb: dwc3: gadget: move requests to cancelled_list")
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1627543994-20327-1-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d25d85061bhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Bug: 195570448
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0eebb6938d7fac97f6126deda2984387dec1e794
MTE support needs to be optionally disabled in runtime
for HW issue workaround, FW development and some
evaluation works on system resource and performance.
This patch makes two changes:
(1) moves init of tag-allocation bits(ATA/ATA0) to
cpu_enable_mte() as not cached in TLB.
(2) allows ID_AA64PFR1_EL1.MTE to be overridden on
its shadow value by giving "arm64.nomte" on cmdline.
When the feature value is off, ATA and TCF will not set
and the related functionalities are accordingly suppressed.
Change-Id: Ic9cf6d3a12a33b312643d96101c72a657cb714af
Link: https://lore.kernel.org/lkml/20210803070824.7586-2-yee.lee@mediatek.com/
(cherry picked from commit 7a062ce318 git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git next)
Bug: 195507092
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Marc Zyngier <maz@kernel.org>
Suggested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
This patch implements a vendor hook that changes d3hot_delay to use
usleep_range() instead of msleep() to reduce the resume time from 20ms to 10ms.
The call sequence is as follows:
pci_pm_resume_noirq()
pci_pm_default_resume_early()
pci_power_up()
pci_raw_set_power_state() --> msleep(10)
The default d3hot_delay is 10ms. Using msleep for delays less than 20ms could
result in delays up to 20ms.
Reference: Documentation/timers/timers-howto.rst
Using usleep_range() results in the delay being closer to 10ms and this reduces
the resume time.
Bug: 194231641
Change-Id: If3e4dcfb99edad302371273933fa6784854cf892
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
Booting a KVM host in protected mode with kmemleak quickly results
in a pretty bad crash, as kmemleak doesn't know that the HYP sections
have been taken away. This is specially true for the BSS section,
which is part of the kernel BSS section and registered at boot time
by kmemleak itself.
Unregister the HYP part of the BSS before making that section
HYP-private. The rest of the HYP-specific data is obtained via
the page allocator or lives in other sections, none of which is
subjected to kmemleak.
Fixes: 90134ac9ca ("KVM: arm64: Protect the .hyp sections from the host")
Reviewed-by: Quentin Perret <qperret@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org # 5.13
Link: https://lore.kernel.org/r/20210802123830.2195174-3-maz@kernel.org
(cherry picked from commit 47e6223c84 git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next)
Signed-off-by: Marc Zyngier <mzyngier@google.com>
Bug: 194868924
Change-Id: I2881fc146d8a8dd8c9ad9bd9da3a8356968be794
The HYP rodata section is currently lumped together with the BSS,
which isn't exactly what is expected (it gets registered with
kmemleak, for example).
Move it away so that it is actually marked RO. As an added
benefit, it isn't registered with kmemleak anymore.
Fixes: 380e18ade4 ("KVM: arm64: Introduce a BSS section for use at Hyp")
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org #5.13
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210802123830.2195174-2-maz@kernel.org
(cherry picked from commit eb48d154cd git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next)
Signed-off-by: Marc Zyngier <mzyngier@google.com>
Bug: 194868924
Change-Id: I83eb8a573640a37d7272f004d5f1626080395d93
Due to the xhci bugfix, the abi .xml has to be updated as one of the
reserved fields for padding was needed to be used.
Leaf changes summary: 1 artifact changed (1 filtered out)
Changed leaf types summary: 1 (1 filtered out) leaf types 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 xhci_hcd at xhci.h:1753:1' changed:
type size hasn't changed
1 data member insertion:
'union {xhci_vendor_ops* vendor_ops; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide321; union {};}', at offset 59392 (in bits) at xhci.h:1932:1
there are data member changes:
data member u64 android_kabi_reserved1 at offset 59392 (in bits) became anonymous data member 'union {xhci_vendor_ops* vendor_ops; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide315; union {};}'
18 impacted interfaces
Bug: 194461020
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9ed5203273a951d00d7e6bc5db159411c6db0a58
slab-out-of-bounds happens if the xhci platform drivers don't define
the extra_priv_size in their xhci_driver_overrides structure. Move
xhci_vendor_ops structure to xhci main structure to avoid
extra_priv_size affacts xhci_vendor_get_ops which causes the
slab-out-of-bounds error.
Bug: 194461020
Test: build and boot pass
Change-Id: Id17fdfbfd3e8edcc89a05c9c2f553ffab494215e
Signed-off-by: Howard Yen <howardyen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Since commit 1b6b26ae70 ("pipe: fix and clarify pipe write wakeup
logic") we have sanitized the pipe write logic, and would only try to
wake up readers if they needed it.
In particular, if the pipe already had data in it before the write,
there was no point in trying to wake up a reader, since any existing
readers must have been aware of the pre-existing data already. Doing
extraneous wakeups will only cause potential thundering herd problems.
However, it turns out that some Android libraries have misused the EPOLL
interface, and expected "edge triggered" be to "any new write will
trigger it". Even if there was no edge in sight.
Quoting Sandeep Patil:
"The commit 1b6b26ae70 ('pipe: fix and clarify pipe write wakeup
logic') changed pipe write logic to wakeup readers only if the pipe
was empty at the time of write. However, there are libraries that
relied upon the older behavior for notification scheme similar to
what's described in [1]
One such library 'realm-core'[2] is used by numerous Android
applications. The library uses a similar notification mechanism as GNU
Make but it never drains the pipe until it is full. When Android moved
to v5.10 kernel, all applications using this library stopped working.
The library has since been fixed[3] but it will be a while before all
applications incorporate the updated library"
Our regression rule for the kernel is that if applications break from
new behavior, it's a regression, even if it was because the application
did something patently wrong. Also note the original report [4] by
Michal Kerrisk about a test for this epoll behavior - but at that point
we didn't know of any actual broken use case.
So add the extraneous wakeup, to approximate the old behavior.
[ I say "approximate", because the exact old behavior was to do a wakeup
not for each write(), but for each pipe buffer chunk that was filled
in. The behavior introduced by this change is not that - this is just
"every write will cause a wakeup, whether necessary or not", which
seems to be sufficient for the broken library use. ]
It's worth noting that this adds the extraneous wakeup only for the
write side, while the read side still considers the "edge" to be purely
about reading enough from the pipe to allow further writes.
See commit f467a6a664 ("pipe: fix and clarify pipe read wakeup logic")
for the pipe read case, which remains that "only wake up if the pipe was
full, and we read something from it".
Link: https://lore.kernel.org/lkml/CAHk-=wjeG0q1vgzu4iJhW5juPkTsjTYmiqiMUYAebWW+0bam6w@mail.gmail.com/ [1]
Link: https://github.com/realm/realm-core [2]
Link: https://github.com/realm/realm-core/issues/4666 [3]
Link: https://lore.kernel.org/lkml/CAKgNAkjMBGeAwF=2MKK758BhxvW58wYTgYKB2V-gY1PwXxrH+Q@mail.gmail.com/ [4]
Link: https://lore.kernel.org/lkml/20210729222635.2937453-1-sspatil@android.com/
Bug: 193851993
Reported-by: Sandeep Patil <sspatil@android.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3a34b13a88)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Change-Id: Idcf3e8faa31bff47ada4b815237a355e0757b964
Enable CONFIG_USB_EHCI_ROOT_HUB_TT so that EHCI controllers
on i.MX8MM can integrate transaction translators.
Bug: 194108974
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Change-Id: If06b571e1a3a74946953fa48f86545b282b20b4d
This tries to fix priority inversion in the below condition resulting in
long checkpoint delay.
f2fs_get_node_info()
- nat_tree_lock
-> sleep to grab journal_rwsem by contention
checkpoint
- waiting for nat_tree_lock
In order to let checkpoint go, let's release nat_tree_lock, if there's a
journal_rwsem contention.
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 191987855
(cherry picked from commit 2eeb0dce72
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I97ac4f9d3bde399ab4f17f5b3a6e949ae9b79f0f
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Some hardware has a way to restore all keyslots at once that is
significantly faster than restoring each keyslot individually, as is
done by blk_ksm_reprogram_all_keys(). Add a hook
"android_rvh_ufs_reprogram_all_keys" that allows overriding the
restoration of all keyslots after UFS reset. This may sleep, so this
must be a "restricted" Android vendor hook rather than a regular one.
Note that currently this functionality can't be upstreamed, as support
for the hardware that needs it would need to be upstreamed first.
Bug: 162257402
Bug: 181905172
Change-Id: I0b25393a5131941f085892560e08a64e63cd1369
Signed-off-by: Eric Biggers <ebiggers@google.com>
Initial list of rockchip symbols. These are all already included in the
existing list of symbols supported, so no .xml file update is needed at
this time.
Bug: 194515348
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3d31281597bf2e3fb0016629ff75bb304052b1c4
This patch is for updating GKI allowed symbol list without adding any
new symbol. Next patch will introduce newly added symbols for Exynosauto
SoC GKI vendor modules.
Bug: 194547942
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I5f50e0c7b7991953aa40b9555277f6a208629303
Add hook to tcp/udp to collect network info and do performance tuning.
Bug: 190523684
Change-Id: Id790a381d5ce6c35a747697510f14678ccf3ff2f
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
commit '1b6b26ae7053 ("pipe: fix and clarify pipe write wakeup logic")'
change `pipe_write()` wakeup logic to wakeup readers only if the pipe
was empty.
This meant that applications that are not draining the pipe
before each write were exposed to unexpected timeouts / hangs in
epoll_wait() waiting for data in a pipe using EPOLLIN | EPOLLET flags.
This behaviour can be easily tested with android12-5.4 kernel where
the test that uses pipes for notifications in this way works while it
fails 100% with android12-5.10.
This change restores the old behavior to wakeup all pipe_readers if any
new data is written to the pipe.
Bug: 193851993
Bug: 193846582
Change-Id: If0c5a844091ccf16d5236bd072326325d4d5447a
Signed-off-by: Sandeep Patil <sspatil@google.com>
Trying to verify that all of the proper files are being pulled in for
the ABI symbol list is easier if they are in sorted order.
Bug: 193853163
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I663313ea6d61b2ab80b3fd8e29098e694ff4ef00
This reverts commit 52f8b40ff6.
It turns out that the unisoc file was never even hooked up to the gki
symbol build script so this file is doing nothing at all.
I tried to add it, but it breaks the build as it includes a lot of
symbols that are not even part of this kernel tree, so it must have been
created from a different kernel version.
Please resubmit this file properly, and hook it up to the build process
(by adding it to the list in the build.config.gki.aarch64 file.)
Bug: 186088840
Signed-off-by: Jian Gong <jian.gong@unisoc.com>
Fixes: 52f8b40ff6 ("ANDROID: ABI: update symbols to unisoc whitelist for the fifth time")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibdb7d57f0901aa7273c0c29e0a7e0eaf26909e26
Need restricted hook so that it can sleep.
The old non-restricted versions need to stay in place as a consequence
of KMI freeze.
Bug: 194431527
Change-Id: I7093b66f95c3b9c473386ade60d8897426ddbb13
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
No additional symbol is added that is not on any pre-existing symbol
list.
Bug: 194634714
Signed-off-by: Woogeun Lee <woogeun.lee@samsung.com>
Change-Id: I1779540d56c977b8260ad1fc6481fd0a85d383a4
Currently the composite driver encodes the MaxPower field of
the configuration descriptor by reading the c->MaxPower of the
usb_configuration only if it is non-zero, otherwise it falls back
to using the value hard-coded in CONFIG_USB_GADGET_VBUS_DRAW.
However, there are cases when a configuration must explicitly set
bMaxPower to 0, particularly if its bmAttributes also has the
Self-Powered bit set, which is a valid combination.
This is specifically called out in the USB PD specification section
9.1, in which a PDUSB device "shall report zero in the bMaxPower
field after negotiating a mutually agreeable Contract", and also
verified by the USB Type-C Functional Test TD.4.10.2 Sink Power
Precedence Test.
The fix allows the c->MaxPower to be used for encoding the bMaxPower
even if it is 0, if the self-powered bit is also set. An example
usage of this would be for a ConfigFS gadget to be dynamically
updated by userspace when the Type-C connection is determined to be
operating in Power Delivery mode.
Co-developed-by: Ronak Vijay Raheja <rraheja@codeaurora.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Ronak Vijay Raheja <rraheja@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210720080907.30292-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bcacbf06c8https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Bug: 194455199
Change-Id: Ie2d04df6cf3c1c6cdaa9f0872774fd6e5788cade
Signed-off-by: Jack Pham <jackp@codeaurora.org>
SBI_NEED_FSCK is an indicator that fsck.f2fs needs to be triggered, so it
is not fully critical to stop any IO writes. So, let's allow to write data
instead of reporting EIO forever given SBI_NEED_FSCK, but do keep OPU.
Bug: 193659742
Fixes: 9557727876 ("f2fs: drop inplace IO if fs status is abnormal")
Cc: <stable@kernel.org> # v5.13+
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 1ffc8f5f77
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I9585358c1cee864064d9d210ee643f49ff1e6749
Running the following commands on my test setup triggers stack corruption:
cd /sys/devices/platform/14700000.ufs/host0/target0:0:0 &&
for f in $(ls */unit_descriptor/hpb_pinned_region_start_offset | sort); do
grep -aH . $f
done
The above commands trigger stack corruption because these commands
assign the value 37 to the variable 'param_offset' and the value 35 to
'buff_len'. The following code changes param_size from 2 into 254 since
'param_size' has type u8:
if (param_offset + param_size > buff_len)
param_size = buff_len - param_offset;
The next statement triggers stack corruption since 'param_read_buf'
points at a two-byte stack array:
memcpy(param_read_buf, &desc_buf[param_offset], param_size);
With this patch applied, the output of the above command on my test
setup is as follows:
0:0:0:0/unit_descriptor/hpb_pinned_region_start_offset:0x0000
0:0:0:1/unit_descriptor/hpb_pinned_region_start_offset:0x0000
0:0:0:2/unit_descriptor/hpb_pinned_region_start_offset:0x0000
0:0:0:3/unit_descriptor/hpb_pinned_region_start_offset:0x0000
grep: 0:0:0:49456/unit_descriptor/hpb_pinned_region_start_offset: Invalid argument
grep: 0:0:0:49476/unit_descriptor/hpb_pinned_region_start_offset: Invalid argument
grep: 0:0:0:49488/unit_descriptor/hpb_pinned_region_start_offset: Invalid argument
Link: https://lore.kernel.org/linux-scsi/20210719231127.869088-1-bvanassche@acm.org/T/#u
Bug: 194045295
Change-Id: I305c15b20f3ac3d6e3e97592566fcc51058195bb
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit d6eeae59b5.
Reason for revert: the file is in DOS line-ends and the tools are
not picking it up at all. So no .xml file updates were ever done
with this.
Bug: 193853163
Change-Id: I7bfc7a9d2c13015093bbb70c07d3906bdd7b7504
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit ddabf14bea.
The file is in DOS format and no tools pick it up. Because of this
there were additional symbols being added here that were never reflected
in the .xml update.
Bug: 193853163
Cc: Woogeun Lee <woogeun.lee@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I399e8a3509b74524852cb44a59a0f54ef9e6dbb8
This reverts commit 8e6d28165f.
Reason for revert: File has DOS line ends and no tool is picking it
up for the .xml update, so nothing is checking this.
Bug: 194367029
Change-Id: I0d908a709bdb1a76cc018c772376158762695d5b
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
