This patch allows the administrator to configure the interface
name of a function using u_ether (e.g., eem, ncm, rndis).
Currently, all such interfaces, regardless of function type, are
always called usb0, usb1, etc. This makes it very cumbersome to
use more than one such type at a time, because userspace cannnot
easily tell the interfaces apart and apply the right
configuration to each one. Interface renaming in userspace based
on driver doesn't help, because the interfaces all have the same
driver. Without this patch, doing this require hacks/workarounds
such as setting fixed MAC addresses on the functions, and then
renaming by MAC address, or scraping configfs after each
interface is created to find out what it is.
Setting the interface name is done by writing to the same
"ifname" configfs attribute that reports the interface name after
the function is bound. The write must contain an interface
pattern such as "usb%d" (which will cause the net core to pick
the next available interface name starting with "usb").
This patch does not allow writing an exact interface name (as
opposed to a pattern) because if the interface already exists at
bind time, the bind will fail and the whole gadget will fail to
activate. This could be allowed in a future patch.
For compatibility with current userspace, when reading an ifname
that has not currently been set, the result is still "(unnamed
net_device)". Once a write to ifname happens, then reading ifname
will return whatever was last written.
Tested by configuring an rndis function and an ncm function on
the same gadget, and writing "rndis%d" to ifname on the rndis
function and "ncm%d" to ifname on the ncm function. When the
gadget was bound, the rndis interface was rndis0 and the ncm
interface was ncm0.
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
(cherry picked from commit 63d152149b2d0860ccf8c4e6596b6175b2b7ace6
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Link: https://lore.kernel.org/r/20210113234222.3272933-1-lorenzo@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Change-Id: I04deb6cc1d8a5b8ee82404940de2a79c06fbafe7
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Revert the following changes to restore to upstream version:
commit 006d8adf55 ("usb: gadget: f_ncm: allocate/free net device upon driver bind/unbind")
commit ad2d551ece ("usb: gadget: Add check gadget function bind or not")
Reason for revert: Causes gether_set_ifname() support to kernel panic.
Change-Id: I51064467cad63e47a4a9734f18f1a5b95fa8db86
mm/page_owner.c:944:39: error:
size argument in 'strlcpy' call appears to be size of the source;
expected the size of the destination [-Werror,-Wstrlcpy-strlcat-size]
944 | strlcpy(call_site->name, buf, strlen(buf));
| ~~~~~~~^~~~
mm/page_owner.c:944:32: note:
change size argument to be the size of the destination
944 | strlcpy(call_site->name, buf, strlen(buf));
| ^~~~~~~~~~~
| sizeof(call_site->name)
https://github.com/LineageOS/android_kernel_qcom_sm8450/blob/lineage-20/drivers/soc/qcom/minidump_memory.c#L692
contains the same code.
Change-Id: Id06f67fe18f2e00dd180afaf99c7577787198cc3
Signed-off-by: Sevenrock <sevenrock@hotmail.de>
https://source.android.com/docs/security/bulletin/2025-04-01
CVE-2024-50264
CVE-2024-53197
CVE-2024-56556
CVE-2024-53150
* tag 'ASB-2025-04-05_11-5.4' of https://android.googlesource.com/kernel/common:
UPSTREAM: net: sched: Disallow replacing of child qdisc from one parent to another
UPSTREAM: pfifo_tail_enqueue: Drop new packet when sch->limit == 0
UPSTREAM: f2fs: compress: don't allow unaligned truncation on released compress inode
UPSTREAM: net: core: reject skb_copy(_expand) for fraglist GSO skbs
UPSTREAM: udp: prevent local UDP tunnel packets from being GROed
UPSTREAM: udp: do not transition UDP GRO fraglist partial checksums to unnecessary
UPSTREAM: udp: do not accept non-tunnel GSO skbs landing in a tunnel
UPSTREAM: binder: Return EFAULT if we fail BINDER_ENABLE_ONEWAY_SPAM_DETECTION
Change-Id: If91ea6f68126e13b4dfc08471e94ced6d2d68ae9
LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0
# By Jayasri Sampath Kumaran
# Via Karthik Veeranki (1) and Linux Build Service Account (1)
* tag 'clo/display-drivers/LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0':
disp: msm: sde: fix kms NULL pointer access in encoder IRQ control
Change-Id: I52a1f3a27d8eed895e1db8a48f15c225d1c1c3ea
LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0
# Via Linux Build Service Account
* tag 'clo/datarmnet/LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0':
Change-Id: I5a76d0990d5bc7655a0c66fc2f39a02f900cdd43
LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0
# By Ratna Deepthi Kudaravalli
# Via Linux Build Service Account (1) and Ratna Deepthi Kudaravalli (1)
* tag 'clo/audio-kernel/LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0':
audio-kernel: avoid out of bound read while checking a bit
Change-Id: I70a5aa2eb95361d9181d5e93a2bbbcce590ce7db
LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0
# By Krupali Dhanvijay (1) and Ravindra Konda (1)
# Via Linux Build Service Account (1) and Ravindra Konda (1)
* tag 'clo/qcacld-3.0/LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0':
Release 2.0.8.34Z
qcacld-3.0: Update key management in original auth mode for WAPI
Change-Id: Idc372a690bf0f5d77ce26e64c7d5fbc5d6aa95c2
LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0
# By Prashanth K (6) and others
# Via Gerrit - the friendly Code Review server (5) and others
* tag 'clo/msm-5.4/LA.UM.9.14.r1-26000-LAHAINA.QSSI15.0':
FROMGIT: media: venus: hfi: add a check to handle OOB in sfr region
FROMGIT: media: venus: hfi: add check to handle incorrect queue size
FROMGIT: media: venus: hfi_parser: refactor hfi packet parsing logic
FROMGIT: media: venus: hfi_parser: add check to avoid out of bound access
UPSTREAM: usb: dwc3: host: Set XHCI_SG_TRB_CACHE_SIZE_QUIRK
UPSTREAM: usb: host: xhci-plat: Add support for XHCI_SG_TRB_CACHE_SIZE_QUIRK
UPSTREAM: usb: xhci: Add error handling in xhci_map_urb_for_dma
UPSTREAM: usb: xhci: Use temporary buffer to consolidate SG
UPSTREAM: usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK
defconfig: Enable RTL8152 ETH-USB driver
msm: mhi_dev: Breaking memory for event request in smaller chunks
msm: eva: Validating the SFR buffer size before accessing
msm: eva: Copy back the validated size to avoid security issue
Change-Id: Ibd883e18a8a410fb23eb3cda97e88b77c34cdbd7
https://source.android.com/docs/security/bulletin/2025-03-01
CVE-2024-46852
CVE-2024-50302
CVE-2025-22413
# By Greg Kroah-Hartman (7) and others
# Via Greg Kroah-Hartman (3) and Terence Tritton (xWF) (1)
* tag 'ASB-2025-03-05_11-5.4':
ANDROID: ABI: Cuttlefish Symbol update
Revert "net: net_namespace: Optimize the code"
Revert "net: add exit_batch_rtnl() method"
Revert "gtp: use exit_batch_rtnl() method"
Revert "gtp: Use for_each_netdev_rcu() in gtp_genl_dump_pdp()."
Revert "gtp: Destroy device along with udp socket's netns dismantle."
Linux 5.4.290
Partial revert of xhci: use pm_ptr() instead #ifdef for CONFIG_PM conditionals
xhci: use pm_ptr() instead of #ifdef for CONFIG_PM conditionals
drm/v3d: Assign job pointer to NULL before signaling the fence
Input: xpad - add support for wooting two he (arm)
Input: xpad - add unofficial Xbox 360 wireless receiver clone
Input: atkbd - map F23 key to support default copilot shortcut
Revert "usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null"
USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()
ext4: fix slab-use-after-free in ext4_split_extent_at()
ext4: avoid ext4_error()'s caused by ENOMEM in the truncate path
vfio/platform: check the bounds of read/write syscalls
net/xen-netback: prevent UAF in xenvif_flush_hash()
net: xen-netback: hash.c: Use built-in RCU list checking
signal/m68k: Use force_sigsegv(SIGSEGV) in fpsp040_die
m68k: Add missing mmap_read_lock() to sys_cacheflush()
m68k: Update ->thread.esp0 before calling syscall_trace() in ret_from_signal
gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
irqchip/sunxi-nmi: Add missing SKIP_WAKE flag
scsi: iscsi: Fix redundant response for ISCSI_UEVENT_GET_HOST_STATS request
ASoC: wm8994: Add depends on MFD core
net: fix data-races around sk->sk_forward_alloc
scsi: sg: Fix slab-use-after-free read in sg_release()
ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()
hrtimers: Handle CPU state correctly on hotplug
irqchip/gic-v3: Handle CPU_PM_ENTER_FAILED correctly
fs/proc: fix softlockup in __read_vmcore (part 2)
net: ethernet: xgbe: re-add aneg to supported features in PHY quirks
nvmet: propagate npwg topology
poll_wait: add mb() to fix theoretical race between waitqueue_active() and .poll()
kheaders: Ignore silly-rename files
hfs: Sanity check the root record
mac802154: check local interfaces before deleting sdata list
i2c: mux: demux-pinctrl: check initial mux selection, too
drm/v3d: Ensure job pointer is set to NULL after job completion
nfp: bpf: prevent integer overflow in nfp_bpf_event_output()
gtp: Destroy device along with udp socket's netns dismantle.
gtp: Use for_each_netdev_rcu() in gtp_genl_dump_pdp().
gtp: use exit_batch_rtnl() method
net: add exit_batch_rtnl() method
net: net_namespace: Optimize the code
net: ethernet: ti: cpsw_ale: Fix cpsw_ale_get_field()
sctp: sysctl: rto_min/max: avoid using current->nsproxy
ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv
ocfs2: correct return value of ocfs2_local_free_info()
phy: core: Fix that API devm_of_phy_provider_unregister() fails to unregister the phy provider
phy: core: fix code style in devm_of_phy_provider_unregister
arm64: dts: rockchip: add hevc power domain clock to rk3328
arm64: dts: rockchip: add #power-domain-cells to power domain nodes
arm64: dts: rockchip: fix pd_tcpc0 and pd_tcpc1 node position on rk3399
arm64: dts: rockchip: fix defines in pd_vio node for rk3399
iio: inkern: call iio_device_put() only on mapped devices
iio: adc: at91: call input_free_device() on allocated iio_dev
iio: adc: ti-ads124s08: Use gpiod_set_value_cansleep()
iio: gyro: fxas21002c: Fix missing data update in trigger handler
iio: adc: ti-ads8688: fix information leak in triggered buffer
iio: imu: kmx61: fix information leak in triggered buffer
iio: light: vcnl4035: fix information leak in triggered buffer
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
iio: pressure: zpa2326: fix information leak in triggered buffer
usb: gadget: f_fs: Remove WARN_ON in functionfs_bind
usb: fix reference leak in usb_new_device()
USB: core: Disable LPM only for non-suspended ports
USB: usblp: return error when setting unsupported protocol
usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null
USB: serial: cp210x: add Phoenix Contact UPS Device
usb-storage: Add max sectors quirk for Nokia 208
staging: iio: ad9832: Correct phase range check
staging: iio: ad9834: Correct phase range check
USB: serial: option: add Neoway N723-EA support
USB: serial: option: add MeiG Smart SRM815
drm/amd/display: increase MAX_SURFACES to the value supported by hw
ACPI: resource: Add Asus Vivobook X1504VAP to irq1_level_low_skip_override[]
ACPI: resource: Add TongFang GM5HG0A to irq1_edge_low_force_override[]
drm/amd/display: Add check for granularity in dml ceil/floor helpers
sctp: sysctl: auth_enable: avoid using current->nsproxy
sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy
dm thin: make get_first_thin use rcu-safe list first function
tls: Fix tls_sw_sendmsg error handling
net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute
tcp/dccp: allow a connection when sk_max_ack_backlog is zero
tcp/dccp: complete lockless accesses to sk->sk_max_ack_backlog
net: 802: LLC+SNAP OID:PID lookup on start of skb data
ieee802154: ca8210: Add missing check for kfifo_alloc() in ca8210_probe()
dm array: fix cursor index when skipping across block boundaries
dm array: fix unreleased btree blocks on closing a faulty array cursor
dm array: fix releasing a faulty array block twice in dm_array_cursor_end
jbd2: flush filesystem device before updating tail sequence
Change-Id: I83cf20e29c63126cd17dfa393dca0ce7dfa47a76
In util_gen_new_ie, there is a possible out-of-bound read due to a missing
length check for extended IEs in the final pass over the copied
subelements.
Fix is to check tmp_new[1] is not zero.
Change-Id: Ic393d699a208bb54ff645bd8d2424b84becf5543
CRs-Fixed: 3924648
A persistence map is expected to hold refs=2 during its creation.
However, the Fuzzy test can create a persistence map by configuring
a mismatch between attributes and flags using the KEEP MAP attribute
and FD NOMAP flags. This sets the map reference count to 1. The user
then calls fastrpc_internal_munmap_fd to free the map since it
doesn't check flags, which can cause a use-after-free (UAF) for the
file map and shared buffer. Add a check to restrict DMA handle
maps with invalid attributes.
Change-Id: I2f024ef99cc2a0487010504166e3af3433d5302d
Acked-by: Santosh <quic_ssakore@quicinc.com>
Signed-off-by: Abhinav Parihar <quic_parihar@quicinc.com>
[ Upstream commit bc50835e83f60f56e9bec2b392fb5544f250fb6f ]
Lion Ackermann was able to create a UAF which can be abused for privilege
escalation with the following script
Step 1. create root qdisc
tc qdisc add dev lo root handle 1:0 drr
step2. a class for packet aggregation do demonstrate uaf
tc class add dev lo classid 1:1 drr
step3. a class for nesting
tc class add dev lo classid 1:2 drr
step4. a class to graft qdisc to
tc class add dev lo classid 1:3 drr
step5.
tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024
step6.
tc qdisc add dev lo parent 1:2 handle 3:0 drr
step7.
tc class add dev lo classid 3:1 drr
step 8.
tc qdisc add dev lo parent 3:1 handle 4:0 pfifo
step 9. Display the class/qdisc layout
tc class ls dev lo
class drr 1:1 root leaf 2: quantum 64Kb
class drr 1:2 root leaf 3: quantum 64Kb
class drr 3:1 root leaf 4: quantum 64Kb
tc qdisc ls
qdisc drr 1: dev lo root refcnt 2
qdisc plug 2: dev lo parent 1:1
qdisc pfifo 4: dev lo parent 3:1 limit 1000p
qdisc drr 3: dev lo parent 1:2
step10. trigger the bug <=== prevented by this patch
tc qdisc replace dev lo parent 1:3 handle 4:0
step 11. Redisplay again the qdiscs/classes
tc class ls dev lo
class drr 1:1 root leaf 2: quantum 64Kb
class drr 1:2 root leaf 3: quantum 64Kb
class drr 1:3 root leaf 4: quantum 64Kb
class drr 3:1 root leaf 4: quantum 64Kb
tc qdisc ls
qdisc drr 1: dev lo root refcnt 2
qdisc plug 2: dev lo parent 1:1
qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p
qdisc drr 3: dev lo parent 1:2
Observe that a) parent for 4:0 does not change despite the replace request.
There can only be one parent. b) refcount has gone up by two for 4:0 and
c) both class 1:3 and 3:1 are pointing to it.
Step 12. send one packet to plug
echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))
step13. send one packet to the grafted fifo
echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))
step14. lets trigger the uaf
tc class delete dev lo classid 1:3
tc class delete dev lo classid 1:1
The semantics of "replace" is for a del/add _on the same node_ and not
a delete from one node(3:1) and add to another node (1:3) as in step10.
While we could "fix" with a more complex approach there could be
consequences to expectations so the patch takes the preventive approach of
"disallow such config".
Bug: 393266309
Joint work with Lion Ackermann <nnamrec@gmail.com>
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250116013713.900000-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit deda09c0543a66fa51554abc5ffd723d99b191bf)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Id94e8dfb543643e489e33f79af990f23580b9121
sfr->buf_size is in shared memory and can be modified by malicious user.
OOB write is possible when the size is made higher than actual sfr data
buffer. Cap the size to allocated size for such cases.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
CRs-Fixed: 3947576
Change-Id: I483a5feff3dfa35dae8f444e57601d2d1d85246f
Git-commit: f4b211714bcc70effa60c34d9fa613d182e3ef1e
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit 56820042f9)
qsize represents size of shared queued between driver and video
firmware. Firmware can modify this value to an invalid large value. In
such situation, empty_space will be bigger than the space actually
available. Since new_wr_idx is not checked, so the following code will
result in an OOB write.
...
qsize = qhdr->q_size
if (wr_idx >= rd_idx)
empty_space = qsize - (wr_idx - rd_idx)
....
if (new_wr_idx < qsize) {
memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while
reading and writing packets into the queue.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
CRs-Fixed: 3935673
Change-Id: Ifb907d4a4c82f853081492e06e68180476367ed5
Git-commit: 69baf245b23e20efda0079238b27fc63ecf13de1
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit 11f9d2350e)
words_count denotes the number of words in total payload, while data
points to payload of various property within it. When words_count
reaches last word, data can access memory beyond the total payload. This
can lead to OOB access. With this patch, the utility api for handling
individual properties now returns the size of data consumed. Accordingly
remaining bytes are calculated before parsing the payload, thereby
eliminates the OOB access possibilities.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
CRs-Fixed: 3935669
Change-Id: I692e4a8dea110f0650fe26e07207408087a4d19b
Git-commit: 9edaaa8e3e15aab1ca413ab50556de1975bcb329
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit fd9b658c8a)
There is a possibility that init_codecs is invoked multiple times during
manipulated payload from video firmware. In such case, if codecs_count
can get incremented to value more than MAX_CODEC_NUM, there can be OOB
access. Reset the count so that it always starts from beginning.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
CRs-Fixed: 3935643
Change-Id: I6216e773af65082e4775b415789ffd549e0bed2d
Git-commit: 172bf5a9ef70a399bb227809db78442dc01d9e48
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit 91f42e0f9c)
commit 647cef20e649c576dff271e018d5d15d998b629d upstream.
Expected behaviour:
In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a
packet in scheduler's queue and decrease scheduler's qlen by one.
Then, pfifo_tail_enqueue() enqueue new packet and increase
scheduler's qlen by one. Finally, pfifo_tail_enqueue() return
`NET_XMIT_CN` status code.
Weird behaviour:
In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a
scheduler that has no packet, the 'drop a packet' step will do nothing.
This means the scheduler's qlen still has value equal 0.
Then, we continue to enqueue new packet and increase scheduler's qlen by
one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by
one and return `NET_XMIT_CN` status code.
The problem is:
Let's say we have two qdiscs: Qdisc_A and Qdisc_B.
- Qdisc_A's type must have '->graft()' function to create parent/child relationship.
Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.
- Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.
- Qdisc_B is configured to have `sch->limit == 0`.
- Qdisc_A is configured to route the enqueued's packet to Qdisc_B.
Enqueue packet through Qdisc_A will lead to:
- hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)
- Qdisc_B->q.qlen += 1
- pfifo_tail_enqueue() return `NET_XMIT_CN`
- hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.
The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1.
Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem.
This violate the design where parent's qlen should equal to the sum of its childrens'qlen.
Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.
Bug: 395539871
Fixes: 57dbb2d83d ("sched: add head drop fifo queue")
Reported-by: Quang Le <quanglex97@gmail.com>
Signed-off-by: Quang Le <quanglex97@gmail.com>
Signed-off-by: Cong Wang <cong.wang@bytedance.com>
Link: https://patch.msgid.link/20250204005841.223511-2-xiyou.wangcong@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 79a955ea4a2e5ddf4a36328959de0de496419888)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I94a3851190671bc98666cb659e8419ab2767fb03
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
invalid. Return NULL if such an skb is passed to skb_copy or
skb_copy_expand, in order to prevent a crash on a potential later
call to skb_gso_segment.
Bug: 254441685
Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d091e579b864fa790dd6a0cd537a22c383126681)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I0835421359096bd9566a09037d43db84f371dcb1
GRO has a fundamental issue with UDP tunnel packets as it can't detect
those in a foolproof way and GRO could happen before they reach the
tunnel endpoint. Previous commits have fixed issues when UDP tunnel
packets come from a remote host, but if those packets are issued locally
they could run into checksum issues.
If the inner packet has a partial checksum the information will be lost
in the GRO logic, either in udp4/6_gro_complete or in
udp_gro_complete_segment and packets will have an invalid checksum when
leaving the host.
Prevent local UDP tunnel packets from ever being GROed at the outer UDP
level.
Due to skb->encapsulation being wrongly used in some drivers this is
actually only preventing UDP tunnel packets with a partial checksum to
be GROed (see iptunnel_handle_offloads) but those were also the packets
triggering issues so in practice this should be sufficient.
Bug: 254441685
Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 64235eabc4b5b18c507c08a1f16cdac6c5661220)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I1f6d19cfd34e04e395b270e5c286fec06d13fedd
UDP GRO validates checksums and in udp4/6_gro_complete fraglist packets
are converted to CHECKSUM_UNNECESSARY to avoid later checks. However
this is an issue for CHECKSUM_PARTIAL packets as they can be looped in
an egress path and then their partial checksums are not fixed.
Different issues can be observed, from invalid checksum on packets to
traces like:
gen01: hw csum failure
skb len=3008 headroom=160 headlen=1376 tailroom=0
mac=(106,14) net=(120,40) trans=160
shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
csum(0xffff232e ip_summed=2 complete_sw=0 valid=0 level=0)
hash(0x77e3d716 sw=1 l4=1) proto=0x86dd pkttype=0 iif=12
...
Fix this by only converting CHECKSUM_NONE packets to
CHECKSUM_UNNECESSARY by reusing __skb_incr_checksum_unnecessary. All
other checksum types are kept as-is, including CHECKSUM_COMPLETE as
fraglist packets being segmented back would have their skb->csum valid.
Bug: 254441685
Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit f0b8c30345565344df2e33a8417a27503589247d)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I29b8543842f63664e901a217f8636f21ffef504b
When rx-udp-gro-forwarding is enabled UDP packets might be GROed when
being forwarded. If such packets might land in a tunnel this can cause
various issues and udp_gro_receive makes sure this isn't the case by
looking for a matching socket. This is performed in
udp4/6_gro_lookup_skb but only in the current netns. This is an issue
with tunneled packets when the endpoint is in another netns. In such
cases the packets will be GROed at the UDP level, which leads to various
issues later on. The same thing can happen with rx-gro-list.
We saw this with geneve packets being GROed at the UDP level. In such
case gso_size is set; later the packet goes through the geneve rx path,
the geneve header is pulled, the offset are adjusted and frag_list skbs
are not adjusted with regard to geneve. When those skbs hit
skb_fragment, it will misbehave. Different outcomes are possible
depending on what the GROed skbs look like; from corrupted packets to
kernel crashes.
One example is a BUG_ON[1] triggered in skb_segment while processing the
frag_list. Because gso_size is wrong (geneve header was pulled)
skb_segment thinks there is "geneve header size" of data in frag_list,
although it's in fact the next packet. The BUG_ON itself has nothing to
do with the issue. This is only one of the potential issues.
Looking up for a matching socket in udp_gro_receive is fragile: the
lookup could be extended to all netns (not speaking about performances)
but nothing prevents those packets from being modified in between and we
could still not find a matching socket. It's OK to keep the current
logic there as it should cover most cases but we also need to make sure
we handle tunnel packets being GROed too early.
This is done by extending the checks in udp_unexpected_gso: GSO packets
lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must
be segmented.
[1] kernel BUG at net/core/skbuff.c:4408!
RIP: 0010:skb_segment+0xd2a/0xf70
__udp_gso_segment+0xaa/0x560
Bug: 254441685
Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 3d010c8031e39f5fa1e8b13ada77e0321091011f)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I28f2d205ff3fd88ef83f16a6fb92057a6f7a6423
All the other ioctl paths return EFAULT in case the
copy_from_user/copy_to_user call fails, make oneway spam detection
follow the same paradigm.
Bug: 254441685
Fixes: a7dc1e6f99df ("binder: tell userspace to dump current backtrace when detected oneway spamming")
Acked-by: Todd Kjos <tkjos@google.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
Link: https://lore.kernel.org/r/20210506193726.45118-1-luca.stefani.ge1@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ced081a436d21a7d34d4d42acb85058f9cf423f2)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I5f54cc7505300f106c04ac81da33d8046704f377
Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. But the support for this quirk isn't present
in the DWC3 layer.
We will encounter this XHCI timeout/hung issue if we run iperf
loopback tests using RTL8156 ethernet adaptor on DWC3 targets
with scatter-gather enabled. This gets resolved after enabling
the XHCI_SG_TRB_CACHE_SIZE_QUIRK. This patch enables it using
the xhci device property since its needed for DWC3 controller.
In Synopsys DWC3 databook,
Table 9-3: xHCI Debug Capability Limitations
Chained TRBs greater than TRB cache size: The debug capability
driver must not create a multi-TRB TD that describes smaller
than a 1K packet that spreads across 8 or more TRBs on either
the IN TR or the OUT TR.
Change-Id: I51c065d76939b6fc34e80dc970568ba5c9d40567
Cc: stable@vger.kernel.org #5.11
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-2-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. Currently this quirk can only be set using
xhci private data. But there are some drivers like dwc3/host.c
which adds adds quirks using software node for xhci device.
Hence set this xhci quirk by iterating over device properties.
Change-Id: I29c31b05727851fd7c22809febc64589113bc1b9
Cc: stable@vger.kernel.org # 5.11
Fixes: bac1ec551434 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-3-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Currently xhci_map_urb_for_dma() creates a temporary buffer and copies
the SG list to the new linear buffer. But if the kzalloc_node() fails,
then the following sg_pcopy_to_buffer() can lead to crash since it
tries to memcpy to NULL pointer.
So return -ENOMEM if kzalloc returns null pointer.
Change-Id: I5a2d953f8e9b2f2488f5daafdfbc7084db0ceb61
Cc: stable@vger.kernel.org # 5.11
Fixes: 2017a1e58472 ("usb: xhci: Use temporary buffer to consolidate SG")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20240229141438.619372-10-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
The Synopsys xHC has an internal TRB cache of size TRB_CACHE_SIZE for
each endpoint. The default value for TRB_CACHE_SIZE is 16 for SS and 8
for HS. The controller loads and updates the TRB cache from the transfer
ring in system memory whenever the driver issues a start transfer or
update transfer command.
For chained TRBs, the Synopsys xHC requires that the total amount of
bytes for all TRBs loaded in the TRB cache be greater than or equal to 1
MPS. Or the chain ends within the TRB cache (with a last TRB).
If this requirement is not met, the controller will not be able to send
or receive a packet and it will hang causing a driver timeout and error.
This can be a problem if a class driver queues SG requests with many
small-buffer entries. The XHCI driver will create a chained TRB for each
entry which may trigger this issue.
This patch adds logic to the XHCI driver to detect and prevent this from
happening.
For every (TRB_CACHE_SIZE - 2), we check the total buffer size of
the SG list and if the last window of (TRB_CACHE_SIZE - 2) SG list length
and we don't make up at least 1 MPS, we create a temporary buffer to
consolidate full SG list into the buffer.
We check at (TRB_CACHE_SIZE - 2) window because it is possible that there
would be a link and/or event data TRB that take up to 2 of the cache
entries.
We discovered this issue with devices on other platforms but have not
yet come across any device that triggers this on Linux. But it could be
a real problem now or in the future. All it takes is N number of small
chained TRBs. And other instances of the Synopsys IP may have smaller
values for the TRB_CACHE_SIZE which would exacerbate the problem.
Change-Id: I6d34805c32756c48b07be2ffa9aad72ab5af2bbe
Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201208092912.1773650-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
This commit uses the private data passed by parent device
to set the quirk for Synopsys xHC. This patch fixes the
SNPS xHC hang issue when the data is scattered across
small buffers which does not make atleast MPS size for
given TRB cache size of SNPS xHC.
Change-Id: I1eb96096cfb7500b5ef4eb866170642bff0b2133
Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201208092912.1773650-2-mathias.nyman@linux.intel.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Enable RTL815x Ethernet dongle support for sdxlemur.
Change-Id: Ida1265bd8642af0b9211dea5cf6330d8487274b0
Signed-off-by: Prashanth K <quic_prashk@quicinc.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: c49dd3401802 ("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 97113eb39fa7972722ff490b947d8af023e1f6a2)
[Kalesh Singh: Resolve some trivial conflicts in mm/mremap.c]
Bug: 151772539
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I5b7235e982ea2efdc155018271fbaf2711fac4c1
HAVE_MOVE_PUD enables remapping pages at the PUD level if both the
source and destination addresses are PUD-aligned.
With HAVE_MOVE_PUD enabled it can be inferred that there is
approximately a 13x improvement in performance on x86. (See data
below).
------- Test Results ---------
The following results were obtained using a 5.4 kernel, by remapping
a PUD-aligned, 1GB sized region to a PUD-aligned destination.
The results from 10 iterations of the test are given below:
Total mremap times for 1GB data on x86. All times are in nanoseconds.
Control HAVE_MOVE_PUD
180394 15089
235728 14056
238931 25741
187330 13838
241742 14187
177925 14778
182758 14728
160872 14418
205813 15107
245722 13998
205721.5 15594 <-- Mean time in nanoseconds
A 1GB mremap completion time drops from ~205 microseconds
to ~15 microseconds on x86. (~13x speed up).
Link: https://lkml.kernel.org/r/20201014005320.2233162-6-kaleshsingh@google.com
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Gavin Shan <gshan@redhat.com>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: Jia He <justin.he@arm.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Lokesh Gidra <lokeshgidra@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Minchan Kim <minchan@google.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: SeongJae Park <sjpark@amazon.de>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit be37c98d1134a8e068b52618c086dab6b34b9a2c)
Bug: 151772539
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I7967951289885157ef3a487a6935abe3b860847f
HAVE_MOVE_PUD enables remapping pages at the PUD level if both the source
and destination addresses are PUD-aligned.
With HAVE_MOVE_PUD enabled it can be inferred that there is approximately
a 19x improvement in performance on arm64. (See data below).
------- Test Results ---------
The following results were obtained using a 5.4 kernel, by remapping a
PUD-aligned, 1GB sized region to a PUD-aligned destination. The results
from 10 iterations of the test are given below:
Total mremap times for 1GB data on arm64. All times are in nanoseconds.
Control HAVE_MOVE_PUD
1247761 74271
1219896 46771
1094792 59687
1227760 48385
1043698 76666
1101771 50365
1159896 52500
1143594 75261
1025833 61354
1078125 48697
1134312.6 59395.7 <-- Mean time in nanoseconds
A 1GB mremap completion time drops from ~1.1 milliseconds to ~59
microseconds on arm64. (~19x speed up).
Link: https://lkml.kernel.org/r/20201014005320.2233162-5-kaleshsingh@google.com
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Gavin Shan <gshan@redhat.com>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jia He <justin.he@arm.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Lokesh Gidra <lokeshgidra@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Minchan Kim <minchan@google.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: SeongJae Park <sjpark@amazon.de>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit f5308c896d5de211245a9dc73b4e530f75185dd5)
Bug: 151772539
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I30590b7375dde84fe345f4920a06f6a2c0b5aa31
Android needs to move large memory regions for garbage collection. The GC
requires moving physical pages of multi-gigabyte heap using mremap.
During this move, the application threads have to be paused for
correctness. It is critical to keep this pause as short as possible to
avoid jitters during user interaction.
Optimize mremap for >= 1GB-sized regions by moving at the PUD/PGD level if
the source and destination addresses are PUD-aligned. For
CONFIG_PGTABLE_LEVELS == 3, moving at the PUD level in effect moves PGD
entries, since the PUD entry is “folded back” onto the PGD entry. Add
HAVE_MOVE_PUD so that architectures where moving at the PUD level isn't
supported/tested can turn this off by not selecting the config.
Link: https://lkml.kernel.org/r/20201014005320.2233162-4-kaleshsingh@google.com
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Gavin Shan <gshan@redhat.com>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jia He <justin.he@arm.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Lokesh Gidra <lokeshgidra@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Minchan Kim <minchan@google.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: SeongJae Park <sjpark@amazon.de>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit c49dd340180260c6239e453263a9a244da9a7c85)
[Kalesh Singh: Resolve conflicts in mm/mremap.c]
Bug: 151772539
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: Ia9b065f5059044815fd05f22bad33c484b2b2b73
HAVE_MOVE_PMD enables remapping pages at the PMD level if both the
source and destination addresses are PMD-aligned.
HAVE_MOVE_PMD is already enabled on x86. The original patch [1] that
introduced this config did not enable it on arm64 at the time because
of performance issues with flushing the TLB on every PMD move. These
issues have since been addressed in more recent releases with
improvements to the arm64 TLB invalidation and core mmu_gather code as
Will Deacon mentioned in [2].
>From the data below, it can be inferred that there is approximately
8x improvement in performance when HAVE_MOVE_PMD is enabled on arm64.
--------- Test Results ----------
The following results were obtained on an arm64 device running a 5.4
kernel, by remapping a PMD-aligned, 1GB sized region to a PMD-aligned
destination. The results from 10 iterations of the test are given below.
All times are in nanoseconds.
Control HAVE_MOVE_PMD
9220833 1247761
9002552 1219896
9254115 1094792
8725885 1227760
9308646 1043698
9001667 1101771
8793385 1159896
8774636 1143594
9553125 1025833
9374010 1078125
9100885.4 1134312.6 <-- Mean Time in nanoseconds
Total mremap time for a 1GB sized PMD-aligned region drops from
~9.1 milliseconds to ~1.1 milliseconds. (~8x speedup).
[1] https://lore.kernel.org/r/20181108181201.88826-3-joelaf@google.com
[2] https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg140837.html
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lore.kernel.org/r/20201014005320.2233162-3-kaleshsingh@google.com
Link: https://lore.kernel.org/kvmarm/20181029102840.GC13965@arm.com/
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 45544eee96065cf183fbb937fe1f45a172b06f4e)
Bug: 151772539
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: If0d97276cf8de1a5893e97444f2d961db05abea5
