IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Should tc589_config() fail, some resources need to be released as already
done in the remove function.
Fixes: 15b99ac17295 ("[PATCH] pcmcia: add return value to _config() functions")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/d8593ae867b24c79063646e36f9b18b0790107cb.1684575975.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If an error occures after calling nv_mgmt_acquire_sema(), it should be
undone with a corresponding nv_mgmt_release_sema() call.
Add it in the error handling path of the probe as already done in the
remove function.
Fixes: cac1c52c3621 ("forcedeth: mgmt unit interface")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com>
Link: https://lore.kernel.org/r/355e9a7d351b32ad897251b6f81b5886fcdc6766.1684571393.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEV76QKkVc4xCGURexaDWVMHDJkrAFAmRr6MMACgkQaDWVMHDJ
krAaIA/+IIV2rijvxzlnN41RksfiuI8lmDXuOeAqFCFVAukm6/faiDHmXQC/4ipw
JTdgq4JbB6wTZmYsijSMdwgWDt3BGXZAAXK7sSOXLNRkaf0EuPk6h59P7QXBAkRD
A6ibjWPipV6/k/Mczm8o+WnTSHUln6CVz8yB13gF3eB6+QMO7yYznL4EJ4iUBdZC
OWCukkI8zT07p1u7nqpOmTixXZEqSauC3qB9tg856w8UJoS1evOocgExZr2d8GT3
Ex9Q+Hj8ULkM6tDeke9mfoDDEdHtHDkQIMH5L63siTc0LzvRIs/EZEnZGdZWNy9F
zw6AaIShzJQ9Z9KTP/SRxQ3nvUh/UuI2z7KnZLLxHYqLZZVMNQtinK+ZDGlzvvqg
xr3ZI2PXUXoQT8Mg0BzzpeLwuuSXS8DFyj63SErValRuyIQQs07MhIRFiU3abQtq
A4nfXMzfCwfRn5ggm9HIPLKOtiw1ZlsQtDxmHULpXsUqGgBxEfmCF5f210TmkOhN
yrNlDmNBr39j1xlUeFlJRXWm4badlo39G8s/70oqFTushvatfet7Gyt7fZseGhJL
KNQCfxyCu8bYYmtYfuW6WTc8nq5sJmnTdWEjcT0ftbgDeYNtBjfKfhJ+8+q04FWl
wBxu5nqfKMT1bAKIOLse9eVbaMXNuHJJkStQZAZP5/wUMoVvfHI=
=TZgh
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Dave Hansen:
"This works around and issue where the INVLPG instruction may miss
invalidating kernel TLB entries in recent hybrid CPUs.
I do expect an eventual microcode fix for this. When the microcode
version numbers are known, we can circle back around and add them the
model table to disable this workaround"
* tag 'x86_urgent_for_6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Avoid incomplete Global INVLPG flushes
Only one fix has tricked through by Harshit Mogalapalli found through
static analysis with smatch.
-----BEGIN PGP SIGNATURE-----
iQJGBAABCgAwFiEENnNq2KuOejlQLZofziMdCjCSiKcFAmRr3eQSHG1jZ3JvZkBr
ZXJuZWwub3JnAAoJEM4jHQowkoinesMQALLCWC3aTC7xAM8rADTGw5vw+QwzlWMb
NbF6El90UHgMyabwo7JENIRp+GF2qyqyrr+yfPh76+vyqBql0AWqFP2tz+pBg4bf
L6gZy2hUu7ieSwsjbKSX5vLG91EUd7pFyAPncE+dt4A8VuJiwKBCqsSPkVvTe8pV
VDslfG2QHghZgxHyUKwDq1zMmRiOao5ZnNuGr1TG1TXYjxLpFPcIoDRCdfNzuoad
0fWzIh/KWG/g2HHdjtBZq949UvVldvdkK7BMGhqe7FD/jEsmIuoDGjy/J2I8df2C
AaULGHNu55vp8QC2yh3NTs1TNT1SPHyzeH7F6xQ0vdaJHSFlDfThjAjfBc+z8v1U
ZD2iva/4ZLj2H4iHBQzK+Pok2k/Sgn6cKw4mpCSYJZSz49nkD9wWexgqyAHlxnAB
YB0IxV94PlowQCiw/ET8DKdZ2nOBzl/L1NxxbM7VbRaFwDvIuKxbOmOR73iwUNaa
pChGU0nF/fG0H6hJbMdYhqzDPlqll768BP5GIa/rUjS4oFMroX4hVMubz3TxiCup
8M3mRR5U8jYIisP+Yyrlkpj3D5/0XrLas5kduprGMl30yG4mnIyy2G4p9Wl88SVm
Yj6ocLSeyDB9t0/iYv8fFKeVU0GdCJlgEkqVsxDzqhEuxbU4+cFpuzJAf4yHWPwg
ZodQSLbm+WRv
=yhNz
-----END PGP SIGNATURE-----
Merge tag 'modules-6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux
Pull module fix from Luis Chamberlain:
"Only one fix has trickled through. Harshit Mogalapalli found a
use-after-free bug through static analysis with smatch"
* tag 'modules-6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux:
module: Fix use-after-free bug in read_file_mod_stats()
Smatch warns:
kernel/module/stats.c:394 read_file_mod_stats()
warn: passing freed memory 'buf'
We are passing 'buf' to simple_read_from_buffer() after freeing it.
Fix this by changing the order of 'simple_read_from_buffer' and 'kfree'.
Fixes: df3e764d8e5c ("module: add debug stats to help identify memory pressure")
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Stable Fix:
* Don't change task->tk_status after the call to rpc_exit_task
Other Bugfixes:
* Convert kmap_atomic() to kmap_local_folio()
* Fix a potential double free with READ_PLUS
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEnZ5MQTpR7cLU7KEp18tUv7ClQOsFAmRrttUACgkQ18tUv7Cl
QOuhaA//QFHklXZk/vCkQnNQMYWL11GJliWawLoDfcZal6uQ/a2QCQV1Cbmav62B
FR2BmXDxzM2PRdLu2VHGpkn0CQW3M1tvgaNjGD1xdOxpyIkn47T5lfAd/4X2XPiU
M1ck2Usc258UB1yoKV+jbUD3ptn2BvC+VMWJInaA578hv8TA6Ouh7lP7rPJfDHoJ
OfoLxx9/VqGqMWzfExAHnGw328oieXNnOwynETAdapVwjQeiEcYAED82pJmVsD7+
m++6dRVQRA2bMIMRFWmW8HsO08sR32wzy76XgKws4Xu59Fiy+TQ8PoeUjCtTNq6/
9ibPwH4R7VbcxXa2eT23EbtO2nSkZw/dFiL0s5VNYqeVrBwwlzyklU1uSvIEPegk
zHamqxMMlVLkoMwJa83wIKB8/viPKwV5zcF9UjmrJy67+wXZet6M0c7S9HyiTj9U
NzVbqyK3KhMtsD4ps/EGVWsgGKAIeWbE8wPlP7GF7PHwEw+hWa9pHir6L6BizNqG
DJ/2zfZxDvOGy2r5OvSqGn07/zsj+0URixzEq0IOn1Li/osFZpvK3EVFncd/qsvW
NwPRoF+70skFRdXhbdWa/HEUZlyN2uiIU24luraMrN0U4b4X7aw+EMnMekBi+Vec
bEtWEUJ/vK3mlsOde4gVW0PZBhe8JE6PHlqkQBn5zobV3/cXXCw=
=6xFZ
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-6.4-2' of git://git.linux-nfs.org/projects/anna/linux-nfs
Pull NFS client fixes from Anna Schumaker:
"Stable Fix:
- Don't change task->tk_status after the call to rpc_exit_task
Other Bugfixes:
- Convert kmap_atomic() to kmap_local_folio()
- Fix a potential double free with READ_PLUS"
* tag 'nfs-for-6.4-2' of git://git.linux-nfs.org/projects/anna/linux-nfs:
NFSv4.2: Fix a potential double free with READ_PLUS
SUNRPC: Don't change task->tk_status after the call to rpc_exit_task
NFS: Convert kmap_atomic() to kmap_local_folio()
The LRU and LRU_PERCPU maps allocate a new element on update before locking the
target hash table bucket. Right after that the maps try to lock the bucket.
If this fails, then maps return -EBUSY to the caller without releasing the
allocated element. This makes the element untracked: it doesn't belong to
either of free lists, and it doesn't belong to the hash table, so can't be
re-used; this eventually leads to the permanent -ENOMEM on LRU map updates,
which is unexpected. Fix this by returning the element to the local free list
if bucket locking fails.
Fixes: 20b6cc34ea74 ("bpf: Avoid hashtab deadlock with map_locked")
Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
Link: https://lore.kernel.org/r/20230522154558.2166815-1-aspsk@isovalent.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Add comment in arch_sync_dma_for_device() and handle the direction flag in
arch_sync_dma_for_cpu().
When receiving data from the device (DMA_FROM_DEVICE) unconditionally
purge the data cache in arch_sync_dma_for_cpu().
Signed-off-by: Helge Deller <deller@gmx.de>
Merge series from Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>:
Series of fixes for issues found during development and testing,
primarly for avs driver.
For a bigjoiner configuration display->crtc_disable() will be called
first for the slave CRTCs and then for the master CRTC. However slave
CRTCs will be actually disabled only after the master CRTC is disabled
(from the encoder disable hooks called with the master CRTC state).
Hence the slave PIPEDMCs can be disabled only after the master CRTC is
disabled, make this so.
intel_encoders_post_pll_disable() must be called only for the master
CRTC, as for the other two encoder disable hooks. While at it fix this
up as well. This didn't cause a problem, since
intel_encoders_post_pll_disable() will call the corresponding hook only
for an encoder/connector connected to the given CRTC, however slave
CRTCs will have no associated encoder/connector.
Fixes: 3af2ff0840be ("drm/i915: Enable a PIPEDMC whenever its corresponding pipe is enabled")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-2-imre.deak@intel.com
(cherry picked from commit 7eeef32719f6af935a1554813e6bc206446339cd)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
syzbot is reporting a lockdep warning in fill_pool() because the allocation
from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)
and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.
Since fill_pool() might be called with arbitrary locks held, fill_pool()
should not assume that acquiring kswapd_wait::lock is safe.
Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for
!__GFP_DIRECT_RECLAIM allocation.
Fixes: 3ac7fe5a4aab ("infrastructure to debug (dynamic) objects")
Reported-by: syzbot <syzbot+fe0c72f0ccbb93786380@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/6577e1fa-b6ee-f2be-2414-a2b51b1c5e30@I-love.SAKURA.ne.jp
Closes: https://syzkaller.appspot.com/bug?extid=fe0c72f0ccbb93786380
It's reported that the recording started right after the driver probe
doesn't work properly, and it turned out that this is related with the
codec auto-suspend. Namely, after the probe phase, the usage count
goes zero, and the auto-suspend is programmed, but the codec is kept
still active until the auto-suspend expiration. When an application
(e.g. alsactl) updates the mixer values at this moment, the values are
cached but not actually written. Then, starting arecord thereafter
also results in the silence because of the missing unmute.
The root cause is the handling of "lazy update" mode; when a mixer
value is updated *after* the suspend, it should update only the cache
and exits. At the resume, the cached value is written to the device,
in turn. The problem is that the current code misinterprets the state
of auto-suspend as if it were already suspended.
Although we can add the check of the actual device state after
pm_runtime_get_if_in_use() for catching the missing state, this won't
suffice; the second call of regmap_update_bits_check() will skip
writing the register because the cache has been already updated by the
first call. So we'd need fixes in two different places.
OTOH, a simpler fix is to replace pm_runtime_get_if_in_use() with
pm_runtime_get_if_active() (with ign_usage_count=true). This change
implies that the driver takes the pm refcount if the device is still
in ACTIVE state and continues the processing. A small caveat is that
this will leave the auto-suspend timer. But, since the timer callback
itself checks the device state and aborts gracefully when it's active,
this won't be any substantial problem.
Long story short: we address the missing register-write problem just
by replacing the pm_runtime_*() call in snd_hda_keep_power_up().
Fixes: fc4f000bf8c0 ("ALSA: hda - Fix unexpected resume through regmap code path")
Reported-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Closes: https://lore.kernel.org/r/a7478636-af11-92ab-731c-9b13c582a70d@linux.intel.com
Suggested-by: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230518113520.15213-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On 68030/020, an instruction such as, moveml %a2-%a3/%a5,%sp@- may cause
a stack page fault during instruction execution (i.e. not at an
instruction boundary) and produce a format 0xB exception frame.
In this situation, the value of USP will be unreliable. If a signal is
to be delivered following the exception, this USP value is used to
calculate the location for a signal frame. This can result in a
corrupted user stack.
The corruption was detected in dash (actually in glibc) where it showed
up as an intermittent "stack smashing detected" message and crash
following signal delivery for SIGCHLD.
It was hard to reproduce that failure because delivery of the signal
raced with the page fault and because the kernel places an unpredictable
gap of up to 7 bytes between the USP and the signal frame.
A format 0xB exception frame can be produced by a bus error or an
address error. The 68030 Users Manual says that address errors occur
immediately upon detection during instruction prefetch. The instruction
pipeline allows prefetch to overlap with other instructions, which means
an address error can arise during the execution of a different
instruction. So it seems likely that this patch may help in the address
error case also.
Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
Link: https://lore.kernel.org/all/CAMuHMdW3yD22_ApemzW_6me3adq6A458u1_F0v-1EYwK_62jPA@mail.gmail.com/
Cc: Michael Schmitz <schmitzmic@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: stable@vger.kernel.org
Co-developed-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/9e66262a754fcba50208aa424188896cc52a1dd1.1683365892.git.fthain@linux-m68k.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
When working in slave mode it seems the timing is exceedingly tight.
The TX FIFO can never empty, because the master is driving the clock so
zeros would be sent for those bytes where the FIFO is empty.
Return to interleaving the writing of the TX FIFO and the reading
of the RX FIFO to try to ensure the data is available when required.
Fixes: a84c11e16dc2 ("spi: spi-cadence: Avoid read of RX FIFO before its ready")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230518093927.711358-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In mutex_init() lockdep identifies a lock by defining a special static
key for each lock class. However if we wrap the macro in a function,
like in drmm_mutex_init(), we end up generating:
int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
{
static struct lock_class_key __key;
__mutex_init((lock), "lock", &__key);
....
}
The static __key here is what lockdep uses to identify the lock class,
however since this is just a normal function the key here will be
created once, where all callers then use the same key. In effect the
mutex->depmap.key will be the same pointer for different
drmm_mutex_init() callers. This then results in impossible lockdep
splats since lockdep thinks completely unrelated locks are the same lock
class.
To fix this turn drmm_mutex_init() into a macro such that it generates a
different "static struct lock_class_key __key" for each invocation,
which looks to be inline with what mutex_init() wants.
v2:
- Revamp the commit message with clearer explanation of the issue.
- Rather export __drmm_mutex_release() than static inline.
Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reported-by: Sarah Walker <sarah.walker@imgtec.com>
Fixes: e13f13e039dc ("drm: Add DRM-managed mutex_init()")
Cc: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230519090733.489019-1-matthew.auld@intel.com
Constraint functions have return values, they should be checked for
potential errors.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-8-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
All IPCs using instance_id use 8 bit value. Original commit used 16 bit
value because FW reports possible max value in 16 bit field, but in
practice FW limits the value to 8 bits.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-7-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Configurations with multiple codecs attached to the platform are
supported but only if each from the set is different. Add new field
representing the 'Unique ID' so that codecs that share Vendor and Part
IDs can be differentiated and thus enabling support for such
configurations.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-6-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Constant 'C4_CHANNEL' does not exist on the firmware side. Value 0xC is
reserved for 'C7_1' instead.
Fixes: 580a5912d1fe ("ASoC: Intel: avs: Declare module configuration types")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-5-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Constant 'C4_CHANNEL' does not exist on the firmware side. Value 0xC is
reserved for 'C7_1' instead.
Fixes: 04afbbbb1cba ("ASoC: Intel: Skylake: Update the topology interface structure")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-4-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Path and its components should be accessed under lock to prevent
problems with one thread modifying them while other tries to read.
Fixes: c8c960c10971 ("ASoC: Intel: avs: APL-based platforms support")
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-3-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When changing value of kcontrol, FW module to which data should be send
needs to be found. Currently it is done in improper way, fix it. Change
function name to indicate that it looks only for volume module.
This allows to change volume during runtime, instead of only changing
init value.
Fixes: be2b81b519d7 ("ASoC: Intel: avs: Parse control tuples")
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-2-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When doing plpmtu probe, the probe size is growing every time when it
receives the ACK during the Search state until the probe fails. When
the failure occurs, pl.probe_high is set and it goes to the Complete
state.
However, if the link pmtu is huge, like 65535 in loopback_dev, the probe
eventually keeps using SCTP_MAX_PLPMTU as the probe size and never fails.
Because of that, pl.probe_high can not be set, and the plpmtu probe can
never go to the Complete state.
Fix it by setting pl.probe_high to SCTP_MAX_PLPMTU when the probe size
grows to SCTP_MAX_PLPMTU in sctp_transport_pl_recv(). Also, not allow
the probe size greater than SCTP_MAX_PLPMTU in the Complete state.
Fixes: b87641aff9e7 ("sctp: do state transition when a probe succeeds on HB ACK recv path")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- MIPS GIC fixes for issues that could result in either
loss of state in the interrupt controller, or a deadlock
- Workaround for Mediatek Chromebooks that only save/restore
partial state when turning the GIC redistributors off,
resulting if fireworks if Linux uses interrupt priorities
for pseudo-NMIs
- Fix the MBIGEN error handling on init
- Mark meson-gpio OF data structures as __maybe_unused,
avoiding compilation warnings on non-OF setups
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAmRp7r8PHG1hekBrZXJu
ZWwub3JnAAoJECPQ0LrRPXpDFAcQAMDzCo3vHXzO7pCrP6OX0lL301RaHKc1m5ds
qO5ecBJ0z0GzRr9ZOcWw0vg40QFuJw/avJR6jX5/sEN6KPbgmNytbqWIBR8O2MgA
hSVxOlsszChb9VAX/zZnVcN6BHx+0JaXqltIZyT1fJgPsXx8JGqALc1bGI9mm9Bg
8hBYWkNcEYZa+YLG+u7clPU/xCcDZNgFtKjl82VK0d1gIU2N65SBgHhsyWbr9CFq
/LYqJlfdEnSspSsH2fsrqw7XrT+MOQ4DRvZpjONgV5FGl7Qopj9A1E/kjbpHfNDi
cA+HJVOGDgByyxteORwFF87Xq0/4woE66pmWJcSf8Jox5jWNevOlRFIsDe0x37eN
ttMd14ukTj0mn/cNvq5l47iZoNo8RMI/Qx2XK+ALcsG2/YGvaD2HkdUOhkbYcv6G
kCfU+kZIKQkLGZO8Ch6o6rClkhPbK0Vfl9xyE6CC6E6lhf+qy3okFOC/U2cTVm+T
/b5ROmPwRTbO27irVOl/+prfMA39ThIa0ht/5gAHj11duW5Pf9AA0Oa+cfYmI/a1
mosyCjzo9bc0xsCjrMaDPDgx+TiPM7c4AzMUISh596l24nHST9zzHEwmoVO+hlRH
cA9GFk+KafEbL095Fye7Bynt1uAyJ6Z00TlV7Ri4o7y0/aheKiNMdVUpDfEC2kbc
iRiidBTb
=OUGp
-----END PGP SIGNATURE-----
Merge tag 'irqchip-fixes-6.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
Pull irqchip fixes from Marc Zyngier:
- MIPS GIC fixes for issues that could result in either
loss of state in the interrupt controller, or a deadlock
- Workaround for Mediatek Chromebooks that only save/restore
partial state when turning the GIC redistributors off,
resulting if fireworks if Linux uses interrupt priorities
for pseudo-NMIs
- Fix the MBIGEN error handling on init
- Mark meson-gpio OF data structures as __maybe_unused,
avoiding compilation warnings on non-OF setups
Link: https://lore.kernel.org/lkml/20230521101812.2520740-1-maz@kernel.org
* Plug a race in the stage-2 mapping code where the IPA and the PA
would end up being out of sync
* Make better use of the bitmap API (bitmap_zero, bitmap_zalloc...)
* FP/SVE/SME documentation update, in the hope that this field
becomes clearer...
* Add workaround for Apple SEIS brokenness to a new SoC
* Random comment fixes
x86:
* add MSR_IA32_TSX_CTRL into msrs_to_save
* fixes for XCR0 handling in SGX enclaves
Generic:
* Fix vcpu_array[0] races
* Fix race between starting a VM and "reboot -f"
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmRp0WIUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroPqVwf+OFayNPpURAFqfrOuISYW7hoCL24+
sCtXyVv4Ei0np1vGekit2h/m8GmxO12xEBibcFeYj+YQItIqu9HvC08fRxAKaMeE
N3p9iLuS1zcM3cEuZpg0r6QN+pKybttdadl70yho43CtagEM4FmB7dgyAo9AhyXk
pZUaVfoO6beBQ/J6A6V/Q5xlue1LvHk1+K4rmNcYVTYn6ZOd+yYgvqng1nv5/h9b
0HgW0aUWkEHAB67/sSnUUro707loMNTowsZlMCtgDk4Fzf8RwQ7qc8lClLk1UPjJ
DHB6Hif9F0Q5mkrwn+c7xyVlKARaY6/FOshS2Q620q19+4fq5fUD9HgjrQ==
=ARzH
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"ARM:
- Plug a race in the stage-2 mapping code where the IPA and the PA
would end up being out of sync
- Make better use of the bitmap API (bitmap_zero, bitmap_zalloc...)
- FP/SVE/SME documentation update, in the hope that this field
becomes clearer...
- Add workaround for Apple SEIS brokenness to a new SoC
- Random comment fixes
x86:
- add MSR_IA32_TSX_CTRL into msrs_to_save
- fixes for XCR0 handling in SGX enclaves
Generic:
- Fix vcpu_array[0] races
- Fix race between starting a VM and 'reboot -f'"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: VMX: add MSR_IA32_TSX_CTRL into msrs_to_save
KVM: x86: Don't adjust guest's CPUID.0x12.1 (allowed SGX enclave XFRM)
KVM: VMX: Don't rely _only_ on CPUID to enforce XCR0 restrictions for ECREATE
KVM: Fix vcpu_array[0] races
KVM: VMX: Fix header file dependency of asm/vmx.h
KVM: Don't enable hardware after a restart/shutdown is initiated
KVM: Use syscore_ops instead of reboot_notifier to hook restart/shutdown
KVM: arm64: vgic: Add Apple M2 PRO/MAX cpus to the list of broken SEIS implementations
KVM: arm64: Clarify host SME state management
KVM: arm64: Restructure check for SVE support in FP trap handler
KVM: arm64: Document check for TIF_FOREIGN_FPSTATE
KVM: arm64: Fix repeated words in comments
KVM: arm64: Constify start/end/phys fields of the pgtable walker data
KVM: arm64: Infer PA offset from VA in hyp map walker
KVM: arm64: Infer the PA offset from IPA in stage-2 map walker
KVM: arm64: Use the bitmap API to allocate bitmaps
KVM: arm64: Slightly optimize flush_context()
- Fail graciously if BUILD_BPF_SKEL=1 is specified and clang isn't available.
- Add empty 'struct rq' to 'perf lock contention' to satisfy libbpf 'runqueue'
type verification. This feature is built only with BUILD_BPF_SKEL=1.
- Make vmlinux.h use bpf.h and perf_event.h in source directory, not system
ones that may be old and not have things like 'union perf_sample_weight'.
- Add system include paths to BPF builds to pick things missing in the headers
included by clang -target bpf.
- Update various header copies with the kernel sources.
- Change divide by zero and not supported events behavior to show 'nan'/'not
counted' in 'perf stat' output. This happens when using things like
'perf stat -M TopdownL2 true', involving JSON metrics.
- Update no event/metric expectations affected by using JSON metrics in
'perf stat -ddd' perf test.
- Avoid segv with 'perf stat --topdown' for metrics without a group.
- Do not assume which events may have a PMU name, allowing the logic to keep an
AUX event group together. Makes this usecase work again:
$ perf record --no-bpf-event -c 10 -e '{intel_pt//,tlb_flush.stlb_any/aux-sample-size=8192/pp}:u' -- sleep 0.1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.078 MB perf.data ]
$ perf script -F-dso,+addr | grep -C5 tlb_flush.stlb_any | head -11
sleep 20444 [003] 7939.510243: 1 branches:uH: 7f5350cc82a2 dl_main+0x9a2 => 7f5350cb38f0 _dl_add_to_namespace_list+0x0
sleep 20444 [003] 7939.510243: 1 branches:uH: 7f5350cb3908 _dl_add_to_namespace_list+0x18 => 7f5350cbb080 rtld_mutex_dummy+0x0
sleep 20444 [003] 7939.510243: 1 branches:uH: 7f5350cc8350 dl_main+0xa50 => 0 [unknown]
sleep 20444 [003] 7939.510244: 1 branches:uH: 7f5350cc83ca dl_main+0xaca => 7f5350caeb60 _dl_process_pt_gnu_property+0x0
sleep 20444 [003] 7939.510245: 1 branches:uH: 7f5350caeb60 _dl_process_pt_gnu_property+0x0 => 0 [unknown]
sleep 20444 7939.510245: 10 tlb_flush.stlb_any/aux-sample-size=8192/pp: 0 7f5350caeb60 _dl_process_pt_gnu_property+0x0
sleep 20444 [003] 7939.510254: 1 branches:uH: 7f5350cc87fe dl_main+0xefe => 7f5350ccd240 strcmp+0x0
sleep 20444 [003] 7939.510254: 1 branches:uH: 7f5350cc8862 dl_main+0xf62 => 0 [unknown]
- Add a check for the above use case in 'perf test test_intel_pt'.
- Fix build with refcount checking on arm64, it was still accessing fields that
need to be wrapped so that the refcounted struct gets checked.
- Fix contextid validation in ARM's CS-ETM, so that older kernels without that
field can still be supported.
- Skip unsupported aggregation for stat events found in perf.data files in 'perf script'.
- Add stat test for record and script to check the previous problem.
- Remove needless debuginfod queries from 'perf test java symbol', this was
just making the test take a long time to complete.
- Address python SafeConfigParser() deprecation warning in 'perf test attr'.
- Fix __NR_execve undeclared on i386 'perf bench syscall' build error.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCZGkUygAKCRCyPKLppCJ+
J8LGAP9qi9fvOt96aXLKHPn/op5KjmvnhZH3/Dj/XPnD8xRNOgD/cQu2D/h8zy9h
NAf0lnJZKiyBGwIrCp1i89snxklnxgA=
=Vztu
-----END PGP SIGNATURE-----
Merge tag 'perf-tools-fixes-for-v6.4-1-2023-05-20' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Pull perf tools fixes from Arnaldo Carvalho de Melo:
- Fail graciously if BUILD_BPF_SKEL=1 is specified and clang isn't
available
- Add empty 'struct rq' to 'perf lock contention' to satisfy libbpf
'runqueue' type verification. This feature is built only with
BUILD_BPF_SKEL=1
- Make vmlinux.h use bpf.h and perf_event.h in source directory, not
system ones that may be old and not have things like 'union
perf_sample_weight'
- Add system include paths to BPF builds to pick things missing in the
headers included by clang -target bpf
- Update various header copies with the kernel sources
- Change divide by zero and not supported events behavior to show
'nan'/'not counted' in 'perf stat' output.
This happens when using things like 'perf stat -M TopdownL2 true',
involving JSON metrics
- Update no event/metric expectations affected by using JSON metrics in
'perf stat -ddd' perf test
- Avoid segv with 'perf stat --topdown' for metrics without a group
- Do not assume which events may have a PMU name, allowing the logic to
keep an AUX event group together. Makes this usecase work again:
$ perf record --no-bpf-event -c 10 -e '{intel_pt//,tlb_flush.stlb_any/aux-sample-size=8192/pp}:u' -- sleep 0.1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.078 MB perf.data ]
$ perf script -F-dso,+addr | grep -C5 tlb_flush.stlb_any | head -11
sleep 20444 [003] 7939.510243: 1 branches:uH: 7f5350cc82a2 dl_main+0x9a2 => 7f5350cb38f0 _dl_add_to_namespace_list+0x0
sleep 20444 [003] 7939.510243: 1 branches:uH: 7f5350cb3908 _dl_add_to_namespace_list+0x18 => 7f5350cbb080 rtld_mutex_dummy+0x0
sleep 20444 [003] 7939.510243: 1 branches:uH: 7f5350cc8350 dl_main+0xa50 => 0 [unknown]
sleep 20444 [003] 7939.510244: 1 branches:uH: 7f5350cc83ca dl_main+0xaca => 7f5350caeb60 _dl_process_pt_gnu_property+0x0
sleep 20444 [003] 7939.510245: 1 branches:uH: 7f5350caeb60 _dl_process_pt_gnu_property+0x0 => 0 [unknown]
sleep 20444 7939.510245: 10 tlb_flush.stlb_any/aux-sample-size=8192/pp: 0 7f5350caeb60 _dl_process_pt_gnu_property+0x0
sleep 20444 [003] 7939.510254: 1 branches:uH: 7f5350cc87fe dl_main+0xefe => 7f5350ccd240 strcmp+0x0
sleep 20444 [003] 7939.510254: 1 branches:uH: 7f5350cc8862 dl_main+0xf62 => 0 [unknown]
- Add a check for the above use case in 'perf test test_intel_pt'
- Fix build with refcount checking on arm64, it was still accessing
fields that need to be wrapped so that the refcounted struct gets
checked
- Fix contextid validation in ARM's CS-ETM, so that older kernels
without that field can still be supported
- Skip unsupported aggregation for stat events found in perf.data files
in 'perf script'
- Add stat test for record and script to check the previous problem
- Remove needless debuginfod queries from 'perf test java symbol', this
was just making the test take a long time to complete
- Address python SafeConfigParser() deprecation warning in 'perf test
attr'
- Fix __NR_execve undeclared on i386 'perf bench syscall' build error
* tag 'perf-tools-fixes-for-v6.4-1-2023-05-20' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (33 commits)
perf bench syscall: Fix __NR_execve undeclared build error
perf test attr: Fix python SafeConfigParser() deprecation warning
perf test attr: Update no event/metric expectations
tools headers disabled-features: Sync with the kernel sources
tools headers UAPI: Sync arch prctl headers with the kernel sources
tools headers: Update the copy of x86's mem{cpy,set}_64.S used in 'perf bench'
tools headers x86 cpufeatures: Sync with the kernel sources
tools headers UAPI: Sync s390 syscall table file that wires up the memfd_secret syscall
tools headers UAPI: Sync linux/prctl.h with the kernel sources
perf metrics: Avoid segv with --topdown for metrics without a group
perf lock contention: Add empty 'struct rq' to satisfy libbpf 'runqueue' type verification
perf cs-etm: Fix contextid validation
perf arm64: Fix build with refcount checking
perf test: Add stat test for record and script
perf script: Skip aggregation for stat events
perf build: Add system include paths to BPF builds
perf bpf skels: Make vmlinux.h use bpf.h and perf_event.h in source directory
perf parse-events: Do not break up AUX event group
perf test test_intel_pt.sh: Test sample mode with event with PMU name
perf evsel: Modify group pmu name for software events
...
- Fix broken soft dirty tracking when using the Radix MMU (>= P9).
- Fix ISA mapping when "ranges" property is not present, for PASemi Nemo boards.
- Fix a possible WARN_ON_ONCE hitting in BPF extable handling.
- Fix incorrect DMA address handling when using 2MB TCEs.
- Fix a bug in IOMMU table handling for SR-IOV devices.
- Fix the recent rework of IOMMU handling which left arch code calling clean
up routines that are handled by the IOMMU core.
- A few assorted build fixes.
Thanks to: Christian Zigotzky, Dan Horák, Gaurav Batra, Hari Bathini, Jason
Gunthorpe, Nathan Chancellor, Naveen N. Rao, Nicholas Piggin, Pali Rohár, Randy
Dunlap, Rob Herring.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmRpdU0THG1wZUBlbGxl
cm1hbi5pZC5hdQAKCRBR6+o8yOGlgIsRD/9bGP2IFLmnVbxKHdyN4gr4beBaDWBG
b9c0nxAc6Oh3A9KMiktEKdSlseUt5kaGSe8aawJCqrw/JXxwfxj02rqqrG2YRcg7
0ApDVg32I+VoCMSoWyBzGKFxSkw85QqItZdTAPHi4IJUkArrkYxU+cJvbD25LTpX
LOun4rObSyOCDk0MA+7HjRjI6RfECeExpsrU4sZjaHs+iPv8q/NoanfsIddOTNq6
c4b84ENF4I8E1ZHhOBUO3lkRy+exop8K0YR1yBuAzSGLqyQsSX1GZFtyOo3VPi2V
73+u1T85i0Bdw272/32hWH8pEPtUAOACmSyUfIRIgypialDWgpESrcxgpCEVc1lk
JU3VDKEfqkiQelG+3DVk3MjBZ4ctqp3Ks/wvtcgUoYBjqiyRz0nLESrplfjDas/I
zF26D+XdwF+s6ylvTWQ7bicZ+DexS1TLwpLQk4sU70XQupWRvJ6S91/UNkydtF87
Iv0S6mJSsUkcasUyeuBReeXKFe/BU7D9vTi0wEEfu2SBY03o9TXDv1f91YHsDb8E
zImIDz6xKAXCi8m+uxyDmCtzr8mYHQ2+b1aF9FgF4QDEICDKz+q7IYhVUHqjfffy
08kGBFx23xVj32xKXz2dDizGXRg7/plNC7ef3WQoTueUr7uK071JhMCCb0blQJ8X
wFi83fer8qlxNg==
=mz+r
-----END PGP SIGNATURE-----
Merge tag 'powerpc-6.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
- Fix broken soft dirty tracking when using the Radix MMU (>= P9)
- Fix ISA mapping when "ranges" property is not present, for PASemi
Nemo boards
- Fix a possible WARN_ON_ONCE hitting in BPF extable handling
- Fix incorrect DMA address handling when using 2MB TCEs
- Fix a bug in IOMMU table handling for SR-IOV devices
- Fix the recent rework of IOMMU handling which left arch code calling
clean up routines that are handled by the IOMMU core
- A few assorted build fixes
Thanks to Christian Zigotzky, Dan Horák, Gaurav Batra, Hari Bathini,
Jason Gunthorpe, Nathan Chancellor, Naveen N. Rao, Nicholas Piggin, Pali
Rohár, Randy Dunlap, and Rob Herring.
* tag 'powerpc-6.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/iommu: Incorrect DDW Table is referenced for SR-IOV device
powerpc/iommu: DMA address offset is incorrectly calculated with 2MB TCEs
powerpc/iommu: Remove iommu_del_device()
powerpc/crypto: Fix aes-gcm-p10 build when VSX=n
powerpc/bpf: populate extable entries only during the last pass
powerpc/boot: Disable power10 features after BOOTAFLAGS assignment
powerpc/64s/radix: Fix soft dirty tracking
powerpc/fsl_uli1575: fix kconfig warnings and build errors
powerpc/isa-bridge: Fix ISA mapping when "ranges" is not present
* Fix DT binding for the ahci-ceva driver to fully describe all iommus,
from Michal.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSRPv8tYSvhwAzJdzjdoc3SxdoYdgUCZGoEPAAKCRDdoc3SxdoY
dk1OAQCo3klTiCDydJ2FIOz7XO1UhSfbt+reIkMSd55iSztnZQD/Yk7h9MBzPyAk
X5c+bf66HGMpbUFO2SYXK5b1aRb8tAo=
=R0jk
-----END PGP SIGNATURE-----
Merge tag 'ata-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
Pull ata fix from Damien Le Moal:
- Fix DT binding for the ahci-ceva driver to fully describe all iommus,
from Michal
* tag 'ata-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata:
dt-bindings: ata: ahci-ceva: Cover all 4 iommus entries
- Fix for USB endpoint check in udlfb (found by syzbot fuzzer)
- Small fix in error code path in omapfb
- compiler warning fixes in fbmem & i810
- code removal and whitespace cleanups in stifb and atyfb
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZGnroAAKCRD3ErUQojoP
X8VOAP0XokcmGLqsBv0ED4y4sPFnDlrGuwnm9br+IVSd2BeSgwD/cJ2DrXBbRK12
p2wGannItDCv4K6dCYvsKSfG7avWbgw=
=0/H9
-----END PGP SIGNATURE-----
Merge tag 'fbdev-for-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev
Pull fbdev fixes from Helge Deller:
"A few small unspectacular fbdev fixes:
- Fix for USB endpoint check in udlfb (found by syzbot fuzzer)
- Small fix in error code path in omapfb
- compiler warning fixes in fbmem & i810
- code removal and whitespace cleanups in stifb and atyfb"
* tag 'fbdev-for-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev:
fbdev: stifb: Whitespace cleanups
fbdev: udlfb: Use usb_control_msg_send()
fbdev: udlfb: Fix endpoint check
fbdev: atyfb: Remove unused clock determination
fbdev: i810: include i810_main.h in i810_dvt.c
fbdev: fbmem: mark get_fb_unmapped_area() static
fbdev: omapfb: panel-tpo-td043mtea1: fix error code in probe()
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmRppOoACgkQiiy9cAdy
T1GXBAv9FP5orZJKZ2yR+k/xAccodIPUlAx9ZcfBw9rV8dihny0RzOhafRm4FUln
EuXoS+nWAxNiaOfLZDQ6PezzeVtYbNvlx5EOZ3tZt2I4tb65hdgdiP9axgo6KtfY
dXMH+Ml2wNxgey9HOfDzDnxdGpBXiNaKlIMbBf0BdtTzvo+BNQulP21P/8SLJg11
mbHj9XBouae5D7yakJlefq09wKgzolK5ZYqQyLSF2gpVPzQHB+m0zNXBaaHFQbdC
7xHr+wPBLERyNnEW6F9WBZ9d5ayqdt+UE6HjxeQtnXzkQgrWHKMqJfdEcwjitYCN
CNTpGdJGxoi7JjbJczPcG3bglJPpOPwbOdu7MTMvom/o4DhR8jrxjtv69k8Kt8ZH
WSHsS/740psJFnRf9nY82DHEY1Hy27V/5xtLOjvV2C2nR/Z0KUDIR6/lWnpuWUyU
is/pTbTFGOqQ6xtxnfIFgSx6aYRgbR1chljBzalPKtzuNLipyAKNePRBELYo9hko
y+M7HtAQ
=ZNmq
-----END PGP SIGNATURE-----
Merge tag '6.4-rc2-ksmbd-server-fixes' of git://git.samba.org/ksmbd
Pull ksmbd server fixes from Steve French:
- two fixes for incorrect SMB3 message validation (one for client which
uses 8 byte padding, and one for empty bcc)
- two fixes for out of bounds bugs: one for username offset checks (in
session setup) and the other for create context name length checks in
open requests
* tag '6.4-rc2-ksmbd-server-fixes' of git://git.samba.org/ksmbd:
ksmbd: smb2: Allow messages padded to 8byte boundary
ksmbd: allocate one more byte for implied bcc[0]
ksmbd: fix wrong UserName check in session_user
ksmbd: fix global-out-of-bounds in smb2_find_context_vals
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmRpn+4ACgkQiiy9cAdy
T1F07gv/dvtE23DaAsTtOsXMzc2fQ9jyQiexgUUMWjYWeWJS06r2o3QMWsSV86QT
z645h6jYgUBeuWVFPF/h0WYjGn/C35Fy08SRuNSReNNahYbNh0A5fe+ic8AoA+f1
LWQYOqRkAaZdcfuOP2Cg2OiNDswxLln4L0eTlJu7Hrdi/xUM5qa66VmFfvfVsu3/
nUlV9KGV6lVoEJbD2Oy+9pfB/2ltgmauQqofXAh35BHSah8Q5U2E2QHHhyMwRBBc
qSINxSoNDDyoW5sCXxzgBPH23lzlMNo0tHVRSqPMtLypzoehzwHmkFJVuGv2F82n
Mj+pMD7As4d7/82IpmCMkhkOcUCRLa/d3gHqZMZVCFSXJ8tpTbRTBiiervJ3/94M
IYfZiBuKy6z2mYdE8sW0zXCXzYE9+iAgySER5Ey2IXlbCSN7N81lV2KE8E4jjKhM
Qoe5DL/AGSjDW0RFSOC7PPRpOqpc//PV2JpPmoYodV1i1nWq5dC1DhQcbXjg/r7c
0fABdS0y
=hi0y
-----END PGP SIGNATURE-----
Merge tag '6.4-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs client fixes from Steve French:
"Two smb3 client fixes, both related to deferred close, and also for
stable:
- send close for deferred handles before not after lease break
response to avoid possible sharing violations
- check all opens on an inode (looking for deferred handles) when
lease break is returned not just the handle the lease break came in
on"
* tag '6.4-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
SMB3: drop reference to cfile before sending oplock break
SMB3: Close all deferred handles of inode in case of handle lease break
Add MSR_IA32_TSX_CTRL into msrs_to_save[] to explicitly tell userspace to
save/restore the register value during migration. Missing this may cause
userspace that relies on KVM ioctl(KVM_GET_MSR_INDEX_LIST) fail to port the
value to the target VM.
In addition, there is no need to add MSR_IA32_TSX_CTRL when
ARCH_CAP_TSX_CTRL_MSR is not supported in kvm_get_arch_capabilities(). So
add the checking in kvm_probe_msr_to_save().
Fixes: c11f83e0626b ("KVM: vmx: implement MSR_IA32_TSX_CTRL disable RTM functionality")
Reported-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Mingwei Zhang <mizhang@google.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Message-Id: <20230509032348.1153070-1-mizhang@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Drop KVM's manipulation of guest's CPUID.0x12.1 ECX and EDX, i.e. the
allowed XFRM of SGX enclaves, now that KVM explicitly checks the guest's
allowed XCR0 when emulating ECREATE.
Note, this could theoretically break a setup where userspace advertises
a "bad" XFRM and relies on KVM to provide a sane CPUID model, but QEMU
is the only known user of KVM SGX, and QEMU explicitly sets the SGX CPUID
XFRM subleaf based on the guest's XCR0.
Reviewed-by: Kai Huang <kai.huang@intel.com>
Tested-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20230503160838.3412617-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Explicitly check the vCPU's supported XCR0 when determining whether or not
the XFRM for ECREATE is valid. Checking CPUID works because KVM updates
guest CPUID.0x12.1 to restrict the leaf to a subset of the guest's allowed
XCR0, but that is rather subtle and KVM should not modify guest CPUID
except for modeling true runtime behavior (allowed XFRM is most definitely
not "runtime" behavior).
Reviewed-by: Kai Huang <kai.huang@intel.com>
Tested-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20230503160838.3412617-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit 1e8fed873e74 ("powerpc: drop ranges for definition of
ARCH_FORCE_MAX_ORDER") removed the limits on the possible values for
ARCH_FORCE_MAX_ORDER.
However removing the ranges entirely causes some common work flows to
break. For example building a defconfig (which uses 64K pages), changing
the page size to 4K, and rebuilding used to work, because
ARCH_FORCE_MAX_ORDER would be clamped to 12 by the ranges.
With the ranges removed it creates a kernel that builds but crashes at
boot:
kernel BUG at mm/huge_memory.c:470!
Oops: Exception in kernel mode, sig: 5 [#1]
...
NIP hugepage_init+0x9c/0x278
LR do_one_initcall+0x80/0x320
Call Trace:
do_one_initcall+0x80/0x320
kernel_init_freeable+0x304/0x3ac
kernel_init+0x30/0x1a0
ret_from_kernel_user_thread+0x14/0x1c
The reasoning for removing the ranges was that some of the values were
too large. So take that into account and limit the maximums to 10 which
is the default max, except for the 4K case which uses 12.
Fixes: 1e8fed873e74 ("powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230519113806.370635-1-mpe@ellerman.id.au
Use the newly introduced usb_control_msg_send() instead of usb_control_msg()
when selecting the channel.
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Helge Deller <deller@gmx.de>
Here are some small tty and serial driver fixes for 6.4-rc3 to resolve
some reported problems, and add some new device ids. These include:
- termios documentation updates
- vc_screen use-after-free fix
- memory leak fix in arc_uart driver
- new 8250 driver ids
- other small serial driver fixes
All of these have been in linux-next for a while with no reported
problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZGj81w8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymjHACfSNJWXivuDTI5KEAkUPLfi1zg5xUAn0x1Demd
NYV1GFn76O0Ijfs6JLll
=0YxQ
-----END PGP SIGNATURE-----
Merge tag 'tty-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty / serial fixes from Greg KH:
"Here are some small tty and serial driver fixes for 6.4-rc3 to resolve
some reported problems, and add some new device ids. These include:
- termios documentation updates
- vc_screen use-after-free fix
- memory leak fix in arc_uart driver
- new 8250 driver ids
- other small serial driver fixes
All of these have been in linux-next for a while with no reported
problems"
* tag 'tty-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF
serial: qcom-geni: fix enabling deactivated interrupt
serial: 8250_bcm7271: fix leak in `brcmuart_probe`
serial: 8250_bcm7271: balance clk_enable calls
serial: arc_uart: fix of_iomap leak in `arc_serial_probe`
serial: 8250: Document termios parameter of serial8250_em485_config()
serial: Add support for Advantech PCI-1611U card
serial: 8250_exar: Add support for USR298x PCI Modems
Here are some USB fixes for 6.4-rc3, as well as a driver core fix that
resolves a memory leak that shows up in USB devices easier than other
subsystems.
Included in here are:
- driver core memory leak as reported and tested by syzbot and
developers
- dwc3 driver fixes for reported problems
- xhci driver fixes for reported problems
- USB gadget driver reverts to resolve regressions
- usbtmc driver fix for syzbot reported problem
- thunderbolt driver fixes for reported issues
- other small USB fixes
All of these, except for the driver core fix, have been in linux-next
with no reported problems. The driver core fix was tested and verified
to solve the issue by syzbot and the original reporter.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZGj97Q8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynhBQCgmc/r5Kx4qBWrf32w6LbGzLC1KDUAoI79Ix7g
7SEM1fqaTWgnCC3gl/cB
=6AOH
-----END PGP SIGNATURE-----
Merge tag 'usb-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt fixes from Greg KH:
"Here are some USB fixes for 6.4-rc3, as well as a driver core fix that
resolves a memory leak that shows up in USB devices easier than other
subsystems.
Included in here are:
- driver core memory leak as reported and tested by syzbot and
developers
- dwc3 driver fixes for reported problems
- xhci driver fixes for reported problems
- USB gadget driver reverts to resolve regressions
- usbtmc driver fix for syzbot reported problem
- thunderbolt driver fixes for reported issues
- other small USB fixes
All of these, except for the driver core fix, have been in linux-next
with no reported problems. The driver core fix was tested and verified
to solve the issue by syzbot and the original reporter"
* tag 'usb-6.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
driver core: class: properly reference count class_dev_iter()
xhci: Fix incorrect tracking of free space on transfer rings
xhci-pci: Only run d3cold avoidance quirk for s2idle
usb-storage: fix deadlock when a scsi command timeouts more than once
usb: dwc3: fix a test for error in dwc3_core_init()
usb: typec: tps6598x: Fix fault at module removal
usb: gadget: u_ether: Fix host MAC address case
usb: typec: altmodes/displayport: fix pin_assignment_show
Revert "usb: gadget: udc: core: Invoke usb_gadget_connect only when started"
Revert "usb: gadget: udc: core: Prevent redundant calls to pullup"
usb: gadget: drop superfluous ':' in doc string
usb: dwc3: debugfs: Resume dwc3 before accessing registers
USB: UHCI: adjust zhaoxin UHCI controllers OverCurrent bit value
usb: dwc3: fix gadget mode suspend interrupt handler issue
usb: dwc3: gadget: Improve dwc3_gadget_suspend() and dwc3_gadget_resume()
USB: usbtmc: Fix direction for 0-length ioctl control messages
thunderbolt: Clear registers properly when auto clear isn't in use
[ cmllamas: clean forward port from commit 015ac18be7de ("binder: fix
UAF of alloc->vma in race with munmap()") in 5.10 stable. It is needed
in mainline after the revert of commit a43cfc87caaf ("android: binder:
stop saving a pointer to the VMA") as pointed out by Liam. The commit
log and tags have been tweaked to reflect this. ]
In commit 720c24192404 ("ANDROID: binder: change down_write to
down_read") binder assumed the mmap read lock is sufficient to protect
alloc->vma inside binder_update_page_range(). This used to be accurate
until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap"), which now downgrades the mmap_lock after detaching the vma
from the rbtree in munmap(). Then it proceeds to teardown and free the
vma with only the read lock held.
This means that accesses to alloc->vma in binder_update_page_range() now
will race with vm_area_free() in munmap() and can cause a UAF as shown
in the following KASAN trace:
==================================================================
BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0
Read of size 8 at addr ffff16204ad00600 by task server/558
CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x2a0
show_stack+0x18/0x2c
dump_stack+0xf8/0x164
print_address_description.constprop.0+0x9c/0x538
kasan_report+0x120/0x200
__asan_load8+0xa0/0xc4
vm_insert_page+0x7c/0x1f0
binder_update_page_range+0x278/0x50c
binder_alloc_new_buf+0x3f0/0xba0
binder_transaction+0x64c/0x3040
binder_thread_write+0x924/0x2020
binder_ioctl+0x1610/0x2e5c
__arm64_sys_ioctl+0xd4/0x120
el0_svc_common.constprop.0+0xac/0x270
do_el0_svc+0x38/0xa0
el0_svc+0x1c/0x2c
el0_sync_handler+0xe8/0x114
el0_sync+0x180/0x1c0
Allocated by task 559:
kasan_save_stack+0x38/0x6c
__kasan_kmalloc.constprop.0+0xe4/0xf0
kasan_slab_alloc+0x18/0x2c
kmem_cache_alloc+0x1b0/0x2d0
vm_area_alloc+0x28/0x94
mmap_region+0x378/0x920
do_mmap+0x3f0/0x600
vm_mmap_pgoff+0x150/0x17c
ksys_mmap_pgoff+0x284/0x2dc
__arm64_sys_mmap+0x84/0xa4
el0_svc_common.constprop.0+0xac/0x270
do_el0_svc+0x38/0xa0
el0_svc+0x1c/0x2c
el0_sync_handler+0xe8/0x114
el0_sync+0x180/0x1c0
Freed by task 560:
kasan_save_stack+0x38/0x6c
kasan_set_track+0x28/0x40
kasan_set_free_info+0x24/0x4c
__kasan_slab_free+0x100/0x164
kasan_slab_free+0x14/0x20
kmem_cache_free+0xc4/0x34c
vm_area_free+0x1c/0x2c
remove_vma+0x7c/0x94
__do_munmap+0x358/0x710
__vm_munmap+0xbc/0x130
__arm64_sys_munmap+0x4c/0x64
el0_svc_common.constprop.0+0xac/0x270
do_el0_svc+0x38/0xa0
el0_svc+0x1c/0x2c
el0_sync_handler+0xe8/0x114
el0_sync+0x180/0x1c0
[...]
==================================================================
To prevent the race above, revert back to taking the mmap write lock
inside binder_update_page_range(). One might expect an increase of mmap
lock contention. However, binder already serializes these calls via top
level alloc->mutex. Also, there was no performance impact shown when
running the binder benchmark tests.
Fixes: c0fd2101781e ("Revert "android: binder: stop saving a pointer to the VMA"")
Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
Reported-by: Jann Horn <jannh@google.com>
Closes: https://lore.kernel.org/all/20230518144052.xkj6vmddccq4v66b@revolver
Cc: <stable@vger.kernel.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Yang Shi <yang.shi@linux.alibaba.com>
Cc: Liam Howlett <liam.howlett@oracle.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20230519195950.1775656-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The NFL4_UFLG_MASK define slipped in in commit 9208d4149758
("block: add a ->get_unique_id method") and should never have been
added, as NFSD as the only user of it already has it's copy.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230520090010.527046-1-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- Fix compiler warnings on btnxpuart
- Fix potential double free on hci_conn_unlink
- Fix UAF on hci_conn_hash_flush
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE7E6oRXp8w05ovYr/9JCA4xAyCykFAmRoBgIZHGx1aXoudm9u
LmRlbnR6QGludGVsLmNvbQAKCRD0kIDjEDILKc9RD/47PfJj6p/dn6WTthegoZ7K
BK0cC4j2H2LBbt4UzGA7BWdGxiJnguahsap09jq3t1hB/9ggXPMbA/4674A58+RM
iYt6u5/uZCPmVyp5P6YVyFIHv4xM/ruQ3wr8/32AscW066Jp/M8TJ0qTOLQpc+qp
jkg2xdKMNj1sYzA3reR/oWiWXQR2qJVlHLMq5namZr04B4mj6+2HyaS8+hjVIwku
VW9g/8fi9FfikdyRfYPNzHuV9C97sP6zvPqKbrxlEk5f1TLfbY9lFqRUgvAL7bco
fT3ddDqpw/3cMP7b8MKbDB0aS+rt4fT6g83Qtfyeps1cauCMoCeHFIqAfmGQtNTx
qO7q/fG7sOSFlfyiwbwHTYxYV8z4ABavrRF4lbvIqt9kh7Xuow87rcgrTBmX7nXE
TUMzeCv/SSQP8k1+O4XNwzUf8XiL6XsbMYmgGRLB8IO+S8QXEDLUelhcCrahq9Pd
FQ3v4Op1vY6YiTP12iaxzYb82OqdU8Th6PpOGjdjPw/7UQiJaItaX8YKDfw8h/d0
XDxHbXvWIORegvMHGuXvjUYDVTTTmAvvuPs5nde9rXgMxTmvzN9e7Srbpb6I0nv4
R5nKiZjnugVaZ9lFimLlj8Bh9/KavpT/41MnF9Oe/XzCfcTVnxthWYJ6kN5Zscof
o8bd8Q4c1F3x6rW7DFMLTQ==
=v45m
-----END PGP SIGNATURE-----
Merge tag 'for-net-2023-05-19' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Luiz Augusto von Dentz says:
====================
bluetooth pull request for net:
- Fix compiler warnings on btnxpuart
- Fix potential double free on hci_conn_unlink
- Fix UAF on hci_conn_hash_flush
* tag 'for-net-2023-05-19' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth:
Bluetooth: btnxpuart: Fix compiler warnings
Bluetooth: Unlink CISes when LE disconnects in hci_conn_del
Bluetooth: Fix UAF in hci_conn_hash_flush again
Bluetooth: Refcnt drop must be placed last in hci_conn_unlink
Bluetooth: Fix potential double free caused by hci_conn_unlink
====================
Link: https://lore.kernel.org/r/20230519233056.2024340-1-luiz.dentz@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When the virtual interface's feature is updated, it synchronizes the
updated feature for its own lower interface.
This propagation logic should be worked as the iteration, not recursively.
But it works recursively due to the netdev notification unexpectedly.
This problem occurs when it disables LRO only for the team and bonding
interface type.
team0
|
+------+------+-----+-----+
| | | | |
team1 team2 team3 ... team200
If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGE
event to its own lower interfaces(team1 ~ team200).
It is worked by netdev_sync_lower_features().
So, the NETDEV_FEAT_CHANGE notification logic of each lower interface
work iteratively.
But generated NETDEV_FEAT_CHANGE event is also sent to the upper
interface too.
upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own
lower interfaces again.
lower and upper interfaces receive this event and generate this
event again and again.
So, the stack overflow occurs.
But it is not the infinite loop issue.
Because the netdev_sync_lower_features() updates features before
generating the NETDEV_FEAT_CHANGE event.
Already synchronized lower interfaces skip notification logic.
So, it is just the problem that iteration logic is changed to the
recursive unexpectedly due to the notification mechanism.
Reproducer:
ip link add team0 type team
ethtool -K team0 lro on
for i in {1..200}
do
ip link add team$i master team0 type team
ethtool -K team$i lro on
done
ethtool -K team0 lro off
In order to fix it, the notifier_ctx member of bonding/team is introduced.
Reported-by: syzbot+60748c96cf5c6df8e581@syzkaller.appspotmail.com
Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://lore.kernel.org/r/20230517143010.3596250-1-ap420073@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The syzbot fuzzer detected a problem in the udlfb driver, caused by an
endpoint not having the expected type:
usb 1-1: Read EDID byte 0 failed: -71
usb 1-1: Unable to get valid EDID from device/display
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880
drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted
6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
04/28/2023
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
<TASK>
dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980
dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315
dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111
dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743
The current approach for this issue failed to catch the problem
because it only checks for the existence of a bulk-OUT endpoint; it
doesn't check whether this endpoint is the one that the driver will
actually use.
We can fix the problem by instead checking that the endpoint used by
the driver does exist and is bulk-OUT.
Reported-and-tested-by: syzbot+0e22d63dcebb802b9bc8@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Pavel Skripkin <paskripkin@gmail.com>
Fixes: aaf7dbe07385 ("video: fbdev: udlfb: properly check endpoint type")
Signed-off-by: Helge Deller <deller@gmx.de>
