Try to mitigate potential future driver core api changes by adding a
pointer to struct signal_struct, struct sched_entity, struct
sched_rt_entity, and struct task_struct.
Based on a patch from Michal Marek <mmarek@suse.cz> from the SLES kernel
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 3 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct sched_entity at sched.h:444:1' changed:
type size changed from 3584 to 4096 (in bits)
4 data member insertions:
'u64 sched_entity::android_kabi_reserved1', at offset 3584 (in bits) at sched.h:481:1
'u64 sched_entity::android_kabi_reserved2', at offset 3648 (in bits) at sched.h:482:1
'u64 sched_entity::android_kabi_reserved3', at offset 3712 (in bits) at sched.h:483:1
'u64 sched_entity::android_kabi_reserved4', at offset 3776 (in bits) at sched.h:484:1
1435 impacted interfaces:
'struct sched_rt_entity at sched.h:481:1' changed:
type size changed from 384 to 640 (in bits)
4 data member insertions:
'u64 sched_rt_entity::android_kabi_reserved1', at offset 384 (in bits) at sched.h:504:1
'u64 sched_rt_entity::android_kabi_reserved2', at offset 448 (in bits) at sched.h:505:1
'u64 sched_rt_entity::android_kabi_reserved3', at offset 512 (in bits) at sched.h:506:1
'u64 sched_rt_entity::android_kabi_reserved4', at offset 576 (in bits) at sched.h:507:1
1435 impacted interfaces:
'struct task_struct at sched.h:624:1' changed:
type size changed from 28672 to 30208 (in bits)
8 data member insertions:
'u64 task_struct::android_kabi_reserved1', at offset 20992 (in bits) at sched.h:1294:1
'u64 task_struct::android_kabi_reserved2', at offset 21056 (in bits) at sched.h:1295:1
'u64 task_struct::android_kabi_reserved3', at offset 21120 (in bits) at sched.h:1296:1
'u64 task_struct::android_kabi_reserved4', at offset 21184 (in bits) at sched.h:1297:1
'u64 task_struct::android_kabi_reserved5', at offset 21248 (in bits) at sched.h:1298:1
'u64 task_struct::android_kabi_reserved6', at offset 21312 (in bits) at sched.h:1299:1
'u64 task_struct::android_kabi_reserved7', at offset 21376 (in bits) at sched.h:1300:1
'u64 task_struct::android_kabi_reserved8', at offset 21440 (in bits) at sched.h:1301:1
there are data member changes:
1435 impacted interfaces:
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1449735b836399e9b356608727092334daf5c36b
Try to mitigate potential future driver core api changes by adding a
padding to struct module.
Based on a patch from Michal Marek <mmarek@suse.cz> from the SLES kernel
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct module at module.h:348:1' changed:
type size hasn't changed
4 data member insertions:
'u64 module::android_kabi_reserved1', at offset 6720 (in bits) at module.h:518:1
'u64 module::android_kabi_reserved2', at offset 6784 (in bits) at module.h:519:1
'u64 module::android_kabi_reserved3', at offset 6848 (in bits) at module.h:520:1
'u64 module::android_kabi_reserved4', at offset 6912 (in bits) at module.h:521:1
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2a764e9eac88f20e50d192112235da6d2f0f83bc
Try to mitigate potential future driver core api changes by adding a
padding to struct sock.
Based on a patch from Michal Marek <mmarek@suse.cz> from the SLES kernel
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct sock at sock.h:324:1' changed:
type size changed from 6016 to 6528 (in bits)
8 data member insertions:
'u64 sock::android_kabi_reserved1', at offset 6016 (in bits) at sock.h:516:1
'u64 sock::android_kabi_reserved2', at offset 6080 (in bits) at sock.h:517:1
'u64 sock::android_kabi_reserved3', at offset 6144 (in bits) at sock.h:518:1
'u64 sock::android_kabi_reserved4', at offset 6208 (in bits) at sock.h:519:1
'u64 sock::android_kabi_reserved5', at offset 6272 (in bits) at sock.h:520:1
'u64 sock::android_kabi_reserved6', at offset 6336 (in bits) at sock.h:521:1
'u64 sock::android_kabi_reserved7', at offset 6400 (in bits) at sock.h:522:1
'u64 sock::android_kabi_reserved8', at offset 6464 (in bits) at sock.h:523:1
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I61c3d6cf12c087345db71fc6d93ee6bd58969003
Try to mitigate potential future driver core api changes by adding
padding to a number of core internal scheduler structures.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0ef2f8dd5f3259dcf443c5045aa1e8505ed78a76
Try to mitigate potential future driver core api changes by adding a
padding to struct vfsmount.
Based on a patch from Michal Marek <mmarek@suse.cz> from the SLES kernel
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct vfsmount at mount.h:68:1' changed:
type size changed from 256 to 512 (in bits)
4 data member insertions:
'u64 vfsmount::android_kabi_reserved1', at offset 192 (in bits) at mount.h:73:1
'u64 vfsmount::android_kabi_reserved2', at offset 256 (in bits) at mount.h:74:1
'u64 vfsmount::android_kabi_reserved3', at offset 320 (in bits) at mount.h:75:1
'u64 vfsmount::android_kabi_reserved4', at offset 384 (in bits) at mount.h:76:1
there are data member changes:
'void* vfsmount::data' offset changed from 192 to 448 (in bits) (by +256 bits)
8 impacted interfaces:
function vfsmount* mntget(vfsmount*)
function int notify_change2(vfsmount*, dentry*, iattr*, inode**)
function int vfs_create2(vfsmount*, inode*, dentry*, umode_t, bool)
function int vfs_mkdir2(vfsmount*, inode*, dentry*, umode_t)
function int vfs_path_lookup(dentry*, vfsmount*, const char*, unsigned int, path*)
function int vfs_rename2(vfsmount*, inode*, dentry*, inode*, dentry*, inode**, unsigned int)
function int vfs_rmdir2(vfsmount*, inode*, dentry*)
function int vfs_unlink2(vfsmount*, inode*, dentry*, inode**)
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9ce1b63f05c90af168eeea1312ac88d3cc5cfdf3
Try to mitigate potential future driver core api changes by adding a
padding to stuct vm_area_struct and struct zone.
Based on a patch from Michal Marek <mmarek@suse.cz> from the SLES kernel
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 3 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct vm_area_struct at mm_types.h:292:1' changed:
type size changed from 1472 to 1728 (in bits)
4 data member insertions:
'u64 vm_area_struct::android_kabi_reserved1', at offset 1472 (in bits) at mm_types.h:365:1
'u64 vm_area_struct::android_kabi_reserved2', at offset 1536 (in bits) at mm_types.h:366:1
'u64 vm_area_struct::android_kabi_reserved3', at offset 1600 (in bits) at mm_types.h:367:1
'u64 vm_area_struct::android_kabi_reserved4', at offset 1664 (in bits) at mm_types.h:368:1
1435 impacted interfaces:
'struct zone at mmzone.h:420:1' changed:
type size changed from 12800 to 13312 (in bits)
4 data member insertions:
'u64 zone::android_kabi_reserved1', at offset 12672 (in bits) at mmzone.h:569:1
'u64 zone::android_kabi_reserved2', at offset 12736 (in bits) at mmzone.h:570:1
'u64 zone::android_kabi_reserved3', at offset 12800 (in bits) at mmzone.h:571:1
'u64 zone::android_kabi_reserved4', at offset 12864 (in bits) at mmzone.h:572:1
624 impacted interfaces:
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I81702aa833f419928e0e32e9609722b98592c171
These structures are fundamental to implementing fw_devlink and
sync_state(). Since they are still evolving, add some padding in case we
need to backport any important bug fixes.
struct device_link
struct class
struct fwnode_handle
struct fwnode_link
Bug: 183615740
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id9daf7cf9ae5d94fb0134144f8220a241ccbaef8
HID structures were not being tracked as a "stable" symbol in the past,
but that looks to change with some future abi requirements. So add
needed padding now, to ensure that we can support this over the
long-term.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8c3064fb7a19006a29dabbaf25c9ed1737f62e75
Given that the xhci driver seems to be one of the more "modified" by
vendors, and that the xhci core is going to be built into the kernel in
the GKI 2 Android kernel, the xhci "platform" api is now a stable
boundry.
Try to handle any future changes in this api by adding some kabi padding
fields to allow for room to grow and change over the next 5+ years as
needed.
Bug: 151154716
Bug: 182336717
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I55c8cad8c8c51330fc2d72df41a1f04229a22e98
Try to mitigate potential future driver core api changes by adding
padding to a number of dwc3 structures.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1826d885e3acf1f378d0e30b1ca2ddc56b16a9e4
There seems to be lots of people wanting to change this structure, and
while it feels internal, due to some SoC patches, there's an ABI that
needs to be preserved here over time.
So add some padding to struct snd_usb_endpoint so that we can maintain
this succesfully in the future.
Of course, now that the padding is there, there never will be any need
to change this structure again...
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I21cb3abbdca2961e33a94b2bc48b49f3fadbd206
Try to mitigate potential future driver core api changes by adding a
padding to struct user_namespace.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2c41281b191cd252db2ddc792699d869ce8d7a4d
Try to mitigate potential future driver core api changes by adding a
padding to struct quota_format_ops, struct dquot_operations, and struct
quotactl_ops.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia957d2f8d9b1a6939cddedc16a7481e9de1a8866
Try to mitigate potential future driver core api changes by adding a
padding to struct mmu_notifier_ops and struct mmu_notifier.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If631445abf20c22830a1c764ff2ccd662a7bd204
Try to mitigate potential future driver core api changes by adding a
padding to struct vm_operations_struct.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I78f84148ef4d3524bd6c5b78e53e06503a4ac3ae
Try to mitigate potential future driver core api changes by adding a
padding to struct kobject, struct kobj_type, and struct kset.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3c28826dc314c7f1b5c9bb167be82089d53768bb
Try to mitigate potential future driver core api changes by adding a
padding to struct kernfs_syscall_ops and struct kernfs_ops.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1fcb0b81c3ea7d5300da283b275391f95d6d4ec8
Try to mitigate potential future driver core api changes by adding a
padding to struct irq_domain.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8ff0c2162ca5f7f0b6c7a51bf341c6b1b1c856e8
Try to mitigate potential future driver core api changes by adding a
padding to struct resource.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5ff4401c540be7d095f1db27370281b7220af030
Try to mitigate potential future driver core api changes by adding a
padding to struct iomap_ops.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1803d5163f7a1d0320f567b983a8241777284c5e
Try to mitigate potential future driver core api changes by adding a
padding to struct hrtimer.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5432e05386265281d993199599c6f9dcd17a9daf
Try to mitigate potential future driver core api changes by adding a
padding to struct blk_integrity, and struct gendisk.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5d19bf942fbedc64f705f5d27ae629c57209df27
Try to mitigate potential future driver core api changes by adding a
padding to struct ethtool_ops.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If9f449cb74e81d048a1c41b33c6b7c5b564ecaf3
Try to mitigate potential future driver core api changes by adding a
padding to struct dma_map_ops.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Icbec584dee3716f341a7831a4810025f690eab4a
Try to mitigate potential future driver core api changes by adding a
padding to a lot of different networking structures:
struct ipv6_devconf
struct proto_ops
struct header_ops
struct napi_struct
struct netdev_queue
struct netdev_rx_queue
struct xfrmdev_ops
struct net_device_ops
struct net_device
struct packet_type
struct sk_buff
struct tlsdev_ops
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I590f004754dbc8beafa40e71cac70a0938c38b4a
Try to mitigate potential future driver core api changes by adding a
padding to struct bio.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib69c7bb8b553cacb9cb7bc020d8ac2bbc75621ba
Try to mitigate potential future driver core api changes by adding a
padding to struct scsi_disk.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1191c786cb341df43a40fa1a82789759b0f431cf
Try to mitigate potential future driver core api changes by adding a
padding to struct pci_sriov, struct pci_dev, struct pci_bus, and struct
pci_driver.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I236df60165b25a33b06fc81f76014162401ba742
There are a lot of different structures that need to have a "frozen" abi
for the next 5+ years. Add padding to a lot of them in order to be able
to handle any future changes that might be needed due to LTS and
security fixes that might come up.
It's a best guess, based on what has happened in the past from the
5.10.0..5.10.110 release (1 1/2 years). Yes, past changes do not mean
that future changes will also be needed in the same area, but that is a
hint that those areas are both well maintained and looked after, and
there have been previous problems found in them.
Also the list of structures that are being required based on OEM usage
in the android/ symbol lists were consulted as that's a larger list than
what has been changed in the past.
Hopefully we caught everything we need to worry about, only time will
tell...
Bug: 151154716
Change-Id: I880bbcda0628a7459988eeb49d18655522697664
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
With a raw socket bound to IPPROTO_RAW (ie with hdrincl enabled), the
protocol field of the flow structure, build by raw_sendmsg() /
rawv6_sendmsg()), is set to IPPROTO_RAW. This breaks the ipsec policy
lookup when some policies are defined with a protocol in the selector.
For ipv6, the sin6_port field from 'struct sockaddr_in6' could be used to
specify the protocol. Just accept all values for IPPROTO_RAW socket.
For ipv4, the sin_port field of 'struct sockaddr_in' could not be used
without breaking backward compatibility (the value of this field was never
checked). Let's add a new kind of control message, so that the userland
could specify which protocol is used.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
CC: stable@vger.kernel.org
Change-Id: I168bca9e37561b255268414e2fdfac18cd08381c
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://lore.kernel.org/r/20230522120820.1319391-1-nicolas.dichtel@6wind.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
(cherry picked from commit 3632679d9e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Users who want to share a single public IP address for outgoing connections
between several hosts traditionally reach for SNAT. However, SNAT requires
state keeping on the node(s) performing the NAT.
A stateless alternative exists, where a single IP address used for egress
can be shared between several hosts by partitioning the available ephemeral
port range. In such a setup:
1. Each host gets assigned a disjoint range of ephemeral ports.
2. Applications open connections from the host-assigned port range.
3. Return traffic gets routed to the host based on both, the destination IP
and the destination port.
An application which wants to open an outgoing connection (connect) from a
given port range today can choose between two solutions:
1. Manually pick the source port by bind()'ing to it before connect()'ing
the socket.
This approach has a couple of downsides:
a) Search for a free port has to be implemented in the user-space. If
the chosen 4-tuple happens to be busy, the application needs to retry
from a different local port number.
Detecting if 4-tuple is busy can be either easy (TCP) or hard
(UDP). In TCP case, the application simply has to check if connect()
returned an error (EADDRNOTAVAIL). That is assuming that the local
port sharing was enabled (REUSEADDR) by all the sockets.
# Assume desired local port range is 60_000-60_511
s = socket(AF_INET, SOCK_STREAM)
s.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
s.bind(("192.0.2.1", 60_000))
s.connect(("1.1.1.1", 53))
# Fails only if 192.0.2.1:60000 -> 1.1.1.1:53 is busy
# Application must retry with another local port
In case of UDP, the network stack allows binding more than one socket
to the same 4-tuple, when local port sharing is enabled
(REUSEADDR). Hence detecting the conflict is much harder and involves
querying sock_diag and toggling the REUSEADDR flag [1].
b) For TCP, bind()-ing to a port within the ephemeral port range means
that no connecting sockets, that is those which leave it to the
network stack to find a free local port at connect() time, can use
the this port.
IOW, the bind hash bucket tb->fastreuse will be 0 or 1, and the port
will be skipped during the free port search at connect() time.
2. Isolate the app in a dedicated netns and use the use the per-netns
ip_local_port_range sysctl to adjust the ephemeral port range bounds.
The per-netns setting affects all sockets, so this approach can be used
only if:
- there is just one egress IP address, or
- the desired egress port range is the same for all egress IP addresses
used by the application.
For TCP, this approach avoids the downsides of (1). Free port search and
4-tuple conflict detection is done by the network stack:
system("sysctl -w net.ipv4.ip_local_port_range='60000 60511'")
s = socket(AF_INET, SOCK_STREAM)
s.setsockopt(SOL_IP, IP_BIND_ADDRESS_NO_PORT, 1)
s.bind(("192.0.2.1", 0))
s.connect(("1.1.1.1", 53))
# Fails if all 4-tuples 192.0.2.1:60000-60511 -> 1.1.1.1:53 are busy
For UDP this approach has limited applicability. Setting the
IP_BIND_ADDRESS_NO_PORT socket option does not result in local source
port being shared with other connected UDP sockets.
Hence relying on the network stack to find a free source port, limits the
number of outgoing UDP flows from a single IP address down to the number
of available ephemeral ports.
To put it another way, partitioning the ephemeral port range between hosts
using the existing Linux networking API is cumbersome.
To address this use case, add a new socket option at the SOL_IP level,
named IP_LOCAL_PORT_RANGE. The new option can be used to clamp down the
ephemeral port range for each socket individually.
The option can be used only to narrow down the per-netns local port
range. If the per-socket range lies outside of the per-netns range, the
latter takes precedence.
UAPI-wise, the low and high range bounds are passed to the kernel as a pair
of u16 values in host byte order packed into a u32. This avoids pointer
passing.
PORT_LO = 40_000
PORT_HI = 40_511
s = socket(AF_INET, SOCK_STREAM)
v = struct.pack("I", PORT_HI << 16 | PORT_LO)
s.setsockopt(SOL_IP, IP_LOCAL_PORT_RANGE, v)
s.bind(("127.0.0.1", 0))
s.getsockname()
# Local address between ("127.0.0.1", 40_000) and ("127.0.0.1", 40_511),
# if there is a free port. EADDRINUSE otherwise.
[1] https://github.com/cloudflare/cloudflare-blog/blob/232b432c1d57/2022-02-connectx/connectx.py#L116
Reviewed-by: Marek Majkowski <marek@cloudflare.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Change-Id: I06e1860472cd2f90bf030076be0c87b9b775a3df
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 91d0b78c51)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit: aa69c36f31 upstream.
We do consider thermal pressure in util_fits_cpu() for uclamp_min only.
With the exception of the biggest cores which by definition are the max
performance point of the system and all tasks by definition should fit.
Even under thermal pressure, the capacity of the biggest CPU is the
highest in the system and should still fit every task. Except when it
reaches capacity inversion point, then this is no longer true.
We can handle this by using the inverted capacity as capacity_orig in
util_fits_cpu(). Which not only addresses the problem above, but also
ensure uclamp_max now considers the inverted capacity. Force fitting
a task when a CPU is in this adverse state will contribute to making the
thermal throttling last longer.
Change-Id: I3c1a4758eb387c5c8e0ba68751840517fff4ae64
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220804143609.515789-10-qais.yousef@arm.com
(cherry picked from commit aa69c36f31)
Signed-off-by: Qais Yousef (Google) <qyousef@layalina.io>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 799c7301de)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit: 44c7b80bff upstream.
Check each performance domain to see if thermal pressure is causing its
capacity to be lower than another performance domain.
We assume that each performance domain has CPUs with the same
capacities, which is similar to an assumption made in energy_model.c
We also assume that thermal pressure impacts all CPUs in a performance
domain equally.
If there're multiple performance domains with the same capacity_orig, we
will trigger a capacity inversion if the domain is under thermal
pressure.
The new cpu_in_capacity_inversion() should help users to know when
information about capacity_orig are not reliable and can opt in to use
the inverted capacity as the 'actual' capacity_orig.
Change-Id: I23a98594e6b24697eb33d9bbfb8dd46a12bfa050
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220804143609.515789-9-qais.yousef@arm.com
(cherry picked from commit 44c7b80bff)
Signed-off-by: Qais Yousef (Google) <qyousef@layalina.io>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fe1c982958)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
With FEAT_FGT, most bits in hfgwtr_el2 must be set to 1 to enable
trapping of MSR writes of certain registers. However, there is a
notable (and arguably curious) exception for nSMPRI_EL1 and
nTPIDR2_EL0 which must be set to 1 to _disable_ trapping of the
corresponding SME registers.
Make sure to initialize hfgwtr_el2 in the pKVM init params accordingly
to avoid accidentally enabling certain traps on hardware that supports
FEAT_FGT and FEAT_SME.
Bug: 282917063
Bug: 282993310
Change-Id: Ia96fa6856b4e7ef98b3cea4f03fcbc0ee03f10c5
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
commit 7e01c7f704 upstream.
Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.
For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
size = SKB_DATA_ALIGN(size);
size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")
Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).
However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).
Consequently the SKB bounds checking semantics fails and panics:
skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:113!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
Workqueue: mld mld_ifc_work
RIP: 0010:skb_panic net/core/skbuff.c:113 [inline]
RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118
[snip]
Call Trace:
<TASK>
skb_put+0x151/0x210 net/core/skbuff.c:2047
skb_put_zero include/linux/skbuff.h:2422 [inline]
cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]
cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308
cdc_ncm_tx_fixup+0xa3/0x100
Deal with too low values of dwNtbOutMaxSize, clamp it in the range
[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure
enough data space is allocated to handle CDC data by making sure
dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
Fixes: 289507d336 ("net: cdc_ncm: use sysfs for rx/tx aggregation tuning")
Cc: stable@vger.kernel.org
Reported-by: syzbot+9f575a1f15fc0c01ed69@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=b982f1059506db48409d
Link: https://lore.kernel.org/all/20211202143437.1411410-1-lee.jones@linaro.org/
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230517133808.1873695-2-tudor.ambarus@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 281604646
Bug: 281606231
Change-Id: Ic1d912e7bf2ba53620eb8293b68ec6046422e047
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
update symbol list related to meminfo for galaxy
3 variable symbol(s) added
'struct tracepoint __tracepoint_android_vh_meminfo_cache_adjust'
'struct tracepoint __tracepoint_android_vh_si_mem_available_adjust'
'struct tracepoint __tracepoint_android_vh_si_meminfo_adjust'
Bug: 283896254
Change-Id: Ia6081e553312781a37c5eae8b0f6751909fad4bf
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Add vendor hooks for extra memory. If there is extra memory, this can
be accounted like other memory stats. One of the usecases could be
cleancache. If some of ram memory is used for cleancache, its free,
cache, and total size could be added through these vendor hooks.
Bug: 283896254
Change-Id: Iad7330310528581f09842f45860f05dc84823f41
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
When the IO pressure increases or the system performs dirty
page balancing, the frame rate of the foreground application
may become unstable. Therefore, a hook point is added to limit
the buffer IO rate from the source.
Bug: 262189942
Change-Id: I5214d611a388c5e8d87dc44ffde86ead1834ddff
Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
cleancache is enabled for only ext4 and btrfs. Since f2fs is one
of the main fs in Android, this patch enables cleancache for f2fs.
Bug: 236887352
Change-Id: Ib6e6e832234f72681058da848e9cff36c5a496f2
Signed-off-by: Minchan Kim <minchan@google.com>
(cherry picked from commit 32dfefb4c8)
Android reported a performance regression in the userfaultfd unmap path.
A closer inspection on the userfaultfd_unmap_prep() change showed that a
second tree walk would be necessary in the reworked code.
Fix the regression by passing each VMA that will be unmapped through to
the userfaultfd_unmap_prep() function as they are added to the unmap list,
instead of re-walking the tree for the VMA.
Link: https://lkml.kernel.org/r/20230601015402.2819343-1-Liam.Howlett@oracle.com
Fixes: 69dbe6daf1 ("userfaultfd: use maple tree iterator to iterate VMAs")
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reported-by: Suren Baghdasaryan <surenb@google.com>
Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit de53cc0be1c8b47d595682932beb3c11be9e4e5a
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm mm-unstable)
Bug: 274059236
Change-Id: Ia189a5e98ffe86c4ca5ac3b686ada5f51826f2ed
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
