The binder_update_page_range() function performs both allocation and
freeing of binder pages. However, these two operations are unrelated and
have no common logic. In fact, when a free operation is requested, the
allocation logic is skipped entirely. This behavior makes the error path
unnecessarily complex. To improve readability of the code, this patch
splits the allocation and freeing operations into separate functions.
No functional changes are introduced by this patch.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-11-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit 0d35bf3bf2da8d43fd12fea7699dc936999bf96e)
Change-Id: Iaf64f94564d2017c4633f2421c15b0bdee914738
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The vma addresses in binder are currently stored as void __user *. This
requires casting back and forth between the mm/ api which uses unsigned
long. Since we also do internal arithmetic on these addresses we end up
having to cast them _again_ to an integer type.
Lets stop all the unnecessary casting which kills code readability and
store the virtual addresses as the native unsigned long from mm/. Note
that this approach is preferred over uintptr_t as Linus explains in [1].
Opportunistically add a few cosmetic touchups.
Link: https://lore.kernel.org/all/CAHk-=wj2OHy-5e+srG1fy+ZU00TmZ1NFp6kFLbVLMXHe7A1d-g@mail.gmail.com/ [1]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-10-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit df9aabead791d7a3d59938abe288720f5c1367f7)
Change-Id: Ib2fbaf0ad881973eb77957863f079f986fe0d926
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The kernel coding style does not require 'extern' in function prototypes
in .h files, so remove them from drivers/android/binder_alloc.h as they
are not needed.
No functional changes in this patch.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20231201172212.1813387-9-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 254650075
(cherry picked from commit da483f8b390546fbe36abd72f58d612a8032e2a8)
Change-Id: I75e4ee9cf08fada7378f448bc5992d125174132f
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit 17fff41db8.
The alloc->mutex to spinlock_t patches from [1] are being backported
into this branch. The vendor hooks will be reapplied on top of these
backports in a way that matches the new structure of the code.
Link: https://lore.kernel.org/all/20231201172212.1813387-1-cmllamas@google.com/ [1]
Change-Id: Ic1acdd3401f985614d2d7383bdaabd6d71bb0c44
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit 7ce117301e.
The alloc->mutex to spinlock_t patches from [1] are being backported
into this branch. The vendor hooks will be reapplied on top of these
backports in a way that matches the new structure of the code.
Link: https://lore.kernel.org/all/20231201172212.1813387-1-cmllamas@google.com/ [1]
Change-Id: I7f4aaab31b4462a40881c596abdcbef835a32e4a
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit db91c5d31a.
The alloc->mutex to spinlock_t patches from [1] are being backported
into this branch. The vendor hooks will be reapplied on top of these
backports in a way that matches the new structure of the code.
Link: https://lore.kernel.org/all/20231201172212.1813387-1-cmllamas@google.com/ [1]
Change-Id: I39dd50bb58a08f39942322ee014dd08ebbd83168
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[ Upstream commit 076361362122a6d8a4c45f172ced5576b2d4a50d ]
The struct adjtimex freq field takes a signed value who's units are in
shifted (<<16) parts-per-million.
Unfortunately for negative adjustments, the straightforward use of:
freq = ppm << 16 trips undefined behavior warnings with clang:
valid-adjtimex.c:66:6: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
-499<<16,
~~~~^
valid-adjtimex.c:67:6: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
-450<<16,
~~~~^
..
Fix it by using a multiply by (1 << 16) instead of shifting negative values
in the valid-adjtimex test case. Align the values for better readability.
Bug: 339526723
Reported-by: Lee Jones <joneslee@google.com>
Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Change-Id: Ied611c13a802acf9c7a2427f0a61eb358b571a3d
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Link: https://lore.kernel.org/r/20240409202222.2830476-1-jstultz@google.com
Link: https://lore.kernel.org/lkml/0c6d4f0d-2064-4444-986b-1d1ed782135f@collabora.com/
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 1f3484dec9)
Signed-off-by: Edward Liaw <edliaw@google.com>
If UNUSED_KSYMS_WHITELIST is a file generated
before Kbuild runs, and the source tree is in
a read-only filesystem, the developer must put
the file somewhere and specify an absolute
path to UNUSED_KSYMS_WHITELIST. This worked,
but if IKCONFIG=y, an absolute path is embedded
into .config and eventually into vmlinux, causing
the build to be less reproducible when building
on a different machine.
This patch makes the handling of
UNUSED_KSYMS_WHITELIST to be similar to
MODULE_SIG_KEY.
First, check if UNUSED_KSYMS_WHITELIST is an
absolute path, just as before this patch. If so,
use the path as is.
If it is a relative path, use wildcard to check
the existence of the file below objtree first.
If it does not exist, fall back to the original
behavior of adding $(srctree)/ before the value.
After this patch, the developer can put the generated
file in objtree, then use a relative path against
objtree in .config, eradicating any absolute paths
that may be evaluated differently on different machines.
Signed-off-by: Yifan Hong <elsk@google.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
(cherry picked from commit a2e3c811938b4902725e259c03b2d6c539613992
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next)
Bug: 333769605
Change-Id: I0696ac8f686329795034ada5a4587af4ecbb774f
[elsk: apply change to gen_autoksyms.sh instead because
CONFIG_UNUSED_KSYMS_WHITELIST is parsed there. Revert change
to Makefile.modpost.]
Bug: 342390208
Signed-off-by: Yifan Hong <elsk@google.com>
Build environments might be running with different umask settings
resulting in indeterministic file modes for the files contained in
kheaders.tar.xz. The file itself is served with 444, i.e. world
readable. Archive the files explicitly with 744,a+X to improve
reproducibility across build environments.
--mode=0444 is not suitable as directories need to be executable. Also,
444 makes it hard to delete all the readonly files after extraction.
Cc: <stable@vger.kernel.org>
Cc: <linux-kbuild@vger.kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.org>
Link: https://lore.kernel.org/r/20240528113243.827490-2-maennich@google.com
Bug: 342094847
Bug: 342393806
Change-Id: Ib206a6e0abfacf8132bfad8c43a62982062175fa
Signed-off-by: Matthias Maennich <maennich@google.com>
Versions of pahole from 1.22 support multi-threaded operation with
separate CUs being processed independently. This results in
non-deterministic and effectively non-reproducible output for kernel
objects. Later versions of pahole aim to support determinism by
retiring CUs in order.
We regain determinism by restricting parallelism to 1 at the cost of
some performance.
The default parallelism of `pahole -J` is the number of online
processors * 1.1. Experiments on a workstation with 36 cores reveal
that performance is actually worse for `vmlinux` at `-j` (8.9s) than
at `-j3` (7.8s) and the optimum is around `-j9` (4.9s). No parallelism
is slowest (18.8s), but still acceptable for GKI.
Bug: 342094847
Change-Id: Ibd72ac638faa1826f6655b336cc7001591ea70f1
Signed-off-by: Giuliano Procida <gprocida@google.com>
epoll can call out to vfs_poll() with a file pointer that may race with
the last 'fput()'. That would make f_count go down to zero, and while
the ep->mtx locking means that the resulting file pointer tear-down will
be blocked until the poll returns, it means that f_count is already
dead, and any use of it won't actually get a reference to the file any
more: it's dead regardless.
Make sure we have a valid ref on the file pointer before we call down to
vfs_poll() from the epoll routines.
Bug: 341834298
Change-Id: Iefa13cd84102ded3e104c030c8d7d0b7a8c1eab2
Link: https://lore.kernel.org/lkml/0000000000002d631f0615918f1e@google.com/
Reported-by: syzbot+045b454ab35fd82a35fb@syzkaller.appspotmail.com
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4efaa5acf0a1d2b5947f98abb3acf8bfd966422b)
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.corp-partner.google.com>
While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX
set to 65536, it has been observed that we receive short packets,
which come at interval of 5-10 seconds sometimes and have block
length zero but still contain 1-2 valid datagrams present.
According to the NCM spec:
"If wBlockLength = 0x0000, the block is terminated by a
short packet. In this case, the USB transfer must still
be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If
exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,
and the size is a multiple of wMaxPacketSize for the
given pipe, then no ZLP shall be sent.
wBlockLength= 0x0000 must be used with extreme care, because
of the possibility that the host and device may get out of
sync, and because of test issues.
wBlockLength = 0x0000 allows the sender to reduce latency by
starting to send a very large NTB, and then shortening it when
the sender discovers that there’s not sufficient data to justify
sending a large NTB"
However, there is a potential issue with the current implementation,
as it checks for the occurrence of multiple NTBs in a single
giveback by verifying if the leftover bytes to be processed is zero
or not. If the block length reads zero, we would process the same
NTB infintely because the leftover bytes is never zero and it leads
to a crash. Fix this by bailing out if block length reads zero.
Cc: stable@vger.kernel.org
Fixes: 427694cfaa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call")
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Link: https://lore.kernel.org/r/20240228115441.2105585-1-quic_kriskura@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master)
Bug: 320608613
Change-Id: I4b60d855f5539e66261e71dc2a29c7d22712e382
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
(cherry picked from commit b493b35d3a52a47d92607a03c257fcb71fcc2ef9)
It is observed sometimes when tethering is used over NCM with Windows 11
as host, at some instances, the gadget_giveback has one byte appended at
the end of a proper NTB. When the NTB is parsed, unwrap call looks for
any leftover bytes in SKB provided by u_ether and if there are any pending
bytes, it treats them as a separate NTB and parses it. But in case the
second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
were parsed properly in the first NTB and saved in rx_list are dropped.
Adding a few custom traces showed the following:
[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:
req 000000003868811a length 1025/16384 zsI ==> 0
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
[002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
In this case, the giveback is of 1025 bytes and block length is 1024.
The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
all datagrams in rx_list.
Same is case with packets of size 2048:
[002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:
req 0000000011dfd96e length 2049/16384 zsI ==> 0
[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
Lecroy shows one byte coming in extra confirming that the byte is coming
in from PC:
Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)
- Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
--- Packet 4063861
Data(1024 bytes)
Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
--- Packet 4063863
Data(1 byte)
Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
because the non-zero wBlockLength has already told the function side the
size of transfer to be expected. However, there are in-market NCM devices
that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
To deal with such devices, it pads an extra 0 at end so the transfer is no
longer multiple of wMaxPacketSize.
Cc: <stable@vger.kernel.org>
Fixes: 9f6ce4240a ("usb: gadget: f_ncm.c added")
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Link: https://lore.kernel.org/r/20240205074650.200304-1-quic_kriskura@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 76c51146820c5dac629f21deafab0a7039bc3ccd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master)
Bug: 320608613
Change-Id: Iee598bcbede12582235fca38a0c9f50f3b7375c5
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
(cherry picked from commit c344c3ebe3fead1ed0c12bd686be083748011342)
For fair tasks inheriting the priority (nice) without reweighting is
a NOP as the task's share won't change.
This is visible when running with PTHREAD_PRIO_INHERIT where fair tasks
with low priority values are susceptible to starvation leading to PI
like impact on lock contention.
The logic in rt_mutex will reset these low priority fair tasks into nice
0, but without the additional reweight operation to actually update the
weights, it doesn't have the desired impact of boosting them to allow
them to run sooner/longer to release the lock.
Apply the reweight for fair_policy() tasks to achieve the desired boost
for those low nice values tasks. Note that boost here means resetting
their nice to 0; as this is what the current logic does for fair tasks.
We need to re-instate ordering fair tasks by their priority order on the
waiter tree to ensure we inherit the top_waiter properly.
Handling of idle_policy() requires more code refactoring and is not
handled yet. idle_policy() are treated specially and only run when the
CPU is idle and get a hardcoded low weight value. Changing weights won't
be enough without a promotion first to SCHED_OTHER.
Tested with a test program that creates three threads.
1. main thread that spawns high prio and low prio task and busy
loops
2. low priority thread that holds a pthread_mutex() with
PTHREAD_PRIO_INHERIT protocol. Runs at nice +10. Busy loops
after holding the lock.
3. high priority thread that holds a pthread_mutex() with
PTHREADPTHREAD_PRIO_INHERIT, but made to start after the low
priority thread. Runs at nice 0. Should remain blocked by the
low priority thread.
All tasks are pinned to CPU0.
Without the patch I can see the low priority thread running only for
~10% of the time which is what expected without it being boosted.
With the patch the low priority thread runs for ~50% which is what
expected if it gets boosted to nice 0.
I modified the test program logic afterwards to ensure that after
releasing the lock the low priority thread goes back to running for 10%
of the time, and it does.
Bug: 263876335
Link: https://lore.kernel.org/lkml/20240514160711.hpdg64grdwc43ux7@airbuntu/
Reported-by: Yabin Cui <yabinc@google.com>
Signed-off-by: Qais Yousef <qyousef@layalina.io>
[Fix trivial conflict with vendor hook]
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: Ia954ee528495b5cf5c3a2157c68b4a757cef1f83
(cherry picked from commit 23ac35ed8fc6220e4e498a21d22a9dbe67e7da9b)
Signed-off-by: Qais Yousef <qyousef@google.com>
This patch add a restricted vendor hook in do_read_fault() for tracking
which file and offsets are faulted.
Bug: 336736235
Change-Id: I425690e58550c4ac44912daa10b5eac0728bfb4e
Signed-off-by: liangjlee <liangjlee@google.com>
The commit 893597cbab ("r8152: add USB device driver for
config selection"), uses usb register/degister symbols.
Add them to the symbol list.
usb_deregister_device_driver
usb_register_device_driver
Bug: 341211984
Change-Id: Ifcf37d5630891c5963123af09843b00395f9eff6
Signed-off-by: Srinivasarao Pathipati <quic_c_spathi@quicinc.com>
Add vendor hooks to reclaim MADV_PAGEOUT memory for asynchrnous
device. It also exports reclaim_pages to reclaim memory.
Bug: 326662423
Change-Id: Ic2516c64a9dbd53173a3bfb19b6cd21636916c27
Signed-off-by: Minchan Kim <minchan@google.com>
Currently all controller IP/revisions except DWC3_usb3 >= 310a
wait 1ms unconditionally for ENDXFER completion when IOC is not
set. This is because DWC_usb3 controller revisions >= 3.10a
supports GUCTL2[14: Rst_actbitlater] bit which allows polling
CMDACT bit to know whether ENDXFER command is completed.
Consider a case where an IN request was queued, and parallelly
soft_disconnect was called (due to ffs_epfile_release). This
eventually calls stop_active_transfer with IOC cleared, hence
send_gadget_ep_cmd() skips waiting for CMDACT cleared during
EndXfer. For DWC3 controllers with revisions >= 310a, we don't
forcefully wait for 1ms either, and we proceed by unmapping the
requests. If ENDXFER didn't complete by this time, it leads to
SMMU faults since the controller would still be accessing those
requests.
Fix this by ensuring ENDXFER completion by adding 1ms delay in
__dwc3_stop_active_transfer() unconditionally.
Cc: stable@vger.kernel.org
Fixes: b353eb6dc2 ("usb: dwc3: gadget: Skip waiting for CMDACT cleared during endxfer")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20240502044103.1066350-1-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 340415457
(cherry picked from commit 1d26ba0944d398f88aaf997bda3544646cf21945
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-next)
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Change-Id: I0d3792d620ecd380f2a0a80ae5137c25d1adac4d
1 function symbol(s) added
'int __traceiter_android_vh_tune_fault_around_bytes(unsigned long *)'
1 variable symbol(s) added
'struct tracepoint __tracepoint_android_vh_tune_fault_around_bytes'
with this vendor_hook, oem can dynamically adjust fault_around_bytes to
balance memory usage and performance
Bug: 340749845
Change-Id: I0ec6c5cc0b021dd7e7854dbe13f13c3f6b488b64
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
with this vendor_hook, oem can dynamically adjust fault_around_bytes to
balance memory usage and performance
Bug: 340749845
Change-Id: I429f4302caf44a769696ccec84e9cc13ea8892ea
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
The data transfer rate using Google Restore in USB3.2 mode is slower,
only about 140MB/s at 5Gbps.
The bMaxBurst is not set, and num_fifos in
dwc3_gadget_resize_tx_fifosis 1, which results
in only 131btye of dwc3 ram space being allocated to ep.
Modify bMaxBurst to 6.
The 5Gbps rate increases from 140MB/s to 350MB/s.
The 10Gbps rate is increased from 220MB/s to 500MB/s.
Bug: 340049583
Change-Id: I5710af32c72d0b57afaecc00c4f0909af4b9a299
Signed-off-by: Lianqin Hu <hulianqin@vivo.corp-partner.google.com>
Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Long ago with android-mainline, kernel/sched/android.h was added
to include stub functions for out-of-tree logic that we wanted
to remove from android-mainline without breaking vendor drivers
that relied on these stubs.
Unfortunately, when the android release branches (android14-6.1
and android15-6.6) forked from android-mainline, the stubs were
kept.
In some cases, the functionality dropped was re-added to the
release branches, but using new function names. Drivers that
continued to use the old names, would then end up using the stub
impelementations, likely without noticing.
Lets try to clean this up by removing the stub header.
This should not affect the GKI KABI, and pre-existing modules
should continue to work, but when modules are re-build, they
may run into build issues and will need tweaks to remove the
old stub functions.
Bug: 332588830
Change-Id: I516913f2e4c36e6edbffb3c12b633a158ba04287
Signed-off-by: John Stultz <jstultz@google.com>
export function for sysfs node formating
Bug: 299190787
Change-Id: I71e6a0815efa8df99d036bf457b8a0081999f3de
Signed-off-by: Robin Hsu <robinhsu@google.com>
The value is only available in debugfs. Export it to allow out of tree
modules to modify it.
Bug: 337139487
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I4b3a5aeeee0539b88756aacc97df6181f68d9d0d
This commit uses the ack() callback to determine when a buffer has been
updated, then exposes it to guest.
The current mechanism splits a dma buffer into descriptors that are
exposed to the device. This dma buffer is shared with the user
application. When the device consumes a buffer, the driver moves the
request from the used ring to available ring.
The driver exposes the buffer to the device without knowing if the
content has been updated from the user. The section 2.8.21.1 of the
virtio spec states that: "The device MAY access the descriptor chains
the driver created and the memory they refer to immediately". If the
device picks up buffers from the available ring just after it is
notified, it happens that the content may be old.
When the ack() callback is invoked, the driver exposes only the buffers
that have already been updated, i.e., enqueued in the available ring.
Thus, the device always picks up a buffer that is updated.
For capturing, the driver starts by exposing all the available buffers
to device. After device updates the content of a buffer, it enqueues it
in the used ring. It is only after the ack() for capturing is issued
that the driver re-enqueues the buffer in the available ring.
Co-developed-by: Anton Yakovlev <anton.yakovlev@opensynergy.com>
Signed-off-by: Anton Yakovlev <anton.yakovlev@opensynergy.com>
Signed-off-by: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
Link: https://lore.kernel.org/r/ZTjkn1YAFz67yfqx@fedora
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Bug: 331600622
Change-Id: If1269f1777432256eea0e0275b678d0d649753bb
(cherry picked from commit fe981e67568c41de6caae25d70b5f203b94452cc)
Signed-off-by: Brian Daniels <briandaniels@google.com>
When a Fast Role Swap control message attempt results in a transition
to ERROR_RECOVERY, the TCPC can still queue a TCPM_SOURCING_VBUS event.
If the event is queued but processed after the tcpm_reset_port() call
in the PORT_RESET state, then the following occurs:
1. tcpm_reset_port() calls tcpm_init_vbus() to reset the vbus sourcing and
sinking state
2. tcpm_pd_event_handler() turns VBUS on before the port is in the default
state.
3. The port resolves as a sink. In the SNK_DISCOVERY state,
tcpm_set_charge() cannot set vbus to charge.
Clear pd events within PORT_RESET to get rid of non-applicable events.
Fixes: b17dd57118 ("staging: typec: tcpm: Improve role swap with non PD capable partners")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240423202715.3375827-2-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 311127232
(cherry picked from commit bf20c69cf3cf9c6445c4925dd9a8a6ca1b78bfdf)
Change-Id: I9b27d040d0acdeb2af74fd3fe90d246b864b5141
Signed-off-by: RD Babiera <rdbabiera@google.com>
Before sending Enter Mode for an Alt Mode, there is a gap between Discover
Modes and the Alt Mode driver queueing the Enter Mode VDM for the port
partner to send a message to the port.
If this message results in unregistering Alt Modes such as in a DR_SWAP,
then the following deadlock can occur with respect to the DisplayPort Alt
Mode driver:
1. The DR_SWAP state holds port->lock. Unregistering the Alt Mode driver
results in a cancel_work_sync() that waits for the current dp_altmode_work
to finish.
2. dp_altmode_work makes a call to tcpm_altmode_enter. The deadlock occurs
because tcpm_queue_vdm_unlock attempts to hold port->lock.
Before attempting to grab the lock, ensure that the port is in a state
vdm_run_state_machine can run in. Alt Mode unregistration will not occur
in these states.
Fixes: 03eafcfb60 ("usb: typec: tcpm: Add tcpm_queue_vdm_unlocked() helper")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240423202356.3372314-2-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 333787869
(cherry picked from commit cdc9946ea6377e8e214b135ccc308c5e514ba25f)
[rd: removed SRC_VDM_IDENTITY_REQUEST check, state not defined in branch]
Change-Id: I8018d1fdc294885ae609b6e45e9bf6ab190897b9
Signed-off-by: RD Babiera <rdbabiera@google.com>
curve25519-x86_64.c fails to build when CONFIG_GCOV_KERNEL is enabled.
The error is "inline assembly requires more registers than available"
thrown from the `fsqr()` function. Therefore, excluding this file from
GCOV profiling until this issue is resolved. Thereby allowing
CONFIG_GCOV_PROFILE_ALL to be enabled for x86.
Change-Id: Icbb1ed0e1b99f1cb0a21ea7a2920b3edce70c38d
Signed-off-by: Joe Fradley <joefradley@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit c390c452eb)
[ Upstream commit 3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc ]
Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern. Quoting Pablo:
add_elem("00000000") timeout 100 ms
...
add_elem("0000000X") timeout 100 ms
del_elem("0000000X") <---------------- delete one that was just added
...
add_elem("00005000") timeout 100 ms
1) nft_pipapo_remove() removes element 0000000X
Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one
element that share the same key.
This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.
The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).
Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.
v2: avoid uneeded temporary variable (Stefano)
Bug: 336735501
Fixes: 3c4287f620 ("nf_tables: Add set type for arbitrary concatenation of ranges")
Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit ebf7c9746f)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ic9a48ac9ac0f9960fea9e066d9a0a9fb93f7b633
commit 8590541473188741055d27b955db0777569438e3 upstream.
Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our
requests to the crypto API, crypto_aead_{encrypt,decrypt} can return
-EBUSY instead of -EINPROGRESS in valid situations. For example, when
the cryptd queue for AESNI is full (easy to trigger with an
artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued
to the backlog but still processed. In that case, the async callback
will also be called twice: first with err == -EINPROGRESS, which it
seems we can just ignore, then with err == 0.
Compared to Sabrina's original patch this version uses the new
tls_*crypt_async_wait() helpers and converts the EBUSY to
EINPROGRESS to avoid having to modify all the error handling
paths. The handling is identical.
Bug: 326215202
Fixes: a54667f672 ("tls: Add support for encryption using async offload accelerator")
Fixes: 94524d8fc9 ("net/tls: Add support for async decryption of tls records")
Co-developed-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Srish: v2: fixed hunk failures
fixed merge-conflict in stable branch linux-6.1.y,
needs to go on top of https://lore.kernel.org/stable/20240307155930.913525-1-lee@kernel.org/]
Signed-off-by: Srish Srinivasan <srish.srinivasan@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cd1bbca03f)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I6aedd018e89a9aa2ace6633e02308336ed19fe13
If the kernel is built CONFIG_CFI_CLANG=y, reading smaps
may cause a panic. This is due to a failed CFI check; which
is triggered becuase the signature of the function pointer for
printing smaps padding VMAs does not match exactly with that
for show_smap().
Fix this by casting the function pointer to the expected type
based on whether printing maps or smaps padding.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I65564a547dacbc4131f8557344c8c96e51f90cd5
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
In some cases a VMA with padding representation may be split, and
therefore the padding flags must be updated accordingly.
There are 3 cases to handle:
Given:
| DDDDPPPP |
where:
- D represents 1 page of data;
- P represents 1 page of padding;
- | represents the boundaries (start/end) of the VMA
1) Split exactly at the padding boundary
| DDDDPPPP | --> | DDDD | PPPP |
- Remove padding flags from the first VMA.
- The second VMA is all padding
2) Split within the padding area
| DDDDPPPP | --> | DDDDPP | PP |
- Subtract the length of the second VMA from the first VMA's
padding.
- The second VMA is all padding, adjust its padding length (flags)
3) Split within the data area
| DDDDPPPP | --> | DD | DDPPPP |
- Remove padding flags from the first VMA.
- The second VMA is has the same padding as from before the split.
To simplify the semantics merging of padding VMAs is not allowed.
If a split produces a VMA that is entirely padding, show_[s]maps()
only outputs the padding VMA entry (as the data entry is of length 0).
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: Ie2628ced5512e2c7f8af25fabae1f38730c8bb1a
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Some file systems like F2FS use a custom filemap_fault ops. Remove this
check, as checking vm_file is sufficient.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: Id6a584d934f06650c0a95afd1823669fc77ba2c2
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Only preform padding advise from the execution context on bionic's
dynamic linker. This ensures that madvise() doesn't have unwanted
side effects.
Also rearrange the order of fail checks in madvise_vma_pad_pages()
in order of ascending cost.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I3e05b8780c6eda78007f86b613f8c11dd18ac28f
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Userspace apps often analyze memory consumption by the use of mm
rss_stat counters -- via the kmem/rss_stat trace event or from
/proc/<pid>/statm.
rss_stat counters are only updated when the PTEs are updated. What this
means is that pages can be present in the page cache from readahead but
not visible to userspace (not attributed to the app) as there is no
corresponding VMA (PTEs) for the respective page cache pages.
A side effect of the loader now extending ELF LOAD segments to be
contiguously mapped in the virtual address space, means that the VMA is
extended to cover the padding pages.
When filesystems, such as f2fs and ext4, that implement
vm_ops->map_pages() attempt to perform a do_fault_around() the extent of
the fault around is restricted by the area of the enclosing VMA. Since
the loader extends LOAD segment VMAs to be contiguously mapped, the extent
of the fault around is also increased. The result of which, is that the
PTEs corresponding to the padding pages are updated and reflected in the
rss_stat counters.
It is not common that userspace application developers be aware of this
nuance in the kernel's memory accounting. To avoid apparent regressions
in memory usage to userspace, restrict the fault around range to only
valid data pages (i.e. exclude the padding pages at the end of the VMA).
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I2c7a39ec1b040be2b9fb47801f95042f5dbf869d
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
When performing LOAD segment extension, the dynamic linker knows what
portion of the VMA is padding. In order for the kernel to implement
mitigations that ensure app compatibility, the extent of the padding
must be made available to the kernel.
To achieve this, reuse MADV_DONTNEED on single VMAs to hint the padding
range to the kernel. This information is then stored in vm_flag bits.
This allows userspace (dynamic linker) to set the padding pages on the
VMA without a need for new out-of-tree UAPI.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I3421de32ab38ad3cb0fbce73ecbd8f7314287cde
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
The dynamic linker may extend ELF LOAD segment mappings to be contiguous
in memory when loading a 16kB compatible ELF on a 4kB page-size system.
This is done to reduce the use of unreclaimable VMA slab memory for the
otherwise necessary "gap" VMAs. The extended portion of the mapping
(VMA) can be viewed as "padding", meaning that the mapping in that range
corresponds to an area of the file that does not contain contents of the
respective segments (maybe zero's depending on how the ELF is built).
For some compatibility mitigations, the region of a VMA corresponding to
these padding sections need to be known.
In order to represent such regions without adding addtional overhead or
breaking ABI, some upper bits of vm_flags are used.
Add the VMA padding pages representation and the necessary APIs to
manipulate it.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: Ieb9fa98e30ec9b0bec62256624f14e3ed6062a75
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Migrating from 4kB to 16kB page-size in Android requires first making
the platform page-agnostic, which involves increasing Android-ELFs'
max-page-size (p_align) from 4kB to 16kB.
Increasing the ELF max-page-size was found to cause compatibility issues
in apps that use obfuscation or depend on the ELF segments being mapped
based on 4kB-alignment.
Working around these compatibility issues involves both kernel and
userspace (dynamic linker) changes.
Introduce a knob for userspace (dynamic linker) to determine whether the
kernel supports the mitigations needed for page-size migration compatibility.
The knob also allows for userspace to turn on or off these mitigations
by writing 1 or 0 to /sys/kernel/mm/pgsize_miration/enabled:
echo 1 > /sys/kernel/mm//pgsize_miration/enabled # Enable
echo 0 > /sys/kernel/mm//pgsize_miration/enabled # Disable
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I9ac1d15d397b8226b27827ecffa30502da91e10e
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
