[ Upstream commit 4e8ef34e36 ]
When work in gadget mode, currently driver doesn't update software level
link_state correctly as link state change event is not enabled for most
devices, in function dwc3_gadget_suspend_interrupt(), it will only pass
suspend event to UDC core when software level link state changes, so when
interrupt generated in sequences of suspend -> reset -> conndone ->
suspend, link state is not updated during reset and conndone, so second
suspend interrupt event will not pass to UDC core.
Remove link_state compare in dwc3_gadget_suspend_interrupt() and add a
suspended flag to replace the compare function.
Fixes: 799e9dc829 ("usb: dwc3: gadget: conditionally disable Link State change events")
Cc: stable <stable@kernel.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Change-Id: I05d2c6814aaca6ac9bb61298ca49341dc5b7d155
Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230512004524.31950-1-quic_linyyuan@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit f191711553)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[ Upstream commit b93c2a68f3 ]
The wakeup bit in the bmAttributes field indicates whether the device
is configured for remote wakeup. But this field should be allowed to
set only if the UDC supports such wakeup mechanism. So configure this
field based on UDC capability. Also inform the UDC whether the device
is configured for remote wakeup by implementing a gadget op.
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Change-Id: I45920af2fe5171587ee801abf4c3d33f8832720f
Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
Link: https://lore.kernel.org/r/1679694482-16430-2-git-send-email-quic_eserrao@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of: 4e8ef34e36 ("usb: dwc3: fix gadget mode suspend interrupt handler issue")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 7919af1dcb)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Now that the branch is used to create production GKI
images, need to institute ACK DrNo for all commits.
The DrNo approvers are in the android-mainline branch
at /OWNERS_DrNo.
Bug: 287162457
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Id5bb83d7add5f314df6816c1c51b4bf2d8018e79
This locks down OWNERS approval to a small group to guard against
unintentional breakages.
Bug: 287162457
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I58ca467b1e7786e1ad0f6ad67c7a7a5845a91ec6
Set KMI_GENERATION=9 for 6/16 KMI update
variable symbol changed from 'struct static_key_false cpu_hwcap_keys[75]' to 'struct static_key_false cpu_hwcap_keys[95]'
CRC changed from 0xfe9a697c to 0x41aad71d
type changed from 'struct static_key_false[75]' to 'struct static_key_false[95]'
number of elements changed from 75 to 95
function symbol 'struct block_device* I_BDEV(struct inode*)' changed
CRC changed from 0x6ad768b0 to 0x8d400dbd
function symbol 'void* PDE_DATA(const struct inode*)' changed
CRC changed from 0x1b12d990 to 0xc3c38b5c
function symbol 'void __ClearPageMovable(struct page*)' changed
CRC changed from 0x5ed16e08 to 0xf489e5e8
... 3676 omitted; 3679 symbols have only CRC changes
type 'enum cpuhp_state' changed
enumerator 'CPUHP_AP_ARM_SDEI_STARTING' (114) was removed
enumerator 'CPUHP_AP_ARM_VFP_STARTING' value changed from 115 to 114
enumerator 'CPUHP_AP_ARM64_DEBUG_MONITORS_STARTING' value changed from 116 to 115
enumerator 'CPUHP_AP_PERF_ARM_HW_BREAKPOINT_STARTING' value changed from 117 to 116
enumerator 'CPUHP_AP_PERF_ARM_ACPI_STARTING' value changed from 118 to 117
enumerator 'CPUHP_AP_PERF_ARM_STARTING' value changed from 119 to 118
enumerator 'CPUHP_AP_ARM_L2X0_STARTING' value changed from 120 to 119
enumerator 'CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING' value changed from 121 to 120
enumerator 'CPUHP_AP_ARM_ARCH_TIMER_STARTING' value changed from 122 to 121
enumerator 'CPUHP_AP_ARM_GLOBAL_TIMER_STARTING' value changed from 123 to 122
enumerator 'CPUHP_AP_JCORE_TIMER_STARTING' value changed from 124 to 123
enumerator 'CPUHP_AP_ARM_TWD_STARTING' value changed from 125 to 124
enumerator 'CPUHP_AP_QCOM_TIMER_STARTING' value changed from 126 to 125
enumerator 'CPUHP_AP_TEGRA_TIMER_STARTING' value changed from 127 to 126
enumerator 'CPUHP_AP_ARMADA_TIMER_STARTING' value changed from 128 to 127
enumerator 'CPUHP_AP_MARCO_TIMER_STARTING' value changed from 129 to 128
enumerator 'CPUHP_AP_MIPS_GIC_TIMER_STARTING' value changed from 130 to 129
enumerator 'CPUHP_AP_ARC_TIMER_STARTING' value changed from 131 to 130
enumerator 'CPUHP_AP_RISCV_TIMER_STARTING' value changed from 132 to 131
enumerator 'CPUHP_AP_CLINT_TIMER_STARTING' value changed from 133 to 132
enumerator 'CPUHP_AP_CSKY_TIMER_STARTING' value changed from 134 to 133
enumerator 'CPUHP_AP_TI_GP_TIMER_STARTING' value changed from 135 to 134
enumerator 'CPUHP_AP_HYPERV_TIMER_STARTING' value changed from 136 to 135
enumerator 'CPUHP_AP_KVM_STARTING' value changed from 137 to 136
enumerator 'CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING' value changed from 138 to 137
enumerator 'CPUHP_AP_KVM_ARM_VGIC_STARTING' value changed from 139 to 138
enumerator 'CPUHP_AP_KVM_ARM_TIMER_STARTING' value changed from 140 to 139
enumerator 'CPUHP_AP_DUMMY_TIMER_STARTING' value changed from 141 to 140
enumerator 'CPUHP_AP_ARM_XEN_STARTING' value changed from 142 to 141
enumerator 'CPUHP_AP_ARM_CORESIGHT_STARTING' value changed from 143 to 142
enumerator 'CPUHP_AP_ARM_CORESIGHT_CTI_STARTING' value changed from 144 to 143
enumerator 'CPUHP_AP_ARM64_ISNDEP_STARTING' value changed from 145 to 144
enumerator 'CPUHP_AP_SMPCFD_DYING' value changed from 146 to 145
enumerator 'CPUHP_AP_X86_TBOOT_DYING' value changed from 147 to 146
enumerator 'CPUHP_AP_ARM_CACHE_B15_RAC_DYING' value changed from 148 to 147
enumerator 'CPUHP_AP_ONLINE' value changed from 149 to 148
enumerator 'CPUHP_TEARDOWN_CPU' value changed from 150 to 149
enumerator 'CPUHP_AP_ONLINE_IDLE' value changed from 151 to 150
enumerator 'CPUHP_AP_SCHED_WAIT_EMPTY' value changed from 152 to 151
enumerator 'CPUHP_AP_SMPBOOT_THREADS' value changed from 153 to 152
enumerator 'CPUHP_AP_X86_VDSO_VMA_ONLINE' value changed from 154 to 153
enumerator 'CPUHP_AP_IRQ_AFFINITY_ONLINE' value changed from 155 to 154
enumerator 'CPUHP_AP_BLK_MQ_ONLINE' value changed from 156 to 155
enumerator 'CPUHP_AP_ARM_MVEBU_SYNC_CLOCKS' value changed from 157 to 156
enumerator 'CPUHP_AP_X86_INTEL_EPB_ONLINE' value changed from 158 to 157
enumerator 'CPUHP_AP_PERF_ONLINE' value changed from 159 to 158
enumerator 'CPUHP_AP_PERF_X86_ONLINE' value changed from 160 to 159
enumerator 'CPUHP_AP_PERF_X86_UNCORE_ONLINE' value changed from 161 to 160
enumerator 'CPUHP_AP_PERF_X86_AMD_UNCORE_ONLINE' value changed from 162 to 161
enumerator 'CPUHP_AP_PERF_X86_AMD_POWER_ONLINE' value changed from 163 to 162
enumerator 'CPUHP_AP_PERF_X86_RAPL_ONLINE' value changed from 164 to 163
enumerator 'CPUHP_AP_PERF_X86_CQM_ONLINE' value changed from 165 to 164
enumerator 'CPUHP_AP_PERF_X86_CSTATE_ONLINE' value changed from 166 to 165
enumerator 'CPUHP_AP_PERF_X86_IDXD_ONLINE' value changed from 167 to 166
enumerator 'CPUHP_AP_PERF_S390_CF_ONLINE' value changed from 168 to 167
enumerator 'CPUHP_AP_PERF_S390_SF_ONLINE' value changed from 169 to 168
enumerator 'CPUHP_AP_PERF_ARM_CCI_ONLINE' value changed from 170 to 169
enumerator 'CPUHP_AP_PERF_ARM_CCN_ONLINE' value changed from 171 to 170
enumerator 'CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE' value changed from 172 to 171
enumerator 'CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE' value changed from 173 to 172
enumerator 'CPUHP_AP_PERF_ARM_HISI_L3_ONLINE' value changed from 174 to 173
enumerator 'CPUHP_AP_PERF_ARM_HISI_PA_ONLINE' value changed from 175 to 174
enumerator 'CPUHP_AP_PERF_ARM_HISI_SLLC_ONLINE' value changed from 176 to 175
enumerator 'CPUHP_AP_PERF_ARM_L2X0_ONLINE' value changed from 177 to 176
enumerator 'CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE' value changed from 178 to 177
enumerator 'CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE' value changed from 179 to 178
enumerator 'CPUHP_AP_PERF_ARM_APM_XGENE_ONLINE' value changed from 180 to 179
enumerator 'CPUHP_AP_PERF_ARM_CAVIUM_TX2_UNCORE_ONLINE' value changed from 181 to 180
enumerator 'CPUHP_AP_PERF_POWERPC_NEST_IMC_ONLINE' value changed from 182 to 181
enumerator 'CPUHP_AP_PERF_POWERPC_CORE_IMC_ONLINE' value changed from 183 to 182
enumerator 'CPUHP_AP_PERF_POWERPC_THREAD_IMC_ONLINE' value changed from 184 to 183
enumerator 'CPUHP_AP_PERF_POWERPC_TRACE_IMC_ONLINE' value changed from 185 to 184
enumerator 'CPUHP_AP_PERF_POWERPC_HV_24x7_ONLINE' value changed from 186 to 185
enumerator 'CPUHP_AP_PERF_POWERPC_HV_GPCI_ONLINE' value changed from 187 to 186
enumerator 'CPUHP_AP_PERF_CSKY_ONLINE' value changed from 188 to 187
enumerator 'CPUHP_AP_WATCHDOG_ONLINE' value changed from 189 to 188
enumerator 'CPUHP_AP_WORKQUEUE_ONLINE' value changed from 190 to 189
enumerator 'CPUHP_AP_RANDOM_ONLINE' value changed from 191 to 190
enumerator 'CPUHP_AP_RCUTREE_ONLINE' value changed from 192 to 191
enumerator 'CPUHP_AP_BASE_CACHEINFO_ONLINE' value changed from 193 to 192
enumerator 'CPUHP_AP_ONLINE_DYN' value changed from 194 to 193
enumerator 'CPUHP_AP_ONLINE_DYN_END' value changed from 224 to 223
enumerator 'CPUHP_AP_MM_DEMOTION_ONLINE' value changed from 225 to 224
enumerator 'CPUHP_AP_X86_HPET_ONLINE' value changed from 226 to 225
enumerator 'CPUHP_AP_X86_KVM_CLK_ONLINE' value changed from 227 to 226
enumerator 'CPUHP_AP_DTPM_CPU_ONLINE' value changed from 228 to 227
enumerator 'CPUHP_AP_ACTIVE' value changed from 229 to 228
enumerator 'CPUHP_ANDROID_RESERVED_1' value changed from 230 to 229
enumerator 'CPUHP_ANDROID_RESERVED_2' value changed from 231 to 230
enumerator 'CPUHP_ANDROID_RESERVED_3' value changed from 232 to 231
enumerator 'CPUHP_ANDROID_RESERVED_4' value changed from 233 to 232
enumerator 'CPUHP_ONLINE' value changed from 234 to 233
type 'struct task_struct' changed
byte size changed from 4672 to 4736
5 members ('struct sched_rt_entity rt' .. 'struct uclamp_se uclamp[2]') changed
offset changed by -1536
member 'struct sched_statistics stats' was added
189 members ('struct hlist_head preempt_notifiers' .. 'u64 android_kabi_reserved8') changed
offset changed by 832
member 'struct thread_struct thread' changed
offset changed by 768
type 'struct platform_driver' changed
byte size changed from 240 to 248
member 'void(* remove_new)(struct platform_device*)' was added
7 members ('void(* shutdown)(struct platform_device*)' .. 'u64 android_kabi_reserved1') changed
offset changed by 64
type 'struct sched_entity' changed
byte size changed from 512 to 320
member 'struct sched_statistics statistics' was removed
5 members ('int depth' .. 'unsigned long runnable_weight') changed
offset changed by -1728
5 members ('struct sched_avg avg' .. 'u64 android_kabi_reserved4') changed
offset changed by -1536
type 'struct tipc_bearer' changed
member 'u16 encap_hlen' was added
type 'enum kvm_pgtable_prot' changed
enumerator 'KVM_PGTABLE_PROT_PXN' (32) was added
enumerator 'KVM_PGTABLE_PROT_UXN' (64) was added
Bug: 287162457
Change-Id: Icccb0e4826e7693fdae5c4463be6664db1de421c
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[ Upstream commit 35a089b5d7 ]
Checking the bearer min mtu with tipc_udp_mtu_bad() only works for
IPv4 UDP bearer, and IPv6 UDP bearer has a different value for the
min mtu. This patch checks with encap_hlen + TIPC_MIN_BEARER_MTU
for min mtu, which works for both IPv4 and IPv6 UDP bearer.
Note that tipc_udp_mtu_bad() is still used to check media min mtu
in __tipc_nl_media_set(), as m->mtu currently is only used by the
IPv4 UDP bearer as its default mtu value.
Fixes: 682cd3cf94 ("tipc: confgiure and apply UDP bearer MTU on running links")
Change-Id: I585703598475f2de30353fcc7a96e295fe63549b
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 673cb47989)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[ Upstream commit 56077b56cd ]
When doing link mtu negotiation, a malicious peer may send Activate msg
with a very small mtu, e.g. 4 in Shuang's testing, without checking for
the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
n->links[bearer_id].mtu is set to 4294967228, which is a overflow of
'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().
With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:
tipc: Too large msg, purging xmit list 1 5 0 40 4!
tipc: Too large msg, purging xmit list 1 15 0 60 4!
And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in
named_distribute(), and when purging it in tipc_link_xmit(), a crash
was even caused:
general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19
RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0
Call Trace:
<IRQ>
skb_release_data+0xf9/0x1d0
kfree_skb_reason+0x40/0x100
tipc_link_xmit+0x57a/0x740 [tipc]
tipc_node_xmit+0x16c/0x5c0 [tipc]
tipc_named_node_up+0x27f/0x2c0 [tipc]
tipc_node_write_unlock+0x149/0x170 [tipc]
tipc_rcv+0x608/0x740 [tipc]
tipc_udp_recv+0xdc/0x1f0 [tipc]
udp_queue_rcv_one_skb+0x33e/0x620
udp_unicast_rcv_skb.isra.72+0x75/0x90
__udp4_lib_rcv+0x56d/0xc20
ip_protocol_deliver_rcu+0x100/0x2d0
This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),
and not updating mtu if it is too small.
Fixes: ed193ece26 ("tipc: simplify link mtu negotiation")
Reported-by: Shuang Li <shuali@redhat.com>
Change-Id: I84fb5694b763c1e9d1a93643d849d8d17dbf5cd8
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 575e84d90a)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[ Upstream commit 3ae6d66b60 ]
As different media may requires different min mtu, and even the
same media with different net family requires different min mtu,
add tipc_bearer_min_mtu() to calculate min mtu accordingly.
This API will be used to check the new mtu when doing the link
mtu negotiation in the next patch.
Change-Id: Ic9917ba5e26138b813dd037d38c52ce7adb3ea03
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stable-dep-of: 56077b56cd ("tipc: do not update mtu if msg_max is too small in mtu negotiation")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 5cf99d5f65)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[ Upstream commit d2c48b2387 ]
Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra
triggers:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0
preempt_count: 0, expected: 0
RCU nest depth: 0, expected: 0
3 locks held by cpuhp/0/24:
#0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248
#1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248
#2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130
irq event stamp: 36
hardirqs last enabled at (35): [<ffffda301e85b7bc>] finish_task_switch+0xb4/0x2b0
hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhp_thread_fun+0x21c/0x248
softirqs last enabled at (0): [<ffffda301e80b184>] copy_process+0x63c/0x1ac0
softirqs last disabled at (0): [<0000000000000000>] 0x0
CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...]
Hardware name: WIWYNN Mt.Jade Server [...]
Call trace:
dump_backtrace+0x114/0x120
show_stack+0x20/0x70
dump_stack_lvl+0x9c/0xd8
dump_stack+0x18/0x34
__might_resched+0x188/0x228
rt_spin_lock+0x70/0x120
sdei_cpuhp_up+0x3c/0x130
cpuhp_invoke_callback+0x250/0xf08
cpuhp_thread_fun+0x120/0x248
smpboot_thread_fn+0x280/0x320
kthread+0x130/0x140
ret_from_fork+0x10/0x20
sdei_cpuhp_up() is called in the STARTING hotplug section,
which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entry
instead to execute the cpuhp cb later, with preemption enabled.
SDEI originally got its own cpuhp slot to allow interacting
with perf. It got superseded by pNMI and this early slot is not
relevant anymore. [1]
Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on the
calling CPU. It is checked that preemption is disabled for them.
_ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.
Preemption is enabled in those threads, but their cpumask is limited
to 1 CPU.
Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cb
don't trigger them.
Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI call
which acts on the calling CPU.
[1]:
https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/
Suggested-by: James Morse <james.morse@arm.com>
Change-Id: If68806613938a753ba8113cf3421c545934cf3a2
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20230216084920.144064-1-pierre.gondois@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 66caf22787)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[ Upstream commit 31088f6f79 ]
typeof is (still) a GNU extension, which means that it cannot be used when
building ISO C (e.g. -std=c99). It should therefore be avoided in uapi
headers in favour of the ISO-friendly __typeof__.
Unfortunately this issue could not be detected by
CONFIG_UAPI_HEADER_TEST=y as the __ALIGN_KERNEL() macro is not expanded in
any uapi header.
This matters from a userspace perspective, not a kernel one. uapi
headers and their contents are expected to be usable in a variety of
situations, and in particular when building ISO C applications (with
-std=c99 or similar).
This particular problem can be reproduced by trying to use the
__ALIGN_KERNEL macro directly in application code, say:
int align(int x, int a)
{
return __KERNEL_ALIGN(x, a);
}
and trying to build that with -std=c99.
Link: https://lkml.kernel.org/r/20230411092747.3759032-1-kevin.brodsky@arm.com
Fixes: a79ff731a1 ("netfilter: xtables: make XT_ALIGN() usable in exported headers by exporting __ALIGN_KERNEL()")
Change-Id: I4204df6f16689acb4d0786e3edf2b6ebc457c4e3
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Reported-by: Ruben Ayrapetyan <ruben.ayrapetyan@arm.com>
Tested-by: Ruben Ayrapetyan <ruben.ayrapetyan@arm.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Tested-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 397eb669da)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 769fdf83df upstream.
When !SCHEDSTATS schedstat_enabled() is an unconditional 0 and the
whole block doesn't exist, however GCC figures the scoped variable
'stats' is unused and complains about it.
Upgrade the warning from -Wunused-variable to -Wunused-but-set-variable
by writing it in two statements. This fixes the build because the new
warning is in W=1.
Given that whole if(0) {} thing, I don't feel motivated to change
things overly much and quite strongly feel this is the compiler being
daft.
Fixes: cb3e971c435d ("sched: Make struct sched_statistics independent of fair sched class")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Change-Id: I3b1f6cc605ae53a43f4a75a8d1a6cf2a947998ea
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0a008c5098)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[ Upstream commit ceeadb83ae ]
If we want to use the schedstats facility to trace other sched classes, we
should make it independent of fair sched class. The struct sched_statistics
is the schedular statistics of a task_struct or a task_group. So we can
move it into struct task_struct and struct task_group to achieve the goal.
After the patch, schestats are orgnized as follows,
struct task_struct {
...
struct sched_entity se;
struct sched_rt_entity rt;
struct sched_dl_entity dl;
...
struct sched_statistics stats;
...
};
Regarding the task group, schedstats is only supported for fair group
sched, and a new struct sched_entity_stats is introduced, suggested by
Peter -
struct sched_entity_stats {
struct sched_entity se;
struct sched_statistics stats;
} __no_randomize_layout;
Then with the se in a task_group, we can easily get the stats.
The sched_statistics members may be frequently modified when schedstats is
enabled, in order to avoid impacting on random data which may in the same
cacheline with them, the struct sched_statistics is defined as cacheline
aligned.
As this patch changes the core struct of scheduler, so I verified the
performance it may impact on the scheduler with 'perf bench sched
pipe', suggested by Mel. Below is the result, in which all the values
are in usecs/op.
Before After
kernel.sched_schedstats=0 5.2~5.4 5.2~5.4
kernel.sched_schedstats=1 5.3~5.5 5.3~5.5
[These data is a little difference with the earlier version, that is
because my old test machine is destroyed so I have to use a new
different test machine.]
Almost no impact on the sched performance.
No functional change.
[lkp@intel.com: reported build failure in earlier version]
Change-Id: I3df219ae37b431796057e380098afa7f6bb2bc63
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Link: https://lore.kernel.org/r/20210905143547.4668-3-laoar.shao@gmail.com
Stable-dep-of: 39afe5d6fc ("sched/fair: Fix inaccurate tally of ttwu_move_affine")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit c3b9f95598)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[ Upstream commit 5c5a7680e6 ]
struct platform_driver::remove returning an integer made driver authors
expect that returning an error code was proper error handling. However
the driver core ignores the error and continues to remove the device
because there is nothing the core could do anyhow and reentering the
remove callback again is only calling for trouble.
So this is an source for errors typically yielding resource leaks in the
error path.
As there are too many platform drivers to neatly convert them all to
return void in a single go, do it in several steps after this patch:
a) Convert all drivers to implement .remove_new() returning void instead
of .remove() returning int;
b) Change struct platform_driver::remove() to return void and so make
it identical to .remove_new();
c) Change all drivers back to .remove() now with the better prototype;
d) drop struct platform_driver::remove_new().
While this touches all drivers eventually twice, steps a) and c) can be
done one driver after another and so reduces coordination efforts
immensely and simplifies review.
Change-Id: I35e14b74375e32f1351bfebfa794e2f3fec99776
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20221209150914.3557650-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of: c766c90faf ("media: rcar_fdp1: Fix refcount leak in probe and remove function")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit d18789f434)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Over the lifetime of the kernel, new arm64 cpucaps need to be added to
handle errata and other fun stuff. So reserve 20 spots for us to use in
the future as this is an ABI-stable structure that we can not increase
over time without major problems.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I37bdac374e2570f61ab54919712fd62c7e541e67
FEAT_XNX allows to specify PXN and UXN attributes on stage-2 entries.
Make this usable from pKVM by exposing two new kvm_pgtable_prot entries
for each of them.
No functional changes intended.
Bug: 264070847
Change-Id: I47d861fa64ba511370b182f4609fe1c27695a949
Signed-off-by: Quentin Perret <qperret@google.com>
Nothing currently prevents the donation of an MMIO region to the
hypervisor for backing e.g. guest stage-2 page-tables, tracing buffers,
hyp vm and vcpu metadata, or any other donation to EL2. However, the
only confirmed use-case for MMIO donations are for protecting the IOMMU
registers as well as for vendor module usage.
Restrict the donation of MMIO regions to these two paths only by
introducing a new helper function.
Bug: 264070847
Change-Id: I914508fb3e3547fcfabca8557bdf7948cb796099
Signed-off-by: Quentin Perret <qperret@google.com>
We've historically disallowed state changes for MMIO pages -- the host
had sole ownership of all of them. However, changing the state of those
pages has clearly become a goal both to support vendor extensions to
the hypervisor, as well as to support device assignment in the longer
term. To pave the way towards this support, let's allow certain state
transitions for MMIO pages.
Bug: 264070847
Change-Id: I9803b572c90d8a694c3d43a0ee0d7b4f4124fe4a
Signed-off-by: Quentin Perret <qperret@google.com>
We now allow donations of MMIO ranges, let's also allow modules to
change host stage-2 permissions.
Bug: 264070847
Change-Id: Ia72678bb27559d9a7963dbc5ffb5a101efcbbad2
Signed-off-by: Quentin Perret <qperret@google.com>
There shouldn't be any reason to ever need allocating from the host
stage-2 pool during mem aborts now that the base page-table structure
is pinned. To prevent future regressions in this area, introduce a new
sanity check that will warn when hyp_page_alloc() is used from the mem
wrong paths.
Bug: 264070847
Change-Id: I7a7c606fe01558790e4ffcd3534f8976caf48bd0
Signed-off-by: Quentin Perret <qperret@google.com>
The MMIO register space for IOMMUs controlled by the hypervisor is
currently unmapped from the host stage-2, and we rely on the host abort
path to not accidentally map them. However, this approach becomes
increasingly difficult to maintain as we introduce support for donating
MMIO regions and not just memory -- nothing prevents the host from
donating a protected MMIO register to another entity for example.
Now that MMIO donations are possible, let's use the proper
host-donate-hyp machinery to implement this. As a nice side effect, this
guarantees the host stage-2 page-table is annotated with hyp ownership
for those IOMMU regions, which guarantees the core range alignment
feature in the host mem abort parth will do the right thing without
requiring a second pass in the IOMMU code. This also turns the host
stage-2 PTEs into "non-default" entries, hence avoiding issues with the
coallescing code looking forward.
Bug: 264070847
Change-Id: I1fad1b1be36f3b654190a912617e780141945a8f
Signed-off-by: Quentin Perret <qperret@google.com>
We now support donations of MMIO ranges to the hypervisor. Make sure to
update the donation logic to correctly map these pages with device
mappings.
Bug: 264070847
Change-Id: I36558f05ed47d1e3dc06e4e24151241474b4ff77
Signed-off-by: Quentin Perret <qperret@google.com>
We're now guaranteed by construction to not require structural changes
to the host stage-2 page-table from the host memory abort path, so let's
use the low-level __host_stage2_idmap() function directly instead of the
higher-level wrapper that attempts page recycling when running out of
memory.
Bug: 264070847
Change-Id: I2db34777386931bfb3f93ea3b3e51e1e2a10ea79
Signed-off-by: Quentin Perret <qperret@google.com>
Now that the host stage-2 page-table is entirely pre-populated in
__pkvm_init_finalize(), we know that by the end of this function, the
structure of the page-table will remain stable until the host calls in
the hypervisor to require e.g. a page-table changes (by e.g. running a
guest). This does not necessarily mean that no host mem aborts will
occur -- there may be null PTEs in the host stage-2 due to collapsed
block mappings from fix_host_ownership() for example -- but all those
aborts should be trivially handled without requiring structural changes
to the page-table. This has the nice side effect of guaranteeing that
host_mem_abort() will not allocate from the host stage-2 pool. In order
to ensure this desirable property is retained for the lifetime of the
system even in the presence of the coalescing feature, let's 'pin' the
structure of the page-table as-is by taking an additional reference
from each table entry.
Bug: 264070847
Change-Id: If870d7485cc38f6ad714901e710287911f111897
Signed-off-by: Quentin Perret <qperret@google.com>
We will soon need to use kvm_pte_follow() from outside pgtable.c, so
move it to the header file as static inline.
Bug: 264070847
Change-Id: I319dff1b352a4acd8d9a5cc74acb5f1758be358f
Signed-off-by: Quentin Perret <qperret@google.com>
We will soon attempt to avoid any memory allocations from the host mem
abort path. In order to pave the way towards supporting this, let's
pre-populate the host stage-2 for the entire address space using as many
block mappings as possible. Some of these mappings may need to be
collapsed shortly after from fix_host_ownership() for example, so this
doesn't guarantee the absence of memory aborts altogether, but helps
getting the structure of the page-table in the right shape early on.
Bug: 264070847
Change-Id: Ib3ce25c893f779437ce473d64e08e8876870556c
Signed-off-by: Quentin Perret <qperret@google.com>
The fix_host_ownership() path walks the hypervisor's stage-1 page-table
to adjust the host's stage-2 accordingly. However, this is done before
the hyp stage-1 refcount has been fixed up, and before the hyp percpu
fixmap has been created. This all works right now as we start off with
an empty host stage-2, so none of the changes require the usage of the
fixmap for e.g. CMOs.
To prepare the ground for doing fix_host_ownership() with a non-empty
page-table, finalize the hyp stage-1 upfront.
Bug: 264070847
Change-Id: I6aff3ac2f835be3fb3fba7660540c0a9b99c097d
Signed-off-by: Quentin Perret <qperret@google.com>
When recycling host stage-2 page-table pages, we currenly blindly
unmap all 'non-moveable' regions. To prepare the ground for allowing the
mapping of those regions with non-default attributes, let's switch to
using the recently introduced kvm_pgtable_stage2_reclaim_leaf() helper
which will only reclaim pages containing PTEs with default attributes.
Bug: 264070847
Change-Id: I4a441a20abe84d2405efcfa403908078c10be841
Signed-off-by: Quentin Perret <qperret@google.com>
We will soon improve the mechanism by which the host's stage-2
page-table pages are recycled whenever its pool runs out of pages. To
prepare thecground for this, introduce a new helper function in the
page-table code allowing to reclaim leaf pages that don't hold counted
PTEs.
Bug: 264070847
Change-Id: Ie172bf11f2980e45bc908002368759f74f42d195
Signed-off-by: Quentin Perret <qperret@google.com>
Previously it was possible to load a pKVM module after the userspace has
started, leaving on the modules the task of disabling the feature
(__pkvm_close_module_registration HVC).
Depreacte this way of loading modules in favor of the pre-userspace
loading via the cmdline kvm-arm.protected_modules=<module1>,<module2>.
Bug: 254835242
Change-Id: I38eef46b1482ff03af610b3b5d21b3ebfadda59b
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
[ qperret: fixed trivial conflict in nvhe/iommu.c due to aosp/2571370 ]
Signed-off-by: Quentin Perret <qperret@google.com>
Expose usb device state to userland as the information is useful in
detecting non-compliant setups and diagnosing enumeration failures.
For example:
- End-to-end signal integrity issues: the device would fail port reset
repeatedly and thus be stuck in POWERED state.
- Charge-only cables (missing D+/D- lines): the device would never enter
POWERED state as the HC would not see any pullup.
What's the status quo?
We do have error logs such as "Cannot enable. Maybe the USB cable is bad?"
to flag potential setup issues, but there's no good way to expose them to
userspace.
Why add a sysfs entry in struct usb_port instead of struct usb_device?
The struct usb_device is not device_add() to the system until it's in
ADDRESS state hence we would miss the first two states. The struct
usb_port is a better place to keep the information because its life
cycle is longer than the struct usb_device that is attached to the port.
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202306042228.e532af6e-oliver.sang@intel.com
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Roy Luo <royluo@google.com>
Message-ID: <20230608015913.1679984-1-royluo@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(Backport conflicts: connector_ops wasn't there in port.c)
Bug: 285199434
(cherry picked from commit 83cb2604f6
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-testing)
Signed-off-by: Roy Luo <royluo@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:ce2ae89fb6e5f73ae046aeb039a406ec10e626ba)
Change-Id: I1a0da6686e57be05ef10ae98892599eb37074014
Remove this log to avoid non-error conditions.
If CONFIG_USB_PHY is disabled, the following error message appears:
[ 0.231609] xhci-hcd f10f0000.usb3: xhci_plat_probe get usb3phy fail (ret=-6)
[ 0.239716] xhci-hcd f10f8000.usb3: xhci_plat_probe get usb3phy fail (ret=-6)
In this case, devm_usb_get_phy_by_phandle is declared static inline
and returns -ENXIO.
It is easy to pinpoint the failure to get the usb-phy using the debug
log in drivers/usb/phy/phy.c. Therefore, it can be removed.
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Link: https://lore.kernel.org/r/20230510075129.28047-1-stanley_chang@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 286930662
(cherry picked from commit 424e02931e
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Change-Id: I872ceb810cd0389700342911cc601f1703d557cd
The Realtek RTD SoCs were designed with the global register address
offset at 0x8100. The default address offset is constant at
DWC3_GLOBALS_REGS_START (0xc100). Therefore, add a check if the
compatible name of the parent is realtek,rtd-dwc3, then global
register start address will remap to 0x8100.
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20230505025104.18321-1-stanley_chang@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 286930198
(cherry picked from commit ec5eb43813
git: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Change-Id: I436a3a3bd79696764ccd2fad104182ae8a1c9006
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Setting CONFIG_RPMSG_CTRL=y to add a user-space control interface
for RPMSG. It can provide a user-space program to create endpoints with
specific service name, source, and destination addresses.
Bug: 286965107
Change-Id: I86bc065d4b83582b3322f0823e46536ca5847cf6
Signed-off-by: James Tai <james.tai@realtek.com>
[ Upstream commit 8fe72b76db ]
There was a bug where this code forgot to unlock the tdev->mutex if the
kzalloc() failed. Fix this issue, by moving the allocation outside the
lock.
Bug: 275340532
Fixes: 2d1e952a2b ("mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 7d233f9359)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I7a4a1bf06abbb2092aceb72610e3f894b2bfbf0f
[ Upstream commit 2d1e952a2b ]
If a user can make copy_from_user() fail, there is a potential for
UAF/DF due to a lack of locking around the allocation, use and freeing
of the data buffers.
This issue is not theoretical. I managed to author a POC for it:
BUG: KASAN: double-free in kfree+0x5c/0xac
Free of addr ffff29280be5de00 by task poc/356
CPU: 1 PID: 356 Comm: poc Not tainted 6.1.0-00001-g961aa6552c04-dirty #20
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace.part.0+0xe0/0xf0
show_stack+0x18/0x40
dump_stack_lvl+0x64/0x80
print_report+0x188/0x48c
kasan_report_invalid_free+0xa0/0xc0
____kasan_slab_free+0x174/0x1b0
__kasan_slab_free+0x18/0x24
__kmem_cache_free+0x130/0x2e0
kfree+0x5c/0xac
mbox_test_message_write+0x208/0x29c
full_proxy_write+0x90/0xf0
vfs_write+0x154/0x440
ksys_write+0xcc/0x180
__arm64_sys_write+0x44/0x60
invoke_syscall+0x60/0x190
el0_svc_common.constprop.0+0x7c/0x160
do_el0_svc+0x40/0xf0
el0_svc+0x2c/0x6c
el0t_64_sync_handler+0xf4/0x120
el0t_64_sync+0x18c/0x190
Allocated by task 356:
kasan_save_stack+0x3c/0x70
kasan_set_track+0x2c/0x40
kasan_save_alloc_info+0x24/0x34
__kasan_kmalloc+0xb8/0xc0
kmalloc_trace+0x58/0x70
mbox_test_message_write+0x6c/0x29c
full_proxy_write+0x90/0xf0
vfs_write+0x154/0x440
ksys_write+0xcc/0x180
__arm64_sys_write+0x44/0x60
invoke_syscall+0x60/0x190
el0_svc_common.constprop.0+0x7c/0x160
do_el0_svc+0x40/0xf0
el0_svc+0x2c/0x6c
el0t_64_sync_handler+0xf4/0x120
el0t_64_sync+0x18c/0x190
Freed by task 357:
kasan_save_stack+0x3c/0x70
kasan_set_track+0x2c/0x40
kasan_save_free_info+0x38/0x5c
____kasan_slab_free+0x13c/0x1b0
__kasan_slab_free+0x18/0x24
__kmem_cache_free+0x130/0x2e0
kfree+0x5c/0xac
mbox_test_message_write+0x208/0x29c
full_proxy_write+0x90/0xf0
vfs_write+0x154/0x440
ksys_write+0xcc/0x180
__arm64_sys_write+0x44/0x60
invoke_syscall+0x60/0x190
el0_svc_common.constprop.0+0x7c/0x160
do_el0_svc+0x40/0xf0
el0_svc+0x2c/0x6c
el0t_64_sync_handler+0xf4/0x120
el0t_64_sync+0x18c/0x190
Bug: 275340532
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit cad1abbe48)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I79753a9a63d8b04e139eaaeb9435bf1d05d38892
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>
The tarball, when implemented correctly, adds around
3.7MB of kheaders.tar.xz to the kernel image, which
increases memory usage. Since this tarball is usually
for debugging only, mark it as a module so it can
be conditionally loaded.
Bug: 276339429
Test: treehugger
Change-Id: Icc330a947ff25006fa48ffc5801d7a2746369893
Signed-off-by: Yifan Hong <elsk@google.com>
ISOC transfers expect a certain cadence of requests being queued. Not
keeping up with the expected rate of requests results in missed ISOC
transfers (EXDEV). The application layer may or may not produce video
frames to match this expectation, so uvc gadget driver must handle cases
where the application is not queuing up buffers fast enough to fulfill
ISOC requirements.
Currently, uvc gadget driver waits for new video buffer to become available
before queuing up usb requests. With this patch the gadget driver queues up
0 length usb requests whenever there are no video buffers available. The
USB controller's complete callback is used as the limiter for how quickly
the 0 length packets will be queued. Video buffers are still queued as
soon as they become available.
Link: https://lore.kernel.org/CAMHf4WKbi6KBPQztj9FA4kPvESc1fVKrC8G73-cs6tTeQby9=w@mail.gmail.com/
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Link: https://lore.kernel.org/r/20230508231103.1621375-1-arakesh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c3ff12a92b)
Bug: 271684194
Signed-off-by: Avichal Rakesh <arakesh@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:39cc781d6f7542117b07de2fd052e91cc21b66b5)
Change-Id: I3eed9b415f80ccea9c69b0d96593da8493dbf6bb
timerfd doesn't create any wakelocks, but eventpoll can. When it does,
it names them after the underlying file descriptor, and since all
timerfd file descriptors are named "[timerfd]" (which saves memory on
systems like desktops with potentially many timerfd instances), all
wakesources created as a result of using the eventpoll-on-timerfd idiom
are called... "[timerfd]".
However, it becomes impossible to tell which "[timerfd]" wakesource is
affliated with which process and hence troubleshooting is difficult.
Adding vendor hooks to allow vendor to assign appropriate names to
timerfd descriptors and eventoll wakesource.
Bug: 155142106
Signed-off-by: Manish Varma <varmam@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:0ff110fbb309be385126a42ac9f7004ba9b0644e)
Merged-In: I330a42ab48bed4b26d5eb2f636925c66061165ec
Change-Id: I330a42ab48bed4b26d5eb2f636925c66061165ec
Signed-off-by: Darren Hsu <darrenhsu@google.com>
This patch enables KCSAN for arm64, with updates to build rules
to not use KCSAN for several incompatible compilation units.
Recent GCC version(at least GCC10) made outline-atomics as the
default option(unlike Clang), which will cause linker errors
for kernel/kcsan/core.o. Disables the out-of-line atomics by
no-outline-atomics to fix the linker errors.
Meanwhile, as Mark said[1], some latent issues are needed to be
fixed which isn't just a KCSAN problem, we make the KCSAN depends
on EXPERT for now.
Tested selftest and kcsan_test(built with GCC11 and Clang 13),
and all passed.
[1] https://lkml.kernel.org/r/YadiUPpJ0gADbiHQ@FVFF77S0Q05N
Acked-by: Marco Elver <elver@google.com> # kernel/kcsan
Tested-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Link: https://lore.kernel.org/r/20211211131734.126874-1-wangkefeng.wang@huawei.com
[catalin.marinas@arm.com: added comment to justify EXPERT]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 286152957
Change-Id: I369e13fdd1a86c5c5dca0e72c60eae5fb1595299
(cherry picked from commit dd03762ab6)
[joey: Resolve minor conflicts in arch/arm64/Kconfig,
arch/arm64/kvm/hyp/nvhe/Makefile,
kernel/kcsan/Makefile]
Signed-off-by: Joey Jiao <quic_jiangenj@quicinc.com>
See also commit 9102217567.
Revert the code that sends requests back to the I/O scheduler if
dispatching fails because it is suspected to have introduced the
following BFQ crash:
==================================================================
BUG: KASAN: invalid-access in bfq_get_queue+0x500/0x560
Write at addr faffff8056fd8b30 by task Thread-11/27396
Pointer tag: [fa], memory tag: [fe]
CPU: 5 PID: 27396 Comm: Thread-11 Tainted: G S W OE 5.15.110-android14-7-00150-gf82b53108826-ab10234611 #1
Call trace:
dump_backtrace+0xf8/0x1e8
dump_stack_lvl+0x74/0xa4
print_report+0x344/0x958
kasan_report+0x90/0xe4
__do_kernel_fault+0xc4/0x2ac
do_bad_area+0x3c/0x154
do_tag_check_fault+0x18/0x24
do_mem_abort+0x60/0x134
el1_abort+0x38/0x54
el1h_64_sync_handler+0x54/0x88
el1h_64_sync+0x78/0x7c
bfq_get_queue+0x500/0x560
bfq_insert_requests+0x98c/0x1474
blk_mq_sched_insert_requests+0xec/0x334
blk_mq_flush_plug_list+0x138/0x234
blk_flush_plug_list+0x118/0x164
read_pages+0x38c/0x408
page_cache_ra_unbounded+0x22c/0x2f4
do_sync_mmap_readahead+0x1a4/0x208
filemap_fault+0x27c/0x8f4
f2fs_filemap_fault+0x28/0xfc
__do_fault+0xc0/0x204
handle_pte_fault+0x28c/0xdf8
do_handle_mm_fault+0x504/0x7b8
do_page_fault+0x5dc/0x798
do_translation_fault+0x40/0x54
do_mem_abort+0x60/0x134
el0_ia+0x74/0x158
el0t_64_sync_handler+0xac/0xe4
el0t_64_sync+0x1b0/0x1b4
The buggy address belongs to the object at ffffff8056fd8a50
which belongs to the cache bfq_io_cq of size 232
The buggy address is located 224 bytes inside of
232-byte region [ffffff8056fd8a50, ffffff8056fd8b38)
The buggy address belongs to the physical page:
page:00000000a0db99e0 refcount:1 mapcount:0 mapping:0000000000000000 index:0xfaffff8056fd8a50 pfn:0xd6fd8
head:00000000a0db99e0 order:1 compound_mapcount:0
flags: 0x4000000000010200(slab|head|zone=1|kasantag=0x0)
raw: 4000000000010200 fffffffe2306b300 0000000400000004 f2ffff800a71f700
raw: faffff8056fd8a50 000000008022001d 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffff8056fd8900: fe fe fe fe fe fe fd fd fd fd fd fd fd fd fd fd
ffffff8056fd8a00: fd fd fd fd fd fe fe fe fe fe fe fe fe fe fe fe
>ffffff8056fd8b00: fe fe fe fe fb fb fb fb fb fb fb fb fb fb fb fb
^
ffffff8056fd8c00: fb fb fb f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4
ffffff8056fd8d00: f4 f4 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
==================================================================
Bug: 285769645
Change-Id: Ia870feee81988ae47a2be0e1b145d18165588f8a
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit 88819308f5.
Revert this commit in preparation of partially reverting "Send requeued
requests to the I/O scheduler".
Bug: 285769645
Change-Id: Ic447d3a245957c4b6a739cbe87503b6a14c8d627
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This adds passthrough only support for ioctls with fuse-bpf.
compat_ioctls will return -ENOTTY.
Bug: 279519292
Test: F2fsMiscTest#testAtomicWrite
Change-Id: Ia3052e465d87dc1d15ae13955fba8a7f93bc387b
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Set KMI_GENERATION=8 for 6/7 KMI update
1 function symbol(s) removed
'void __sock_recv_ts_and_drops(struct msghdr*, struct sock*, struct sk_buff*)'
function symbol changed from 'int ufshcd_hold(struct ufs_hba*, bool)' to 'void ufshcd_hold(struct ufs_hba*, bool)'
CRC changed from 0x97fc06b5 to 0x35a1ce51
type changed from 'int(struct ufs_hba*, bool)' to 'void(struct ufs_hba*, bool)'
return type changed from 'int' to 'void'
function symbol 'struct block_device* I_BDEV(struct inode*)' changed
CRC changed from 0x5c732fed to 0x6ad768b0
function symbol 'void* PDE_DATA(const struct inode*)' changed
CRC changed from 0x782fda7f to 0x1b12d990
function symbol 'void __ClearPageMovable(struct page*)' changed
CRC changed from 0xdf0d01db to 0x5ed16e08
... 3668 omitted; 3671 symbols have only CRC changes
type 'struct page' changed
member 'union { struct { union { struct list_head lru; struct list_head buddy_list; struct list_head pcp_list; }; struct address_space* mapping; unsigned long index; unsigned long private; }; struct { unsigned long pp_magic; struct page_pool* pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; union { unsigned long dma_addr_upper; atomic_long_t pp_frag_count; }; }; struct { union { struct list_head slab_list; struct { struct page* next; int pages; int pobjects; }; }; struct kmem_cache* slab_cache; void* freelist; union { void* s_mem; unsigned long counters; struct { unsigned int inuse:16; unsigned int objects:15; unsigned int frozen:1; }; }; }; struct { unsigned long compound_head; unsigned char compound_dtor; unsigned char compound_order; atomic_t compound_mapcount; unsigned int compound_nr; }; struct { unsigned long _compound_pad_1; atomic_t hpage_pinned_refcount; struct list_head deferred_list; }; struct { unsigned long _pt_pad_1; pgtable_t pmd_huge_pte; unsigned long _pt_pad_2; union { struct mm_struct* pt_mm; atomic_t pt_frag_refcount; }; spinlock_t ptl; }; struct { struct dev_pagemap* pgmap; void* zone_device_data; }; struct callback_head callback_head; }' was added
member 'union { struct { struct list_head lru; struct address_space* mapping; unsigned long index; unsigned long private; }; struct { unsigned long pp_magic; struct page_pool* pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; union { unsigned long dma_addr_upper; atomic_long_t pp_frag_count; }; }; struct { union { struct list_head slab_list; struct { struct page* next; int pages; int pobjects; }; }; struct kmem_cache* slab_cache; void* freelist; union { void* s_mem; unsigned long counters; struct { unsigned int inuse:16; unsigned int objects:15; unsigned int frozen:1; }; }; }; struct { unsigned long compound_head; unsigned char compound_dtor; unsigned char compound_order; atomic_t compound_mapcount; unsigned int compound_nr; }; struct { unsigned long _compound_pad_1; atomic_t hpage_pinned_refcount; struct list_head deferred_list; }; struct { unsigned long _pt_pad_1; pgtable_t pmd_huge_pte; unsigned long _pt_pad_2; union { struct mm_struct* pt_mm; atomic_t pt_frag_refcount; }; spinlock_t ptl; }; struct { struct dev_pagemap* pgmap; void* zone_device_data; }; struct callback_head callback_head; }' was removed
type 'struct request_queue' changed
byte size changed from 2240 to 2104
member 'struct delayed_work requeue_work' was removed
22 members ('struct mutex sysfs_lock' .. 'u64 android_oem_data1') changed
offset changed by -1088
type 'struct Scsi_Host' changed
member 'unsigned int queuecommand_may_block:1' was added
2 members ('unsigned int short_inquiry:1' .. 'unsigned int no_scsi2_lun_in_cdb:1') changed
offset changed by 1
type 'struct pglist_data' changed
byte size changed from 7168 to 7232
2 members ('unsigned long flags' .. 'struct lru_gen_mm_walk mm_walk') changed
offset changed by 128
member 'struct lru_gen_memcg memcg_lru' changed
offset changed by 256
3 members ('struct zone_padding _pad2_' .. 'atomic_long_t vm_stat[41]') changed
offset changed by 512
type 'struct phy_device' changed
byte size changed from 1600 to 1640
member 'struct phy_led_trigger* phy_led_triggers' was added
member 'unsigned int phy_num_led_triggers' was added
member 'struct phy_led_trigger* last_triggered' was added
member 'struct phy_led_trigger* led_link_trigger' was added
member 'int irq' changed
offset changed by 288
21 members ('void* priv' .. 'u64 android_kabi_reserved4') changed
offset changed by 320
type 'struct scsi_host_template' changed
member 'unsigned int queuecommand_may_block:1' was added
type 'struct mem_cgroup_per_node' changed
byte size changed from 2080 to 2096
9 members ('struct lruvec_stats_percpu* lruvec_stats_percpu' .. 'struct mem_cgroup* memcg') changed
offset changed by 128
type 'struct per_cpu_pages' changed
byte size changed from 336 to 320
member 'spinlock_t lock' was added
4 members ('int count' .. 'short free_factor') changed
offset changed by 32
member changed from 'struct list_head lists[20]' to 'struct list_head lists[17]'
offset changed from 128 to 192
type changed from 'struct list_head[20]' to 'struct list_head[17]'
number of elements changed from 20 to 17
type 'struct swap_info_struct' changed
byte size changed from 288 to 296
member 'u64 android_vendor_data1' was added
member 'struct plist_node avail_lists[0]' changed
offset changed by 64
type 'struct lruvec' changed
byte size changed from 1224 to 1240
member 'struct lru_gen_mm_state mm_state' changed
offset changed by 128
member 'struct pglist_data* pgdat' changed
offset changed by -64
member 'u64 android_vendor_data1' was added
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_mm_walk' changed
byte size changed from 152 to 168
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_memcg' changed
byte size changed from 160 to 176
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_page' changed
byte size changed from 960 to 976
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_mm_state' changed
byte size changed from 120 to 96
member 'struct wait_queue_head wait' was removed
2 members ('unsigned long* filters[2]' .. 'unsigned long stats[1][6]') changed
offset changed by -192
member 'u64 android_kabi_reserved1' was added
member 'int nr_walkers' was removed
Bug: 285364323
Change-Id: I7bde6d93581c7abf225556bdcec7efe25edcc572
Signed-off-by: Carlos Llamas <cmllamas@google.com>
