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>
An authoritative Dr. No reviewers list has been created in
android-mainline. Rather use this list for enforcement to avoid
duplication.
Bug: 194314089
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Iab1e4bd427b500295158cef390ce10612b3f6d72
should_proactive_compact_node() returns true when sum of the weighted
fragmentation score of all the zones in the node is greater than the
wmark_high of compaction, which then triggers the proactive compaction
that operates on the individual zones of the node. But proactive
compaction runs on the zone only when its weighted fragmentation score
is greater than wmark_low(=wmark_high - 10).
This means that the sum of the weighted fragmentation scores of all the
zones can exceed the wmark_high but individual weighted fragmentation zone
scores can still be less than wmark_low which makes the unnecessary
trigger of the proactive compaction only to return doing nothing.
Issue with the return of proactive compaction with out even trying is its
deferral. It is simply deferred for 1 << COMPACT_MAX_DEFER_SHIFT if the
scores across the proactive compaction is same, thinking that compaction
didn't make any progress but in reality it didn't even try. With the
delay between successive retries for proactive compaction is 500msec, it
can result into the deferral for ~30sec with out even trying the proactive
compaction.
Test scenario is that: compaction_proactiveness=50 thus the wmark_low = 50
and wmark_high = 60. System have 2 zones(Normal and Movable) with sizes
5GB and 6GB respectively. After opening some apps on the android, the
weighted fragmentation scores of these zones are 47 and 49 respectively.
Since the sum of these fragmentation scores are above the wmark_high which
triggers the proactive compaction and there since the individual zones
weighted fragmentation scores are below wmark_low, it returns without
trying the proactive compaction. As a result the weighted fragmentation
scores of the zones are still 47 and 49 which makes the existing logic to
defer the compaction thinking that noprogress is made across the
compaction.
Fix this by checking just zone fragmentation score, not the weighted, in
__compact_finished() and use the zones weighted fragmentation score in
fragmentation_score_node(). In the test case above, If the weighted
average of is above wmark_high, then individual score (not adjusted) of
atleast one zone has to be above wmark_high. Thus it avoids the
unnecessary trigger and deferrals of the proactive compaction.
Link: https://lkml.kernel.org/r/1610989938-31374-1-git-send-email-charante@codeaurora.org
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Nitin Gupta <ngupta@nitingupta.dev>
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 40d7e20320)
Bug: 194263998
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I814b350368f2183f064ab71030e075dd7bea901b
This effectively locks down OWNERS approval to a small group to guard
the code base against unintentional breakages.
Bug: 194314089
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Ifd1ea97639a622320ea83f901f6451e2e52b38d4
The vendor hook functions we implemented will invoke callback functions which have do some sleep or spinlock
operations and have risk of deadlock due to preemption disabled of normal vendor hook function.
So we have to use restricted vendor hook function instead.
Due to KMI freeze we could not change the existing hooks.
trace_android_rvh_media_device_setup_link =>invoke setup_link, link_notify callback
trace_android_rvh_v4l2subdev_set_xxx =>invoke set_xxx callback
Bug: 193870284
Signed-off-by: Louis Kuo <louis.kuo@mediatek.com>
Change-Id: I94fe2e112b6c3d9ac5177abb30a99b7007068f7e
The commit 529a1101212a("mfd: syscon: Don't free allocated name
for regmap_config") doesn't free the allocated name field of struct
regmap_config, but introduce a memory leak. There is another
commit 94cc89eb8fa5("regmap: debugfs: Fix handling of name string
for debugfs init delays") fixing this debugfs init issue from root
cause. With this fixing, the name field in struct regmap_debugfs_node
is removed. When initialize debugfs for syscon driver, the name
field of struct regmap_config is not used anymore. So, the allocated
name field of struct regmap_config is need to be freed directly after
regmap initialization to avoid memory leak.
Cc: stable@vger.kernel.org
Fixes: 529a1101212a("mfd: syscon: Don't free allocated name for regmap_config")
Signed-off-by: Meng Li <Meng.Li@windriver.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/patchwork/patch/1408873/
Bug: 193747648
Signed-off-by: Allen Chiu <allen.chiu@mediatek.com>
Change-Id: Iadc628aae889f306afb6eefbf66fdd9143a91278
(cherry picked from commit 56a1188159)
Current UIC cmd timeout (500ms) is too short, UIC cmd completion may
frequently time out when CPUs are shortly hogged by other subsystems.
Change UIC cmd timeout to 5s.
Bug: 193844987
Change-Id: Ia3db5fb4d9a49967e54a9d44676d884f77572831
Signed-off-by: Can Guo <cang@codeaurora.org>
security_secid_to_secctx() can fail because of a GFP_ATOMIC allocation
This needs to be retried from userspace. However, binder driver doesn't
propagate specific enough error codes just yet (WIP b/28321379). We'll
retry on the binder driver as a temporary work around until userspace
can do this instead.
Bug: 174806915
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: Ifebddeb7adf9707613512952b97ab702f0d2d592
My commit "integrate page_alloc init with HW_TAGS" changed the order of
kernel_unpoison_pages() and kernel_init_free_pages() calls. This leads
to complaints from the page unpoisoning code, as the poison pattern gets
overwritten for __GFP_ZERO allocations.
Fix by restoring the initial order. Also add a warning comment.
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Sergei Trofimovich <slyfox@gentoo.org>
The fix was included in upstream patch 1bb5eab30d 'kasan, mm: integrate page_alloc init with HW_TAGS'
Fixes: a15989497e ("FROMGIT: kasan, mm: integrate page_alloc init with HW_TAGS")
Bug: 192912968
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ifc4ab7ed27b3c060f70ba5ca03117a36c9b4da08
__get_vm_area_caller(), map_kernel_range still be needed by a vendor
for their sub-system architecture that need to be improved.
Avoid using these symbols, becuase once the vendor improves
sub-system structure they will be unexported.
Bug: 181049185
Change-Id: I84d7c66351cc6d10798bc3a66f8325a90cec4324
Signed-off-by: Jeongtae Park <jtp.park@samsung.com>
Allocation requests outside ZONE_NORMAL (MOVABLE, HIGHMEM or DMA) cannot
be fulfilled by KFENCE, because KFENCE memory pool is located in a
zone different from the requested one.
Because callers of kmem_cache_alloc() may actually rely on the
allocation to reside in the requested zone (e.g. memory allocations done
with __GFP_DMA must be DMAable), skip all allocations done with
GFP_ZONEMASK and/or respective SLAB flags (SLAB_CACHE_DMA and
SLAB_CACHE_DMA32).
Fixes: 0ce20dd840 ("mm: add Kernel Electric-Fence infrastructure")
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Souptick Joarder <jrdr.linux@gmail.com>
Cc: stable@vger.kernel.org # 5.12+
Signed-off-by: Alexander Potapenko <glider@google.com>
Reviewed-by: Marco Elver <elver@google.com>
Acked-by: Souptick Joarder <jrdr.linux@gmail.com>
Bug: 192294212
Test: ran KFENCE test suite with __GFP_DMA on QEMU
Link: https://lore.kernel.org/linux-mm/20210714092222.1890268-2-glider@google.com/
Change-Id: I72d2e24185e213d0ce60155d5a78f29bca8c88cc
Signed-off-by: Alexander Potapenko <glider@google.com>
