When an extended state component is not present in fpstate, but in init
state, the function copies from init_fpstate via copy_feature().
But, dynamic states are not present in init_fpstate because of all-zeros
init states. Then retrieving them from init_fpstate will explode like this:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
RIP: 0010:memcpy_erms+0x6/0x10
? __copy_xstate_to_uabi_buf+0x381/0x870
fpu_copy_guest_fpstate_to_uabi+0x28/0x80
kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm]
? __this_cpu_preempt_check+0x13/0x20
? vmx_vcpu_put+0x2e/0x260 [kvm_intel]
kvm_vcpu_ioctl+0xea/0x6b0 [kvm]
? kvm_vcpu_ioctl+0xea/0x6b0 [kvm]
? __fget_light+0xd4/0x130
__x64_sys_ioctl+0xe3/0x910
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x27/0x50
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Adjust the 'mask' to zero out the userspace buffer for the features that
are not available both from fpstate and from init_fpstate.
The dynamic features depend on the compacted XSAVE format. Ensure it is
enabled before reading XCOMP_BV in init_fpstate.
Fixes: 2308ee57d9 ("x86/fpu/amx: Enable the AMX feature in 64-bit mode")
Reported-by: Yuan Yao <yuan.yao@intel.com>
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Tested-by: Yuan Yao <yuan.yao@intel.com>
Link: https://lore.kernel.org/lkml/BYAPR11MB3717EDEF2351C958F2C86EED95259@BYAPR11MB3717.namprd11.prod.outlook.com/
Link: https://lkml.kernel.org/r/20221021185844.13472-1-chang.seok.bae@intel.com
Two small changes, one in the lpfc driver and the other in the core.
The core change is an additional footgun guard which prevents users
from writing the wrong state to sysfs and causing a hang.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCY1KeHiYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishUBSAP0aya1G
dXqg9yZqSkYKj17oFHfU0Y84lPfQKHh5b6gH2wEA49SWjPCHDf4OhCWjzpqdAAeO
GmT9oeU3FqhqiuMthBA=
=vIir
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Two small changes, one in the lpfc driver and the other in the core.
The core change is an additional footgun guard which prevents users
from writing the wrong state to sysfs and causing a hang"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: lpfc: Fix memory leak in lpfc_create_port()
scsi: core: Restrict legal sdev_state transitions via sysfs
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmNSA2YQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpjmWD/9w8JAXzbJR+hHOa6wcy/2gYLWewYPVwG9D
HyuiSYDGGazPC39gmfEl9ouixhXxofMEjnvTkguzNudpKp8I4yKvmHC6hXz8Qxwj
EYpGa99yVI914Qd6XWXzzc+03C/+flLb+JuvNee9oNkv/mYSjXSvBT7hOVYNNomX
bnTFi9QHbP3vL+LA1WRkdlSyypxVDibj3gzyCqWrTiprRKbMzpZa481PUZf7QrDl
MjlmAoDYA3wzsq8JjvEmO3/rZdawK6E8POtPn9mXmmdna0mcW1MQ7UOxJIi+g7fr
JU+Q6E6VhFA/zjV2nmRfxlnticXdzih8OvL4rMK5QBwxqz0NDBqpl7OfnuR4Y0WX
WlWWMVPG4zkJ7xCMy4s8h7iLn/GSgsjNFZ4tVA9EccGC3Oh5NOINyqMzNnZqEiY4
judhXpiIowTkHuxqwzLEL1V91ELhkZoLaVfGaQp2DiG/0PMGbNSqDMMXQJ+m/N4g
2AL9Gwn0iqrAeNVmBhOGCfQ9hVh7TTKoHd3QKcW0lwksy8zKZBqIo6XvLxX8DcQ7
gqTGv+LBJkaFsFLiFCI+f59ZPPs6FyiqvUmDmIZmoVLPVxRuMwfWijIYhU/zXPjB
vvautQLCQ3FX49XDuUtGlrgDLwFvMkyDl7IOjH+jzK0Cmj+Gmv1/2/E18wlGuMsW
c6mV/bWW0Q==
=bOqU
-----END PGP SIGNATURE-----
Merge tag 'io_uring-6.1-2022-10-20' of git://git.kernel.dk/linux
Pull io_uring fixes from Jens Axboe:
- Fix a potential memory leak in the error handling path of io-wq setup
(Rafael)
- Kill an errant debug statement that got added in this release (me)
- Fix an oops with an invalid direct descriptor with IORING_OP_MSG_RING
(Harshit)
- Remove unneeded FFS_SCM flagging (Pavel)
- Remove polling off the exit path (Pavel)
- Move out direct descriptor debug check to the cleanup path (Pavel)
- Use the proper helper rather than open-coding cached request get
(Pavel)
* tag 'io_uring-6.1-2022-10-20' of git://git.kernel.dk/linux:
io-wq: Fix memory leak in worker creation
io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()
io_uring/rw: remove leftover debug statement
io_uring: don't iopoll from io_ring_ctx_wait_and_kill()
io_uring: reuse io_alloc_req()
io_uring: kill hot path fixed file bitmap debug checks
io_uring: remove FFS_SCM
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRTLbB6QfY48x44uB6AXGG7T9hjvgUCY1JhRwAKCRCAXGG7T9hj
vtcFAQDEkdKa5lWFo6Lut8rraHPyjoCVdLV1J2KJo0vO8rgU+AEA1kuPMqQzpVez
1xTkZrKnPvIo+Dv515oxDCmzTxGoDgA=
=1fmO
-----END PGP SIGNATURE-----
Merge tag 'for-linus-6.1-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
"Just two fixes for the new 'virtio with grants' feature"
* tag 'for-linus-6.1-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts
xen/virtio: Handle cases when page offset > PAGE_SIZE properly
Along with the version number, "bpftool version" displays a list of
features that were selected at compilation time for bpftool. It would be
useful to indicate in that list whether a binary is a bootstrap version
of bpftool. Given that an increasing number of components rely on
bootstrap versions for generating skeletons, this could help understand
what a binary is capable of if it has been copied outside of the usual
"bootstrap" directory.
To detect a bootstrap version, we simply rely on the absence of
implementation for the do_prog() function. To do this, we must move the
(unchanged) list of commands before do_version(), which in turn requires
renaming this "cmds" array to avoid shadowing it with the "cmds"
argument in cmd_select().
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20221020100332.69563-1-quentin@isovalent.com
Commands "bpftool help" or "bpftool version" use argv[0] to display the
name of the binary. While it is a convenient way to retrieve the string,
it does not always produce the most readable output. For example,
because of the way bpftool is currently packaged on Ubuntu (using a
wrapper script), the command displays the absolute path for the binary:
$ bpftool version | head -n 1
/usr/lib/linux-tools/5.15.0-50-generic/bpftool v5.15.60
More generally, there is no apparent reason for keeping the whole path
and exact binary name in this output. If the user wants to understand
what binary is being called, there are other ways to do so. This commit
replaces argv[0] with "bpftool", to simply reflect what the tool is
called. This is aligned on what "ip" or "tc" do, for example.
As an additional benefit, this seems to help with integration with
Meson for packaging [0].
[0] https://github.com/NixOS/nixpkgs/pull/195934
Suggested-by: Vladimír Čunát <vladimir.cunat@nic.cz>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20221020100300.69328-1-quentin@isovalent.com
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAyFiEES0KozwfymdVUl37v6iDy2pc3iXMFAmNRY7QUHHBhdWxAcGF1
bC1tb29yZS5jb20ACgkQ6iDy2pc3iXMvRg/48NI0ohEC3ErRlLxhpaQgEOp4qH+h
rqvOAyuIHNrdd9j4u5Gm3n2VvNRsAhzFXxlfRpoAGIrO9elest3/RcCI/HiTXK5a
Jt+yzBIZXyJutvTJSGuCc78q8ydfhhD+1jGEBPCsiTAdRIiNUPTXutqCWkJW3rn7
apcYQvJ7P65VPipSzkHFngRN7PjyXr3poU3OTKHeA+Uxn+jydk+d6GpGJ9wVkwPz
kFlF/7CXUK05PPs5cJJjSIXnDSEkFUB8ZCV1bEMBV5vm6GodEz02forUTJ4yMxtP
0ARGepQLxej76DTmnqWf+9MaijnRCvo0eOwXSltD0CrsVoirulc/nLEq2x4eDiaZ
W4iIOqJp8CgTLw4OhJDKrdltypM7xLVSlyAS18hpekfnRldtMLHQTWmUxMmCj9Q1
WF8TTabp8tg2DzlGrDM96BHz8vGeF4e1O5qEE2Wpq9XCIYiHmusFk2mOH7nhuWwO
cqUOkFR27DSyPvR/jgNgRRNfB1NzaiNndsknDeEBHXbjOgzeWRtgFjBscRlpIEc3
NgF8DStIVVBmuxQ2MfF4VXxUtjAgLbAP0fTqLmYZVxnQXmRJPXzqTqe/9a81a9Yy
ARX23ZW2vpaJTQ5CdFyje+bk30Msi3q5EWFsC34KSXL0oyIyd3/tWsCv4C+9JWbK
2NOTIUZbkRekBw==
=Z+5I
-----END PGP SIGNATURE-----
Merge tag 'selinux-pr-20221020' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
Pull selinux fix from Paul Moore:
"A small SELinux fix for a GFP_KERNEL allocation while a spinlock is
held.
The patch, while still fairly small, is a bit larger than one might
expect from a simple s/GFP_KERNEL/GFP_ATOMIC/ conversion because we
added support for the function to be called with different gfp flags
depending on the context, preserving GFP_KERNEL for those cases that
can safely sleep"
* tag 'selinux-pr-20221020' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
selinux: enable use of both GFP_KERNEL and GFP_ATOMIC in convert_context()
The reg_name in parse_usdt_arg() is used to hold register name, which
is short enough to be held in a 16-byte array, so we could define
reg_name as char reg_name[16] to avoid dynamically allocating reg_name
with sscanf.
Suggested-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20221018145538.2046842-1-xukuohai@huaweicloud.com
In some cases an hardware peripheral can be used for two exclusive usages.
For example, on STM32MP15 we have the same peripheral for I2S and SPI. We
have dedicated driver for each usage and so a dedicated device node in
devicetree.
To avoid to get useless warnings running "make W=1 dtbs", this patch adds
the "-Wunique_unit_address_if_enabled" flag for a make with W=1. In this
case we will detect a duplicate address only if both devices are
enabled in the devicetree, which is a real error case.
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Link: https://lore.kernel.org/r/20221021084447.5550-1-alexandre.torgue@foss.st.com
[robh: Refactor options and keep 'unique_unit_address' for W=2]
Signed-off-by: Rob Herring <robh@kernel.org>
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. Hence move its compatible value to the R-Car Gen4 section.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/c1fb71448a8400986fd30d51a1bb2704376c0306.1666361055.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
The 'ata-generic' binding has been around since 2008, but never
documented.
Cc: Alexander Shiyan <shc_work@mail.ru>
Acked-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Link: https://lore.kernel.org/r/20221011135849.2785834-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
BPF CI has revealed flakiness in the task_local_storage/exit_creds test.
The failure point in CI [1] is that null_ptr_count is equal to 0,
which indicates that the program hasn't run yet. This points to the
kern_sync_rcu (sys_membarrier -> synchronize_rcu underneath) not
waiting sufficiently.
Indeed, synchronize_rcu only waits for read-side sections that started
before the call. If the program execution starts *during* the
synchronize_rcu invocation (due to, say, preemption), the test won't
wait long enough.
As a speculative fix, make the synchornize_rcu calls in a loop until
an explicit run counter has gone up.
[1]: https://github.com/kernel-patches/bpf/actions/runs/3268263235/jobs/5374940791
Signed-off-by: Delyan Kratunov <delyank@meta.com>
Link: https://lore.kernel.org/r/156d4ef82275a074e8da8f4cffbd01b0c1466493.camel@meta.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
[why]
MES response time in sriov may be longer than default value
due to reset or init in other VF. A timeout value specific
to sriov is needed.
[how]
When in sriov, adjust the timeout value to calculated
worst case scenario.
Signed-off-by: Yiqing Yao <yiqing.yao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Trivial removal of an unused variable. Not sure how it snuck by me and
build bots in the 7c99616e3f.
Fixes: 7c99616e3f ("drm: Remove drm_mode_config::fb_base")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thomas Zimmermann <tzimemrmann@suse.de>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221021010703.536318-1-zack@kde.org
[WHY]
0, original pstate X
1, ctx_A_create -> ctx_A->stable_pstate = X
2, ctx_A_set_pstate (Y) -> current pstate is Y (PEAK or STANDARD)
3, ctx_B_create -> ctx_B->stable_pstate = Y
4, ctx_A_destroy -> restore pstate to X
5, ctx_B_destroy -> restore pstate to Y
Above sequence will cause final pstate is wrong (Y), should be original X.
[HOW]
When ctx_B create,
if ctx_A touched pstate setting
(not auto, stable_pstate_ctx != NULL),
set ctx_B->stable_pstate the same value as ctx_A saved,
if stable_pstate_ctx == NULL,
fetch current pstate to fill
ctx_B->stable_pstate.
Signed-off-by: Chengming Gui <Jack.Gui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Call ghes_get_devices() to check whether ghes_edac should be used on the
platform where it is preferred over the corresponding chipset-specific
EDAC driver.
Unlike the existing edac_get_owner() check, the ghes_get_devices() check
works independent to the module_init ordering.
[ bp: Massage. ]
Suggested-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-6-justin.he@arm.com
Commit 16ce101db8 ("mm/memory.c: fix race when faulting a device private
page") changed the migrate_to_ram() callback to take a reference on the
device page to ensure it can't be freed while handling the fault.
Unfortunately the corresponding update to Nouveau to accommodate this
change was inadvertently dropped from that patch causing GPU to CPU
migration to fail so add it here.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Fixes: 16ce101db8 ("mm/memory.c: fix race when faulting a device private page")
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221019122934.866205-1-apopple@nvidia.com
Commit
dc4e8c07e9 ("ACPI: APEI: explicit init of HEST and GHES in apci_init()")
introduced a bug leading to ghes_edac_register() to be invoked before
edac_init(). Because at that time the bus "edac" hadn't been even
registered, this created sysfs nodes as /devices/mc0 instead of
/sys/devices/system/edac/mc/mc0 on an Ampere eMag server.
Fix this by turning ghes_edac into a proper module.
The list of GHES devices returned is not protected from being modified
concurrently but it is pretty static as it gets created only during GHES
init and latter is not a module so...
[ bp: Massage. ]
Fixes: dc4e8c07e9 ("ACPI: APEI: explicit init of HEST and GHES in apci_init()")
Co-developed-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-5-justin.he@arm.com
[why]
MES response time in sriov may be longer than default value
due to reset or init in other VF. A timeout value specific
to sriov is needed.
[how]
When in sriov, adjust the timeout value to calculated
worst case scenario.
Signed-off-by: Yiqing Yao <yiqing.yao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
0, original pstate X
1, ctx_A_create -> ctx_A->stable_pstate = X
2, ctx_A_set_pstate (Y) -> current pstate is Y (PEAK or STANDARD)
3, ctx_B_create -> ctx_B->stable_pstate = Y
4, ctx_A_destroy -> restore pstate to X
5, ctx_B_destroy -> restore pstate to Y
Above sequence will cause final pstate is wrong (Y), should be original X.
[HOW]
When ctx_B create,
if ctx_A touched pstate setting
(not auto, stable_pstate_ctx != NULL),
set ctx_B->stable_pstate the same value as ctx_A saved,
if stable_pstate_ctx == NULL,
fetch current pstate to fill
ctx_B->stable_pstate.
Signed-off-by: Chengming Gui <Jack.Gui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
post-6.0 issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCY1IgYgAKCRDdBJ7gKXxA
jpyRAQDkfa1LDkfbA4dQBZShkUhBX1k3AyRO1NWMjwwTxP3H8wD9HUz1BB3ynoKc
ipzQs7q5jbBvndczEksHiG2AC7SvQAI=
=wD9I
-----END PGP SIGNATURE-----
Merge tag 'mm-hotfixes-stable-2022-10-20' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull misc fixes from Andrew Morron:
"Seventeen hotfixes, mainly for MM.
Five are cc:stable and the remainder address post-6.0 issues"
* tag 'mm-hotfixes-stable-2022-10-20' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
nouveau: fix migrate_to_ram() for faulting page
mm/huge_memory: do not clobber swp_entry_t during THP split
hugetlb: fix memory leak associated with vma_lock structure
mm/page_alloc: reduce potential fragmentation in make_alloc_exact()
mm: /proc/pid/smaps_rollup: fix maple tree search
mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages
mm/mmap: fix MAP_FIXED address return on VMA merge
mm/mmap.c: __vma_adjust(): suppress uninitialized var warning
mm/mmap: undo ->mmap() when mas_preallocate() fails
init: Kconfig: fix spelling mistake "satify" -> "satisfy"
ocfs2: clear dinode links count in case of error
ocfs2: fix BUG when iput after ocfs2_mknod fails
gcov: support GCC 12.1 and newer compilers
zsmalloc: zs_destroy_pool: add size_class NULL check
mm/mempolicy: fix mbind_range() arguments to vma_merge()
mailmap: update email for Qais Yousef
mailmap: update Dan Carpenter's email address
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEABECAAYFAmNQOiwACgkQ+iyteGJfRsopNgCgw0BPrAnTfXQxiPPJiej/vUIu
rWMAoLs5azbM52vw54b5onmIngSYacNL
=1XLP
-----END PGP SIGNATURE-----
Merge tag 'linux-watchdog-6.1-rc2' of git://www.linux-watchdog.org/linux-watchdog
Pull watchdog updates from Wim Van Sebroeck:
- Add tracing events for the most common watchdog events
* tag 'linux-watchdog-6.1-rc2' of git://www.linux-watchdog.org/linux-watchdog:
watchdog: Add tracing events for the most usual watchdog events
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
In IPC4 all DSP loadable executable is a 'library' containing modules. The main
or basefw is also a library which contains multiple modules.
IPC4 allows to use loadable libraries to extend the functionality of the booted
basefw.
This series adds support for loading external libraries in case they are needed
by the loaded topology file.
The libraries must be placed to a specific firmware directory (fw_lib_prefix),
which is:
intel/avs-lib|sof-ipc4-lib/ followed by the platform name and in case of
community key use a 'community' directory.
For example for upx-i11 (community key): intel/avs-lib/tgl/community is the
default path.
The name of the library should be the UUID of the module it contains since the
library loading is going to look for the file as <module_UUID>.bin
In case there is a need to bundle multiple modules into single library, symlinks
can be used to point to the file:
module_boundle.bin
<UUID1>.bin -> module_boundle.bin
<UUID2>.bin -> module_boundle.bin
<UUID3>.bin -> module_boundle.bin
But note that in this case all modules will be loaded to the DSP since only the
whole library can be loaded, not individual modules.
Merge assorted ACPI fixes for 6.1-rc2:
- Fix resource list walk in acpi_dma_get_range() (Robin Murphy).
- Add IRQ override quirk for LENOVO IdeaPad and extend the IRQ
override warning message (Jiri Slaby).
- Fix integer overflow in ghes_estatus_pool_init() (Ashish Kalra).
- Fix multiple error records handling in one of the ACPI extlog driver
code paths (Tony Luck).
- Prune DSDT override documentation from index after dropping it (Bagas
Sanjaya).
* acpi-scan:
ACPI: scan: Fix DMA range assignment
* acpi-resource:
ACPI: resource: note more about IRQ override
ACPI: resource: do IRQ override on LENOVO IdeaPad
* acpi-apei:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
* acpi-extlog:
ACPI: extlog: Handle multiple records
* acpi-docs:
Documentation: ACPI: Prune DSDT override documentation from index
Currently the NMI safety debugging is only performed on architectures
that don't support NMI-safe this_cpu_inc().
Reorder the code so that other architectures like x86 also detect bad
uses.
[ paulmck: Apply kernel test robot, Stephen Rothwell, and Zqiang feedback. ]
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
To make ghes_edac a proper module, prepare to decouple its dependencies
from GHES.
Move the ghes_edac.force_load parameter to ghes.c in order to
properly control whether ghes_edac should be force-loaded: In
ghes_edac_register() it is too late to set the module flag.
Introduce a helper ghes_get_devices(), which returns the list of GHES
devices which got probed when the platform-check passes on the system.
The previous force_load check is not needed in ghes_edac_unregister()
since it will be checked in the module's init function of ghes_edac
later.
[ bp: Massage. ]
Suggested-by: Toshi Kani <toshi.kani@hpe.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-4-justin.he@arm.com
Tell about the need to protect against concurrent updaters who may
overflow the GP counter behind the current update.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Using the NMI-unsafe reader API from within an NMI handler is very likely
to be buggy for three reasons:
1) NMIs aren't strictly re-entrant (a pending nested NMI will execute at
the end of the current one) so it should be fine to use a non-atomic
increment here. However, breakpoints can still interrupt NMIs and if
a breakpoint callback has a reader on that same ssp, a racy increment
can happen.
2) If the only reader site for a given srcu_struct structure is in an
NMI handler, then RCU should be used instead of SRCU.
3) Because of the previous reason (2), an srcu_struct structure having
an SRCU read side critical section in an NMI handler is likely to
have another one from a task context.
For all these reasons, warn if an NMI-unsafe reader API is used from an
NMI handler.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
The s390 architecture uses either a cmpxchg loop (old systems)
or the laa add-to-memory instruction (new systems) to implement
this_cpu_add(), both of which are NMI safe. This means that the old
and more-efficient srcu_read_lock() may be used in NMI context, without
the need for srcu_read_lock_nmisafe(). Therefore, add the new Kconfig
option ARCH_HAS_NMI_SAFE_THIS_CPU_OPS to arch/s390/Kconfig, which will
cause NEED_SRCU_NMI_SAFE to be deselected, thus preserving the current
srcu_read_lock() behavior.
[ paulmck: Apply Christian Borntraeger feedback. ]
Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/
Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Suggested-by: Frederic Weisbecker <frederic@kernel.org>
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Petr Mladek <pmladek@suse.com>
Cc: <linux-s390@vger.kernel.org>
The loongarch architecture uses the atomic read-modify-write
amadd instruction to implement this_cpu_add(), which is NMI safe.
This means that the old and more-efficient srcu_read_lock() may be
used in NMI context, without the need for srcu_read_lock_nmisafe().
Therefore, add the new Kconfig option ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
to arch/loongarch/Kconfig, which will cause NEED_SRCU_NMI_SAFE to be
deselected, thus preserving the current srcu_read_lock() behavior.
Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/
Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Suggested-by: Frederic Weisbecker <frederic@kernel.org>
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Petr Mladek <pmladek@suse.com>
Cc: <loongarch@lists.linux.dev>
Running rcutorture with non-zero fqs_duration module parameter in a
kernel built with CONFIG_PREEMPTION=y results in the following splat:
BUG: using __this_cpu_read() in preemptible [00000000]
code: rcu_torture_fqs/398
caller is __this_cpu_preempt_check+0x13/0x20
CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x86
dump_stack+0x10/0x16
check_preemption_disabled+0xe5/0xf0
__this_cpu_preempt_check+0x13/0x20
rcu_force_quiescent_state.part.0+0x1c/0x170
rcu_force_quiescent_state+0x1e/0x30
rcu_torture_fqs+0xca/0x160
? rcu_torture_boost+0x430/0x430
kthread+0x192/0x1d0
? kthread_complete_and_exit+0x30/0x30
ret_from_fork+0x22/0x30
</TASK>
The problem is that rcu_force_quiescent_state() uses __this_cpu_read()
in preemptible code instead of the proper raw_cpu_read(). This commit
therefore changes __this_cpu_read() to raw_cpu_read().
Signed-off-by: Zqiang <qiang1.zhang@intel.com>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This commit adds a few words to the informative message that appears
every ten seconds in RCU Tasks and RCU Tasks Trace grace periods.
This message currently reads as follows:
rcu_tasks_wait_gp: rcu_tasks grace period 1046 is 10088 jiffies old.
After this change, it provides additional context, instead reading
as follows:
rcu_tasks_wait_gp: rcu_tasks grace period number 1046 (since boot) is 10088 jiffies old.
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
The commit 3fcd6a230f ("x86/cpu: Avoid cpuinfo-induced IPIing of
idle CPUs") introduced rcu_is_idle_cpu() in order to identify the
current CPU idle state. But commit f3eca381bd ("x86/aperfmperf:
Replace arch_freq_get_on_cpu()") switched to using MAX_SAMPLE_AGE,
so rcu_is_idle_cpu() is no longer used. This commit therefore removes it.
Fixes: f3eca381bd ("x86/aperfmperf: Replace arch_freq_get_on_cpu()")
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
It is not obvious to the casual user why it is absolutely necessary to
acquire a reference to a SLAB_TYPESAFE_BY_RCU structure before acquiring
a lock in that structure. Therefore, add a comment explaining this point.
[ paulmck: Apply Vlastimil Babka feedback. ]
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: <linux-mm@kvack.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Merge series from Amjad Ouled-Ameur <aouledameur@baylibre.com>:
Between SPI transactions, all SPI pins are in HiZ state. When using the SS
signal from the SPICC controller it's not an issue because when the
transaction resumes all pins come back to the right state at the same time
as SS.
The problem is when we use CS as a GPIO. In fact, between the GPIO CS
state change and SPI pins state change from idle, you can have a missing or
spurious clock transition.
Set a bias on the clock depending on the clock polarity requested before CS
goes active, by passing a special "idle-low" and "idle-high" pinctrl state
and setting the right state at a start of a message.
Wang Yufen says:
====================
This patchset add "autoattach" optional for "bpftool prog load(_all)" to support
one-step load-attach-pin_link.
v8 -> v9: fix link leak, and change pathname_concat(specify not just buffer
pointer, but also it's size)
v7 -> v8: for the programs not supporting autoattach, fall back to reguler pinning
instead of skipping
v6 -> v7: add info msg print and update doc for the skip program
v5 -> v6: skip the programs not supporting auto-attach,
and change optional name from "auto_attach" to "autoattach"
v4 -> v5: some formatting nits of doc
v3 -> v4: rename functions, update doc, bash and do_help()
v2 -> v3: switch to extend prog load command instead of extend perf
v2: https://patchwork.kernel.org/project/netdevbpf/patch/20220824033837.458197-1-weiyongjun1@huawei.com/
v1: https://patchwork.kernel.org/project/netdevbpf/patch/20220816151725.153343-1-weiyongjun1@huawei.com/
====================
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Back in commit 826cff3f7e ("drm/bridge: parade-ps8640: Enable
runtime power management") we removed a mysterious 50 ms delay because
"Parade's support [couldn't] explain what the delay [was] for".
While I'm always a fan of removing mysterious delays, I suspect that
we need this mysterious delay to avoid some problems.
Specifically, what I found recently is that on sc7180-trogdor-homestar
sometimes the AUX backlight wasn't initializing properly. Some
debugging showed that the drm_dp_dpcd_read() function that the AUX
backlight driver was calling was returning bogus data about 1% of the
time when I booted up. This confused
drm_panel_dp_aux_backlight(). From continued debugging:
- If I retried the read then the read worked just fine.
- If I added a loop to perform the same read that
drm_panel_dp_aux_backlight() was doing 30 times at bootup I could
see that some percentage of the time the first read would give bogus
data but all 29 additional reads would always be fine.
- If I added a large delay _after_ powering on the panel but before
powering on PS8640 I could still reproduce the problem.
- If I added a delay after PS8640 powered on then I couldn't reproduce
the problem.
- I couldn't reproduce the problem on a board with the same panel but
the ti-sn65dsi86 bridge chip.
To me, the above indicated that there was a problem with PS8640 and
not the panel.
I don't really have any insight into what's going on in the MCU, but
my best guess is that when the MCU itself sees the HPD go high that it
does some AUX transfers itself and this is confusing things.
Let's go back and add back in the mysterious 50 ms delay. We only want
to do this the first time we see HPD go high after booting the MCU,
not every time we double-check HPD.
With this, the backlight initializes reliably on homestar.
Fixes: 826cff3f7e ("drm/bridge: parade-ps8640: Enable runtime power management")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221017121813.1.I59700c745fbc31559a5d5c8e2a960279c751dbd5@changeid
Between SPI transactions, all SPI pins are in HiZ state. When using the SS
signal from the SPICC controller it's not an issue because when the
transaction resumes all pins come back to the right state at the same time
as SS.
The problem is when we use CS as a GPIO. In fact, between the GPIO CS
state change and SPI pins state change from idle, you can have a missing or
spurious clock transition.
Set a bias on the clock depending on the clock polarity requested before CS
goes active, by passing a special "idle-low" and "idle-high" pinctrl state
and setting the right state at a start of a message
Reported-by: Da Xue <da@libre.computer>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
Link: https://lore.kernel.org/r/20221004-up-aml-fix-spi-v4-2-0342d8e10c49@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI pins of the SPICC Controller in Meson-GX needs to be controlled by
pin biais when idle. Therefore define three pinctrl names:
- default: SPI pins are controlled by spi function.
- idle-high: SCLK pin is pulled-up, but MOSI/MISO are still controlled
by spi function.
- idle-low: SCLK pin is pulled-down, but MOSI/MISO are still controlled
by spi function.
Reported-by: Da Xue <da@libre.computer>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221004-up-aml-fix-spi-v4-1-0342d8e10c49@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
