Export symbol invalid_pud_table for modules building (such as the KVM
module) if 4-level page tables enabled. Otherwise we get:
ERROR: modpost: "invalid_pud_table" [arch/loongarch/kvm/kvm.ko] undefined!
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
As described in include/linux/linkage.h,
FUNC -- C-like functions (proper stack frame etc.)
CODE -- non-C code (e.g. irq handlers with different, special stack etc.)
SYM_FUNC_{START, END} -- use for global functions
SYM_CODE_{START, END} -- use for non-C (special) functions
So use SYM_CODE_* to annotate exception handlers.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Add a suite covering the fdb_n_learned and fdb_max_learned bridge
features, touching all special cases in accounting at least once.
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-5-32cddff87758@avm.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Set any new attributes added to br_policy to be parsed strictly, to
prevent userspace from passing garbage.
Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-4-32cddff87758@avm.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The previous patch added accounting and a limit for the number of
dynamically learned FDB entries per bridge. However it did not provide
means to actually configure those bounds or read back the count. This
patch does that.
Two new netlink attributes are added for the accounting and limit of
dynamically learned FDB entries:
- IFLA_BR_FDB_N_LEARNED (RO) for the number of entries accounted for
a single bridge.
- IFLA_BR_FDB_MAX_LEARNED (RW) for the configured limit of entries for
the bridge.
The new attributes are used like this:
# ip link add name br up type bridge fdb_max_learned 256
# ip link add name v1 up master br type veth peer v2
# ip link set up dev v2
# mausezahn -a rand -c 1024 v2
0.01 seconds (90877 packets per second
# bridge fdb | grep -v permanent | wc -l
256
# ip -d link show dev br
13: br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 [...]
[...] fdb_n_learned 256 fdb_max_learned 256
Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-3-32cddff87758@avm.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A malicious actor behind one bridge port may spam the kernel with packets
with a random source MAC address, each of which will create an FDB entry,
each of which is a dynamic allocation in the kernel.
There are roughly 2^48 different MAC addresses, further limited by the
rhashtable they are stored in to 2^31. Each entry is of the type struct
net_bridge_fdb_entry, which is currently 128 bytes big. This means the
maximum amount of memory allocated for FDB entries is 2^31 * 128B =
256GiB, which is too much for most computers.
Mitigate this by maintaining a per bridge count of those automatically
generated entries in fdb_n_learned, and a limit in fdb_max_learned. If
the limit is hit new entries are not learned anymore.
For backwards compatibility the default setting of 0 disables the limit.
User-added entries by netlink or from bridge or bridge port addresses
are never blocked and do not count towards that limit.
Introduce a new fdb entry flag BR_FDB_DYNAMIC_LEARNED to keep track of
whether an FDB entry is included in the count. The flag is enabled for
dynamically learned entries, and disabled for all other entries. This
should be equivalent to BR_FDB_ADDED_BY_USER and BR_FDB_LOCAL being unset,
but contrary to the two flags it can be toggled atomically.
Atomicity is required here, as there are multiple callers that modify the
flags, but are not under a common lock (br_fdb_update is the exception
for br->hash_lock, br_fdb_external_learn_add for RTNL).
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-2-32cddff87758@avm.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In preparation of the following fdb limit for dynamically learned entries,
allow fdb_create to detect that the entry was added by the user. This
way it can skip applying the limit in this case.
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-1-32cddff87758@avm.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eliminate DRM_SCHED_PRIORITY_UNSET, value of -2, whose only user was
amdgpu. Furthermore, eliminate an index bug, in that when amdgpu boots, it
calls drm_sched_entity_init() with DRM_SCHED_PRIORITY_UNSET, which uses it to
index sched->sched_rq[].
Cc: Alex Deucher <Alexander.Deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
Acked-by: Alex Deucher <Alexander.Deucher@amd.com>
Link: https://lore.kernel.org/r/20231017035656.8211-2-luben.tuikov@amd.com
A context priority value of AMD_CTX_PRIORITY_UNSET is now invalid--instead of
carrying it around and passing it to the Direct Rendering Manager--and it
becomes AMD_CTX_PRIORITY_NORMAL in amdgpu_ctx_ioctl(), the gateway to context
creation.
Cc: Alex Deucher <Alexander.Deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
Acked-by: Alex Deucher <Alexander.Deucher@amd.com>
Link: https://lore.kernel.org/r/20231017035656.8211-1-luben.tuikov@amd.com
We discovered from packet traces of slow loss recovery on kernels with
the default HZ=250 setting (and min_rtt < 1ms) that after reordering,
when receiving a SACKed sequence range, the RACK reordering timer was
firing after about 16ms rather than the desired value of roughly
min_rtt/4 + 2ms. The problem is largely due to the RACK reorder timer
calculation adding in TCP_TIMEOUT_MIN, which is 2 jiffies. On kernels
with HZ=250, this is 2*4ms = 8ms. The TLP timer calculation has the
exact same issue.
This commit fixes the TLP transmit timer and RACK reordering timer
floor calculation to more closely match the intended 2ms floor even on
kernels with HZ=250. It does this by adding in a new
TCP_TIMEOUT_MIN_US floor of 2000 us and then converting to jiffies,
instead of the current approach of converting to jiffies and then
adding th TCP_TIMEOUT_MIN value of 2 jiffies.
Our testing has verified that on kernels with HZ=1000, as expected,
this does not produce significant changes in behavior, but on kernels
with the default HZ=250 the latency improvement can be large. For
example, our tests show that for HZ=250 kernels at low RTTs this fix
roughly halves the latency for the RACK reorder timer: instead of
mostly firing at 16ms it mostly fires at 8ms.
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Fixes: bb4d991a28 ("tcp: adjust tail loss probe timeout")
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20231015174700.2206872-1-ncardwell.sw@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
various minor fixes, cleanups and annotations for atyfb, sa1100fb,
omapfb, uvesafb and mmp.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZS7h/AAKCRD3ErUQojoP
X041AQCov386rrMGpY3v4qmU2X0EIAeQjlgs8hElA3YWIWyg2gEA3bt/PFvod8wV
Vhl9gQQJropICSb1zbUZ0aa0rhil6QQ=
=5LoM
-----END PGP SIGNATURE-----
Merge tag 'fbdev-for-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev
Pull fbdev fixes and cleanups from Helge Deller:
"Various minor fixes, cleanups and annotations for atyfb, sa1100fb,
omapfb, uvesafb and mmp"
* tag 'fbdev-for-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev:
fbdev: core: syscopyarea: fix sloppy typing
fbdev: core: cfbcopyarea: fix sloppy typing
fbdev: uvesafb: Call cn_del_callback() at the end of uvesafb_exit()
fbdev: uvesafb: Remove uvesafb_exec() prototype from include/video/uvesafb.h
fbdev: sa1100fb: mark sa1100fb_init() static
fbdev: omapfb: fix some error codes
fbdev: atyfb: only use ioremap_uc() on i386 and ia64
fbdev: mmp: Annotate struct mmp_path with __counted_by
fbdev: mmp: Annotate struct mmphw_ctrl with __counted_by
The second pull request for v6.7, with only driver changes this time.
We have now support for mt7925 PCIe and USB variants, few new features
and of course some fixes.
Major changes:
mt76
* mt7925 support
ath12k
* read board data variant name from SMBIOS
wfx
* Remain-On-Channel (ROC) support
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmUtSjcRHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZu3CQf/ed0tYeZy/X6lBf1ZvFzB2upEEnY7bPXt
PGKASGQVf0livFfwGI4o1YDI53e1fL58CdNam8CY496g7JzuRBaaOZ8jpSuYHQ36
M5MsF7kI+k/5ja560qgn6CRJEyU89zKqGwiQUuvhPsSsCRE/VdMhGPdWKzUyBoon
djuZQu1hayOCAuMk29TScvYisWbdUF9hKfqYBmz4xTnR5oBczP/qyknT/19pdNZZ
6fyAcBJcTUzgASRcKYAejm1wQ6RUUS+wbqH1U2xjH6RyzCFEm0iSzF3wko7VHiiA
f6T136N6aokMp+a/nfnxX+WNzBlhEF+IOKEw2QJs26fNipERwTpakw==
=FIFP
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2023-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.7
The second pull request for v6.7, with only driver changes this time.
We have now support for mt7925 PCIe and USB variants, few new features
and of course some fixes.
Major changes:
mt76
- mt7925 support
ath12k
- read board data variant name from SMBIOS
wfx
- Remain-On-Channel (ROC) support
* tag 'wireless-next-2023-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (109 commits)
wifi: rtw89: mac: do bf_monitor only if WiFi 6 chips
wifi: rtw89: mac: set bf_assoc capabilities according to chip gen
wifi: rtw89: mac: set bfee_ctrl() according to chip gen
wifi: rtw89: mac: add registers of MU-EDCA parameters for WiFi 7 chips
wifi: rtw89: mac: generalize register of MU-EDCA switch according to chip gen
wifi: rtw89: mac: update RTS threshold according to chip gen
wifi: rtlwifi: simplify TX command fill callbacks
wifi: hostap: remove unused ioctl function
wifi: atmel: remove unused ioctl function
wifi: rtw89: coex: add annotation __counted_by() to struct rtw89_btc_btf_set_mon_reg
wifi: rtw89: coex: add annotation __counted_by() for struct rtw89_btc_btf_set_slot_table
wifi: rtw89: add EHT radiotap in monitor mode
wifi: rtw89: show EHT rate in debugfs
wifi: rtw89: parse TX EHT rate selected by firmware from RA C2H report
wifi: rtw89: Add EHT rate mask as parameters of RA H2C command
wifi: rtw89: parse EHT information from RX descriptor and PPDU status packet
wifi: radiotap: add bandwidth definition of EHT U-SIG
wifi: rtlwifi: use convenient list_count_nodes()
wifi: p54: Annotate struct p54_cal_database with __counted_by
wifi: brcmfmac: fweh: Add __counted_by for struct brcmf_fweh_queue_item and use struct_size()
...
====================
Link: https://lore.kernel.org/r/20231016143822.880D8C433C8@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Don't apply the stimer's counter side effects when modifying its
value from user-space, as this may trigger spurious interrupts.
For example:
- The stimer is configured in auto-enable mode.
- The stimer's count is set and the timer enabled.
- The stimer expires, an interrupt is injected.
- The VM is live migrated.
- The stimer config and count are deserialized, auto-enable is ON, the
stimer is re-enabled.
- The stimer expires right away, and injects an unwarranted interrupt.
Cc: stable@vger.kernel.org
Fixes: 1f4b34f825 ("kvm/x86: Hyper-V SynIC timers")
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/20231017155101.40677-1-nsaenz@amazon.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Update the variable with name 'kvm' in kvm_x86_ops.sched_in() to 'vcpu' to
avoid confusions. Variable naming in KVM has a clear convention that 'kvm'
refers to pointer of type 'struct kvm *', while 'vcpu' refers to pointer of
type 'struct kvm_vcpu *'.
Fix this 9-year old naming issue for fun.
Signed-off-by: Mingwei Zhang <mizhang@google.com>
Link: https://lore.kernel.org/r/20231017232610.4008690-1-mizhang@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Avoid the costs of integer division (32-bit and 64-bit) if the realtime
extent size is a power of two.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Replace these macros with typechecked helper functions. Eventually
we're going to add more logic to the helpers and it'll be easier if we
don't have to macro it up.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Create a pair of functions to round rtblock numbers up or down to the
nearest rt extent.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Convert these calls to use the helpers, and clean up all these places
where the same variable can have different units depending on where it
is in the function.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Further disambiguate the xfs_rtblock_t uses by creating a new type,
xfs_rtxnum_t, to store the position of an extent within the realtime
section, in units of rtextents.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Create helpers to do unit conversions of rt block numbers to rt extent
numbers. There are three variations -- one to compute the rt extent
number from an rt block number; one to compute the offset of an rt block
within an rt extent; and one to extract both.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
This helper function validates that a range of *blocks* in the
realtime section is completely contained within the realtime section.
It does /not/ validate ranges of *rtextents*. Rename the function to
avoid suggesting that it does, and change the type of the @len parameter
since xfs_rtblock_t is a position unit, not a length unit.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Create a helper to compute the realtime extent (xfs_rtxlen_t) from an
extent length (xfs_extlen_t) value.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
XFS uses xfs_rtblock_t for many different uses, which makes it much more
difficult to perform a unit analysis on the codebase. One of these
(ab)uses is when we need to store the length of a free space extent as
stored in the realtime bitmap. Because there can be up to 2^64 realtime
extents in a filesystem, we need a new type that is larger than
xfs_rtxlen_t for callers that are querying the bitmap directly. This
means scrub and growfs.
Create this type as "xfs_rtbxlen_t" and use it to store 64-bit rtx
lengths. 'b' stands for 'bitmap' or 'big'; reader's choice.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Create a helper to compute the misalignment between a file extent
(xfs_extlen_t) and a realtime extent.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
We should use xfs_fileoff_t to store the file block offset of any
location within the realtime bitmap or summary files.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Create a helper to convert a realtime extent to a realtime block. Later
on we'll change the helper to use bit shifts when possible.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
In most of the filesystem, we use xfs_extlen_t to store the length of a
file (or AG) space mapping in units of fs blocks. Unfortunately, the
realtime allocator also uses it to store the length of a rt space
mapping in units of rt extents. This is confusing, since one rt extent
can consist of many fs blocks.
Separate the two by introducing a new type (xfs_rtxlen_t) to store the
length of a space mapping (in units of realtime extents) that would be
found in a file.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Move all the declarations for functionality in xfs_rtbitmap.c into a
separate xfs_rtbitmap.h header file.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
In commit 2a6ca4baed, we tried to fix an overflow problem in the
realtime allocator that was caused by an overly large maxlen value
causing xfs_rtcheck_range to run off the end of the realtime bitmap.
Unfortunately, there is a subtle bug here -- maxlen (and minlen) both
have to be aligned with @prod, but @prod can be larger than 1 if the
user has set an extent size hint on the file, and that extent size hint
is larger than the realtime extent size.
If the rt free space extents are not aligned to this file's extszhint
because other files without extent size hints allocated space (or the
number of rt extents is similarly not aligned), then it's possible that
maxlen after clamping to sb_rextents will no longer be aligned to prod.
The allocation will succeed just fine, but we still trip the assertion.
Fix the problem by reducing maxlen by any misalignment with prod. While
we're at it, split the assertions into two so that we can tell which
value had the bad alignment.
Fixes: 2a6ca4baed ("xfs: make sure the rt allocator doesn't run off the end")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
The unit conversions in this function do not make sense. First we
convert a block count to bytes, then divide that bytes value by
rextsize, which is in blocks, to get an rt extent count. You can't
divide bytes by blocks to get a (possibly multiblock) extent value.
Fortunately nobody uses delalloc on the rt volume so this hasn't
mattered.
Fixes: fa5c836ca8 ("xfs: refactor xfs_bunmapi_cow")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
When realtime support is not compiled into the kernel, these functions
should return negative errnos, not positive errnos. While we're at it,
fix a broken macro declaration.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Quotas aren't (yet) supported with realtime, so we shouldn't allow
userspace to set up a realtime section when quotas are enabled, even if
they attached one via mount options. IOWS, you shouldn't be able to do:
# mkfs.xfs -f /dev/sda
# mount /dev/sda /mnt -o rtdev=/dev/sdb,usrquota
# xfs_growfs -r /mnt
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Device specific bindings should not allow undefined properties. This is
accomplished in json-schema with 'additionalProperties: false'.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Sachin reported a warning when running the inject-ra-err selftest:
# selftests: powerpc/mce: inject-ra-err
Disabling lock debugging due to kernel taint
MCE: CPU19: machine check (Severe) Real address Load/Store (foreign/control memory) [Not recovered]
MCE: CPU19: PID: 5254 Comm: inject-ra-err NIP: [0000000010000e48]
MCE: CPU19: Initiator CPU
MCE: CPU19: Unknown
------------[ cut here ]------------
WARNING: CPU: 19 PID: 5254 at arch/powerpc/mm/book3s64/radix_tlb.c:1221 radix__tlb_flush+0x160/0x180
CPU: 19 PID: 5254 Comm: inject-ra-err Kdump: loaded Tainted: G M E 6.6.0-rc3-00055-g9ed22ae6be81 #4
Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1030.20 (NH1030_058) hv:phyp pSeries
...
NIP radix__tlb_flush+0x160/0x180
LR radix__tlb_flush+0x104/0x180
Call Trace:
radix__tlb_flush+0xf4/0x180 (unreliable)
tlb_finish_mmu+0x15c/0x1e0
exit_mmap+0x1a0/0x510
__mmput+0x60/0x1e0
exit_mm+0xdc/0x170
do_exit+0x2bc/0x5a0
do_group_exit+0x4c/0xc0
sys_exit_group+0x28/0x30
system_call_exception+0x138/0x330
system_call_vectored_common+0x15c/0x2ec
And bisected it to commit e43c0a0c3c ("powerpc/64s/radix: combine
final TLB flush and lazy tlb mm shootdown IPIs"), which added a warning
in radix__tlb_flush() if mm->context.copros is still elevated.
However it's possible for the copros count to be elevated if a process
exits without first closing file descriptors that are associated with a
copro, eg. VAS.
If the process exits with a VAS file still open, the release callback
is queued up for exit_task_work() via:
exit_files()
put_files_struct()
close_files()
filp_close()
fput()
And called via:
exit_task_work()
____fput()
__fput()
file->f_op->release(inode, file)
coproc_release()
vas_user_win_ops->close_win()
vas_deallocate_window()
mm_context_remove_vas_window()
mm_context_remove_copro()
But that is after exit_mm() has been called from do_exit() and triggered
the warning.
Fix it by dropping the warning, and always calling __flush_all_mm().
In the normal case of no copros, that will result in a call to
_tlbiel_pid(mm->context.id, RIC_FLUSH_ALL) just as the current code
does.
If the copros count is elevated then it will cause a global flush, which
should flush translations from any copros. Note that the process table
entry was cleared in arch_exit_mmap(), so copros should not be able to
fetch any new translations.
Fixes: e43c0a0c3c ("powerpc/64s/radix: combine final TLB flush and lazy tlb mm shootdown IPIs")
Reported-by: Sachin Sant <sachinp@linux.ibm.com>
Closes: https://lore.kernel.org/all/A8E52547-4BF1-47CE-8AEA-BC5A9D7E3567@linux.ibm.com/
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Sachin Sant <sachinp@linux.ibm.com>
Link: https://msgid.link/20231017121527.1574104-1-mpe@ellerman.id.au
This version addresses issues with:
- When CPU 0 hotplug is not possible, try cgroup v2 isolation
without any user input
- Fix turbo mode enable/disable swapped
- Sanitize command line integer and hex arguments
- Add more error messages
- Increase CPU count in one request
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Building with GCC 11.x results in the following warning:
arch/x86/kernel/cpu/microcode/amd.c: In function ‘find_blobs_in_containers’:
arch/x86/kernel/cpu/microcode/amd.c:504:58: error: ‘h.bin’ directive output may be truncated writing 5 bytes into a region of size between 1 and 7 [-Werror=format-truncation=]
arch/x86/kernel/cpu/microcode/amd.c:503:17: note: ‘snprintf’ output between 35 and 41 bytes into a destination of size 36
The issue is that GCC does not know that the family can only be a byte
(it ultimately comes from CPUID). Suggest the right size to the compiler
by marking the argument as char-size ("hh"). While at it, instead of
using the slightly more obscure precision specifier use the width with
zero padding (over 23000 occurrences in kernel sources, vs 500 for
the idiom using the precision).
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Closes: https://lore.kernel.org/oe-kbuild-all/202308252255.2HPJ6x5Q-lkp@intel.com/
Link: https://lore.kernel.org/r/20231016224858.2829248-1-pbonzini@redhat.com
- add various drivers for Amlogic based boards
- KEYBOARD_GPIO_POLLED=m used to support buttons on pre-G12A boards
- KHADAS_MCU_FAN_THERMAL=m & MFD_KHADAS_MCU=m to control FAN over the MCU on Khadas VIM boards
- MEDIA_CEC_SUPPORT=y & CEC_MESON_G12A_AO=m to enable the CEC bus
- RTC_DRV_PCF8563=m to enable support for RTC on most SBC boards
- VIDEO_MESON_VDEC=m to enable HW Video Decoder
- MESON_DDR_PMU=m to enable DDR PMU perf driver on G12A & SM1 SoCs
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPVPGJshWBf4d9CyLd9zb2sjISdEFAmUs9FsACgkQd9zb2sjI
SdHDtw//dmJ/uEinGJdn1Ub081qgIzaDQ4qhOtnFXBnt/NtNplMMVVqgEcrdzkjq
c5H03X//51yxdBEm7R1oNXXjvHTIZ5G9WQptLpikw62Qr1aLKA3KnhpVVKYo3ELd
5rSmkfEcLtp40heiSHaikx+Uj6zJQRFGORMsRCYaWKaedkMcNRItg37SNlZGywOf
pFB+eSqNQw2k4UjYz2qO88WlUv77kUYkG/WzVr+9K1c3K1VWt9iwFFlUZhnK9dVn
Vh99/Ma7JO3ZSDdbriVT3h4hDgKOJBC9Zwt7io30P4WkVB+MY0PnrT+0UFnGn558
RMisSYnf9mxRw6krGW4rKcF9eigWylJfler/xAK+h6jg/i7/cdO0o7LHzBxcRUFC
P7mLBJUTUKYCn3RRKNE16wq0S/3lM1gEszzTBctoFyLwMbnzhUxox4+r8gnPZlZl
8cHL9L6NXZ/2kGBJBWj1lHypkgLQgQYxxXfXjqK+1qpDlyR6lz94Wgk+gdMKmaLY
BW/5ZG76odgKZDxb4nyioNSV1YlcxPE6zvqi5gIa2t5o752X3UZLnbZ4YRPIWjD0
hC7ihyeXCy6vlEDOr4KUBGZS0nNaZorU2CWHr5n27dImBZ7KKQnrvDjgmHTfdHGo
5GgUoQC6H57WAlJS+wx6+MNGhhXUo2Y1dPMHcvMUCxSqXD0/GYM=
=dyV8
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUu+oAACgkQYKtH/8kJ
UiehghAAlGTAQXqStNS4kFuXwDKkDgHErTmwS995YK9QH9h9CSH3I6tjohpYc5gp
zopY7o/rpXzCRLBHaRUn9efbI7wjXZwFSLkW3jJbwDVUM7/SVitUBEA9PXstplV8
VVze/9nlcyiqI5yXR8KIoUnrsL9ImFpmbXK/NJFKAHoJM7S7nuqir4uFCe8lrGRo
hLEeCe5clGxaM+dwQzJucVNCDIUEFEfXPYo8IdKF42jk+s3zjUSVamXMfGSfJZJb
2OFA2FIEtfmoR9FWQC/0Z7wQBHYbhHK42vQyRN2iSnIhQLwmw6QdYGjBxlmvD12N
vhMGUcBRof4MSKV89JrFFQ+6xMPK9nwPC0JbVcN/yq+IQCcLW4puSz9HScFaBj7g
HdRTvMsx4z1Dq2V+G7ICbMKqRh7HGOVRnbIj67JY/nxYI5pgODUAYtVgB64jBkW7
dVxz2WX82NGxSnfLOytJprJjEU5Uz+Y4KSEic1WL6/yqrAqfF+rIdRy0Zx29bAmU
wEWhH/5k8lWTg2siseLojQ4DFbJShRHEED1WeTBh6iUgEyFpM3RVpo7aDUln0ujT
R8SnlX4nqaQu4Esh5xK8oGZFJjdL5HMQCIbfuaiP5HbbbFP8fdixtcj07C2E3lsJ
sg9rZu3x0/anUCyS7hVlYwzshvmRksoRP+rnsw+8IC9n6spm0AI=
=1hSh
-----END PGP SIGNATURE-----
Merge tag 'amlogic-defconfig-for-v6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/defconfig
Amlogic defconfig changes for v6.7:
- add various drivers for Amlogic based boards
- KEYBOARD_GPIO_POLLED=m used to support buttons on pre-G12A boards
- KHADAS_MCU_FAN_THERMAL=m & MFD_KHADAS_MCU=m to control FAN over the MCU on Khadas VIM boards
- MEDIA_CEC_SUPPORT=y & CEC_MESON_G12A_AO=m to enable the CEC bus
- RTC_DRV_PCF8563=m to enable support for RTC on most SBC boards
- VIDEO_MESON_VDEC=m to enable HW Video Decoder
- MESON_DDR_PMU=m to enable DDR PMU perf driver on G12A & SM1 SoCs
* tag 'amlogic-defconfig-for-v6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux:
arm64: defconfig: add various drivers for Amlogic based boards
Link: https://lore.kernel.org/r/2e08bd06-09e0-4352-8207-bc3b5d26fba4@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enable several drivers for boards with Samsung Exynos ARM SoCs in
exynos_defconfig and multi_v7_defconfig: display PHYs, AHCI DWC, TM2
touchkey (used on ARM and ARM64 Exynos-based boards), Samsung camera
sensors and Intersil 29018 light sensor.
Enable also IIO in s5pv210_defconfig used by MAX17040 fuel gauge driver.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmUs5ekQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD14ZCD/4xfhz0I89lqfAvn38PfSZ/DbTacubF329v
5fA57vvEAr4YPYcSOC9DfNJoAoYST1kup85DEfXltF0fOH5yWc3/JabcrgWyzCiq
TARq+C9ImtqzINNIzG3y5xzeD/1h5fZr5JtTuqNIoDG32yByQeemM1pTBSgiz4I4
93H642P63mXvdify2pPfNmIAp4YSqcPWdkyfsB7CRfyFa5MsdS9GhdXSfsyJMyzO
WbteXGyzu/sA962A2XEOLo+FtvWLyFNoxVizK6YO4y6p9J7v687u2PfUDYZBj4SM
GvbqEShAFPIy9V8xseX43RsDdx/FFjIkiyl1qELn9r3B7bmiDXj1iSf1S2XGYtjV
3CeL4tvlSnhVpmDboOdsxnCbkDagp2v6bt5FL/BiT1cEK9Re+5HdmfCODlrjmqoz
oXQJ5lXEaE3aRZArD866JLn+WVaszp64lUIRuQ7+uyd+BVI2jeTkuGa2sETsDTi/
Cvc85dOAuFJ15SsiGRfurhNZhOzO0upXtBb9gKqG0DsrcDhJ+x8WeOhriHDmP3TJ
C6KLbUoHSAb1pr8nd09f8mpkYA0emJxofmXblFXY8YDEW8HsEQf7aldHehJ+hESm
SiKwwr59whdcV4A+N6BeZ/UG6znkT6Azld9j/3nT2VueZ6k39+hC5ygjrbAPk+Yg
tKA3B0eS/A==
=5Fqw
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUu+jwACgkQYKtH/8kJ
Uicz6BAAq8mhoQA7vBJqz6CA8ZITMpqEKxVTHn4ThduP34WIG8tOh1R0ftkdY2OX
5Zk0PZTPNrt1SN8mX0UBbYjJEn/a7yBLq9u8Aj7EWA+0Mt08zQ5x2JX5cnE0Sdcy
SPbTe3LwjYew5v6K/a/N4ic0UoCSYxUGKz10hQu8NIn0rX/oj8i6X9okcg+klxt+
A3jzKRPawmssE5n74SUNfYGkT2xHmF3RSKq1Nm4/Y20mxvk581IX3ArDuczhEjh5
nf6yrP0m+4mDyjo3AYjnWvW7g9vth05kYTXGWU32EPVKVuYw5XbagvH/C9MG1oy5
r0/zz72+/rkPC9SlaZnQMOAcqNRHPVSO/2QBaykEkfbrgnXAoatzG59E6TcJy8nQ
k5wGxC/LjytrFCVp23fgqrog777m5l3qlHA+d7QlvusKAmY3QmACVECpPAJTaZMy
km1C1UVc7KcVYA88UZCYP0SeKirzzUnT/ddT5fshUNebNPfsjQCSuOvW8oAOnvWn
ewXlwjI3H6hgtSBl7cXZj1ZlutazdhRqZtFRO0lMXh56xGxG44twkVg3vw00oB2f
A8aj6bYY5J1ZDlQWIHuHxh9oZDQZZkXANwYEwC43O8d1VT8yIFwSSQVyzuNoqKyW
EBbsTWztGrFJOdOqY9Euuzol7kswJrqlJMqtJRdQGB5QzbPXv6Q=
=esbI
-----END PGP SIGNATURE-----
Merge tag 'samsung-defconfig-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/defconfig
Samsung defconfig changes for v6.7
Enable several drivers for boards with Samsung Exynos ARM SoCs in
exynos_defconfig and multi_v7_defconfig: display PHYs, AHCI DWC, TM2
touchkey (used on ARM and ARM64 Exynos-based boards), Samsung camera
sensors and Intersil 29018 light sensor.
Enable also IIO in s5pv210_defconfig used by MAX17040 fuel gauge driver.
* tag 'samsung-defconfig-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: exynos_defconfig: add driver for ISL29018
ARM: multi_v7_defconfig: add drivers for S5C73M3 & S5K6A3 camera sensors
ARM: multi_v7_defconfig: add tm2-touchkey driver
ARM: exynos_defconfig: replace SATA_AHCI_PLATFORM with AHCI_DWC driver
ARM: multi_v7_defconfig: add AHCI_DWC driver
ARM: multi_v7_defconfig: make Exynos related PHYs modules
ARM: s5pv210_defconfig: enable IIO required by MAX17040
Link: https://lore.kernel.org/r/20231016072911.27148-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* Enable SMPro and FSI drivers, the BMC to host interfaces for Ampere
and IBM's server processors
* Enable IPMI SSIF, the smbus transport for IPMI
* Disable FIRMWARE_MEMMAP, an x86 only thing
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRz6FSYRMHvZ436fLaBQBa54y6+yAUCZSyOLwAKCRCBQBa54y6+
yEZdAQCgsBEL7Mvs0hELciXKx84XR9wKDDz+fGKiaY6DSS0hFAEAwXEF00omm6qe
eYyJ9vtyWR7A6C7rTPxI4NUcVVagIwU=
=RX7n
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUu+gUACgkQYKtH/8kJ
UidUCxAA4jxACgMvmllyppjFRD9dXxlyCtTDpnwLGrc9DWQ7IvMad0G4+7VbUvGQ
Z00W6GBmSBw9+VLt2BpV3M2SOsaLA+whqUUs2CVuy6as9Qilpxh4yDvXD5o5uMY+
ZmvpevxGsV8yVnc+TrBXaw1gt9j75VVlB0nBNaBjlLpNsNGWK9kTDlEtKlfIeZq2
xNsbuUcv1SsKeDW2nQ6yl9vnj3jq9hBCCJ0PrS/erQgf3gRYRVy9WVO1nfUF0KSH
mLSQu6m3Is6JBgqhfVNsz9Yml5c34o29yaOIx8cJPiGNoULk2Il24RAx6wArneNy
wy0tPbE7vNbLRFyZSjeI0qXhzTkmZ3fWXfcIm273vvnsPR0T0KjHdbBTpsLSuQ8J
EShuaDb2wuidlq9cePoh+7z3Jy2c2URW+2D8SDDjxyU066JCBX3eVvlj7wO36hY2
pUe5AbsRKNPNgNVhjfAqvyyxR3wvco0q1S9lRKpe18ocTj8l1gHeZjc3lGovPF95
zC4G3XvzwRwXQhL1qx+wr5P4sKieZ5/o0u6vL7T2PkQsfCk8nQVXB6ennl8uMUVw
Giao+Cz8aazrioXeLHAN+aL8oWI4fSApkmxe9Nih+e9nqYmZiJWho7tDgA9cGaR5
ICXC1Ns3/yBCoBQwx7puHjkCSWjFhRsr5STyiN8vFrnUobjbqIk=
=lfPg
-----END PGP SIGNATURE-----
Merge tag 'aspeed-6.7-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into soc/defconfig
ASPEED defconfig updates for 6.7
* Enable SMPro and FSI drivers, the BMC to host interfaces for Ampere
and IBM's server processors
* Enable IPMI SSIF, the smbus transport for IPMI
* Disable FIRMWARE_MEMMAP, an x86 only thing
* tag 'aspeed-6.7-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc:
ARM: config: aspeed: Remove FIRMWARE_MEMMAP
ARM: config: aspeed_g5: Enable SSIF BMC driver
ARM: config: aspeed: Add Ampere SMPro drivers
ARM: config: aspeed: Add new FSI drivers
Link: https://lore.kernel.org/r/CACPK8XezpL-4bx0S-9t999_qde5Hik9BnuUZHcnmDHTd0KWBLA@mail.gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This enables the NB7VPQ904M SuperSpeed redriver driver, used in SM8550,
the LPASS pinctrl driver for SM6115 and SM8350 and the M31 USB phy
driver found in IPQ5332.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmUsSOIVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FdX0P/jd12xVPwiiP6juBqQeTVLWy0doN
1Ir+4UdO3v9VEvMU3Cs6QnQC8dgLRi8V1qUzne7ec/KNT0Ulqw5X5j22js52Q4i9
6i5fz9488YmWdav38JzfP3s7MAkVbs5EueKPBysfGLWmt1s4ZRT9vo93ZliGpQBo
FT7M/ovcP/c7cF9SaCT6gXxdyNrTbPlSwEQ/jJEIOODmp0Y5Ewq4aEy+KLpOxZo/
qU2iD58j7Wts1hDWMaZwViYUOyKG4rEfrV0RFSkJLppp8+EECf5nfKv6chMU/XQJ
OcKoekcHBbAp2kDBCsrERLWKXw0WfcpjWTsFHDtr/XAToi+eKR/f9PbiGFWzZRTP
SW04T+0NlpulIXJuFjvrzC0GwnIrQtR/sFFSh1K27PvlF7FMy/d/3Dcl6AtflPEq
nwuxr4LMCXiNMQHREgtxHMABwT1F4TBgYVMqy1ep0oBr1XvFo2hPoknCZqQ57Rxb
OWGh7wbthoguGY3fCLWOcaVRjGmkMYmsEM+aO9y8UBCNJzfw14aOe8C9jsaiKB8q
B8kmBYn8+xbR0J25JCBMVWKWNoHzASo9X85r8MYRibYVowwRFYYVeSeeJB2iIQTy
2HD9bezwTb3JhpqVifOmYr/AR4VENABTiAqbtVAgvoFzCw+ebJ8LBmyb94lElAVY
unrGsyYlwPzR5wzX
=76AT
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUu+dYACgkQYKtH/8kJ
UiezzRAAj+i9QxhL4ZO80PbNTYh58PF4PHVnk7DUUxGkPqjQp9XFG6o39iVENH+n
JdriN5roQwCq1yXFoR7sMjmwh/oXK5BAmDIiExDDtymzzdHYqnRJqeWjlWDXKBMB
fSrkNqcQOxiHJqYtSbgDhzSzbXCnUCxCNP9iWY9sVQIp1ktkv1kkfCkdvAw3uXHN
8TMj8TdTxEjGILyQewSFsYzPrPai3RYSVlNfifbk1s303YYqdN6WI5RZZJowyjx9
DMNlTnrAj40pvuEKg7OtS9M2jDqZTfbLLM0vQVGqBa+kqtK82iyIZV/ECfOYt5ps
cxONxUS5mIhzlbPkbho298MIlEsXXZK99Cbgz4FXIEhLZWLQKTJxNxBSkcdUK3F3
pef1kq83lOfUQRrvt5XEP5TR+YWKpIyJrdUIJT+ok/lFJdHoNq9qZYmUvsuQbXa8
hAyvcOGNs1q8YUfoFyFJGJyCTj6QUPvSweeGj0T5xQfpoFHhTdM6tm81a6Jiov+e
1Cil1XUtN2fR5Qu41Ui4H7kKcgIMrko37CdENkrUbmjBu9gDDuU6VdyYRXJUTu7y
2jGfPeurS/ynX5LYubeDoQ4qRvXh2K1DkgQlH2AtoTXnOHB81uej3WZ9d8/XNlHW
ZzJT11kLZu2Sl43XNWPqq0Kum9IPsu2D/IH/sosZIa3EbsbYSnw=
=3jl/
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/defconfig
Qualcomm ARM64 defconfig updates for v6.7
This enables the NB7VPQ904M SuperSpeed redriver driver, used in SM8550,
the LPASS pinctrl driver for SM6115 and SM8350 and the M31 USB phy
driver found in IPQ5332.
* tag 'qcom-arm64-defconfig-for-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable M31 USB phy driver
arm64: defconfig: enable Qualcomm SM6115 LPASS pinctrl
arm64: defconfig: enable Qualcomm SM8350 LPASS pinctrl
arm64: defconfig: enable NB7VPQ904M driver as module
Link: https://lore.kernel.org/r/20231015201812.855218-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The abi_test currently uses a long sized test value for enablement
checks. On LE this works fine, however, on BE this results in inaccurate
assert checks due to a bit being used and assuming it's value is the
same on both LE and BE.
Use int type for 32-bit values and long type for 64-bit values to ensure
appropriate behavior on both LE and BE.
Fixes: 60b1af8de8 ("tracing/user_events: Add ABI self-test")
Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
We can now use any of the secret transformation hashes with a
secret, regardless of the secret size.
e.g. a 32 byte key with the SHA-512(64 byte) hash.
The example secret from the spec should now be permitted with
any of the following:
DHHC-1:00:ia6zGodOr4SEG0Zzaw398rpY0wqipUWj4jWjUh4HWUz6aQ2n:
DHHC-1:01:ia6zGodOr4SEG0Zzaw398rpY0wqipUWj4jWjUh4HWUz6aQ2n:
DHHC-1:02:ia6zGodOr4SEG0Zzaw398rpY0wqipUWj4jWjUh4HWUz6aQ2n:
DHHC-1:03:ia6zGodOr4SEG0Zzaw398rpY0wqipUWj4jWjUh4HWUz6aQ2n:
Note: Secrets are still restricted to 32,48 or 64 bits.
Co-developed-by: Akash Appaiah <Akash.Appaiah@dell.com>
Signed-off-by: Akash Appaiah <Akash.Appaiah@dell.com>
Signed-off-by: Mark O'Donovan <shiftee@posteo.net>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
This does not change current behaviour as the driver currently
verifies that the secret size is the same size as the length of
the transformation hash.
Co-developed-by: Akash Appaiah <Akash.Appaiah@dell.com>
Signed-off-by: Akash Appaiah <Akash.Appaiah@dell.com>
Signed-off-by: Mark O'Donovan <shiftee@posteo.net>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
nvmet_tcp_schedule_release_queue() is called from socket state
change callbacks, which may be called from an softirq context.
So use 'spin_lock_bh' to avoid a spin lock warning.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
