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>
Added gc_reclaimed_segments and gc_segment_mode sysfs nodes.
1) "gc_reclaimed_segments" shows how many segments have been
reclaimed by GC during a specific GC mode.
2) "gc_segment_mode" is used to control for which gc mode
the "gc_reclaimed_segments" node shows.
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 182708936
(cherry picked from commit 07c6b5933e
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: Ie8c2ccf5d36ce2f388c98b77e22848f3ff6645c3
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Allow vendors to obtain a list of modules loaded at given time. Vendor
modules are able to register on part of notifier chain
(register_module_notifer), but a vendor module would never see modules
which are loaded before the one which registers on the notifier chain.
The kernel doesn't offer load order control, so a hook is necessary to
iterate through currently loaded kernel modules.
Bug: 193552324
Change-Id: I3b01cc1b90f8c0c7c21a37992cc7d607316efc7b
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Since commit c5089591c3ba ("block, bfq: detect wakers and
unconditionally inject their I/O"), when the in-service bfq_queue, say
Q, is temporarily empty, BFQ checks whether there are I/O requests to
inject (also) from the waker bfq_queue for Q. To this goal, the value
pointed by bfqq->waker_bfqq->next_rq must be controlled. However, the
current implementation mistakenly looks at bfqq->next_rq, which
instead points to the next request of the currently served queue.
This mistake evidently causes losses of throughput in scenarios with
waker bfq_queues.
This commit corrects this mistake.
Fixes: c5089591c3ba ("block, bfq: detect wakers and unconditionally inject their I/O")
Signed-off-by: Jia Cheng Hu <jia.jiachenghu@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Bug: 193744965
Change-Id: I2b31773e1f67e4828e33a32acfa29b59809be7e0
(cherry picked from commit d4fc3640ff)
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
To avoid a race between rmap walk and mremap, mremap does
take_rmap_locks(). The lock was taken to ensure that rmap walk don't miss
a page table entry due to PTE moves via move_pagetables(). The kernel
does further optimization of this lock such that if we are going to find
the newly added vma after the old vma, the rmap lock is not taken. This
is because rmap walk would find the vmas in the same order and if we don't
find the page table attached to older vma we would find it with the new
vma which we would iterate later.
As explained in commit eb66ae0308 ("mremap: properly flush TLB before
releasing the page") mremap is special in that it doesn't take ownership
of the page. The optimized version for PUD/PMD aligned mremap also
doesn't hold the ptl lock. This can result in stale TLB entries as show
below.
This patch updates the rmap locking requirement in mremap to handle the race condition
explained below with optimized mremap::
Optmized PMD move
CPU 1 CPU 2 CPU 3
mremap(old_addr, new_addr) page_shrinker/try_to_unmap_one
mmap_write_lock_killable()
addr = old_addr
lock(pte_ptl)
lock(pmd_ptl)
pmd = *old_pmd
pmd_clear(old_pmd)
flush_tlb_range(old_addr)
*new_pmd = pmd
*new_addr = 10; and fills
TLB with new addr
and old pfn
unlock(pmd_ptl)
ptep_clear_flush()
old pfn is free.
Stale TLB entry
Optimized PUD move also suffers from a similar race. Both the above race
condition can be fixed if we force mremap path to take rmap lock.
Link: https://lkml.kernel.org/r/20210616045239.370802-7-aneesh.kumar@linux.ibm.com
Fixes: 2c91bd4a4e ("mm: speed up mremap by 20x on large regions")
Fixes: c49dd34018 ("mm: speedup mremap on 1GB or larger regions")
Link: https://lore.kernel.org/linux-mm/CAHk-=wgXVR04eBNtxQfevontWnP6FDm+oj5vauQXP3S-huwbPw@mail.gmail.com
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Acked-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Kalesh Singh <kaleshsingh@google.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 97113eb39f)
Bug: 151772539
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I5b7235e982ea2efdc155018271fbaf2711fac4c1
Some of the platforms might be still expecting dedicated memory region
for ramoops node. So add logic to detect the start and size of the
ramoops memory region by looking up reserved memory region with
of_reserved_mem_lookup() when platform_get_resource() failed.
Bug: 191636717
Change-Id: Idc479b45fb3f637f7235efd6eabac62059d5e92b
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Vendor hook is add in the commit:
https://android-review.googlesource.com/c/kernel/common/+/1687592
When we register the vendor hook and build, there is build error:
too long symbol "__tracepoint_android_vh_binder_transaction_priority_skip"
So, I shorten the function name
android_vh_binder_transaction_priority_skip -->
android_vh_binder_priority_skip
Bug: 186482511
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I27f39dd32436b09257bcf6e746f4ccdfbd6d6cfe
