Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
On 1/9/24 2:16 PM, Nathan Chancellor wrote:
reviews.llvm.org was LLVM's Phabricator instances for code review. It
has been abandoned in favor of GitHub pull requests. While the majority
of links in the kernel sources still work because of the work Fangrui
has done turning the dynamic Phabricator instance into a static archive,
there are some issues with that work, so preemptively convert all the
links in the kernel sources to point to the commit on GitHub.
Most of the commits have the corresponding differential review link in
the commit message itself so there should not be any loss of fidelity in
the relevant information.
Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
in the area.
Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
Signed-off-by: Nathan Chancellor
Ack with one nit below.
Acked-by: Yonghong Song
---
Cc: a...@kernel.org
Cc: dan...@iogearbox.net
Cc: and...@kernel.org
Cc: myko...@fb.com
Cc: b...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
---
tools/testing/selftests/bpf/README.rst | 32 +++---
tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +-
.../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +-
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/tools/testing/selftests/bpf/README.rst
b/tools/testing/selftests/bpf/README.rst
index cb9b95702ac6..b9a493f66557 100644
--- a/tools/testing/selftests/bpf/README.rst
+++ b/tools/testing/selftests/bpf/README.rst
@@ -115,7 +115,7 @@ the insn 20 undoes map_value addition. It is currently
impossible for the
verifier to understand such speculative pointer arithmetic.
Hence `this patch`__ addresses it on the compiler side. It was committed on
llvm 12.
-__ https://reviews.llvm.org/D85570
+__
https://github.com/llvm/llvm-project/commit/ddf1864ace484035e3cde5e83b3a31ac81e059c6
The corresponding C code
@@ -165,7 +165,7 @@ This is due to a llvm BPF backend bug. `The fix`__
has been pushed to llvm 10.x release branch and will be
available in 10.0.1. The patch is available in llvm 11.0.0 trunk.
-__ https://reviews.llvm.org/D78466
+__
https://github.com/llvm/llvm-project/commit/3cb7e7bf959dcd3b8080986c62e10a75c7af43f0
bpf_verif_scale/loop6.bpf.o test failure with Clang 12
==
@@ -204,7 +204,7 @@ r5(w5) is eventually saved on stack at insn #24 for later
use.
This cause later verifier failure. The bug has been `fixed`__ in
Clang 13.
-__ https://reviews.llvm.org/D97479
+__
https://github.com/llvm/llvm-project/commit/1959ead525b8830cc8a345f45e1c3ef9902d3229
BPF CO-RE-based tests and Clang version
===
@@ -221,11 +221,11 @@ failures:
- __builtin_btf_type_id() [0_, 1_, 2_];
- __builtin_preserve_type_info(), __builtin_preserve_enum_value() [3_, 4_].
-.. _0: https://reviews.llvm.org/D74572
-.. _1: https://reviews.llvm.org/D74668
-.. _2: https://reviews.llvm.org/D85174
-.. _3: https://reviews.llvm.org/D83878
-.. _4: https://reviews.llvm.org/D83242
+.. _0:
https://github.com/llvm/llvm-project/commit/6b01b465388b204d543da3cf49efd6080db094a9
+.. _1:
https://github.com/llvm/llvm-project/commit/072cde03aaa13a2c57acf62d79876bf79aa1919f
+.. _2:
https://github.com/llvm/llvm-project/commit/00602ee7ef0bf6c68d690a2bd729c12b95c95c99
+.. _3:
https://github.com/llvm/llvm-project/commit/6d218b4adb093ff2e9764febbbc89f429412006c
+.. _4:
https://github.com/llvm/llvm-project/commit/6d6750696400e7ce988d66a1a00e1d0cb32815f8
Floating-point tests and Clang version
==
@@ -234,7 +234,7 @@ Certain selftests, e.g. core_reloc, require support for the
floating-point
types, which was introduced in `Clang 13`__. The older Clang versions will
either crash when compiling these tests, or generate an incorrect BTF.
-__ https://reviews.llvm.org/D83289
+__
https://github.com/llvm/llvm-project/commit/a7137b238a07d9399d3ae96c0b461571bd5aa8b2
Kernel function call test and Clang version
===
@@ -248,7 +248,7 @@ Without it, the error from compiling bpf selftests looks
like:
libbpf: failed to find BTF for extern 'tcp_slow_start' [25] section: -2
-__ https://reviews.llvm.org/D93563
+__
https://github.com/llvm/llvm-project/commit/886f9ff53155075bd5f1e994f17b85d1e1b7470c
btf_tag test and Clang version
==
@@ -264,8 +264,8 @@ Without them, the btf_tag selftest will be skipped and you
will observe:
# btf_tag:SKIP
-.. _0: https://reviews.llvm.org/D111588
-.. _1: https://reviews.llvm.org/D99
+.. _0:
https://github.com/llvm/llvm-project/commit/a162b67c98066218d0d00aa13b99afb95d9bb5e6
+.. _1:
https://github.com/llvm/llvm-project/commit/3466e00716e12e32fdb100e3fcfca5c2b3e8d784
Clang dependencies for static linking tests
===
@
[PATCH v5] powerpc/pseries/vas: Use usleep_range() to support HCALL delay
VAS allocate, modify and deallocate HCALLs returns
H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy
delay and expects OS to reissue HCALL after that delay. But using
msleep() will often sleep at least 20 msecs even though the
hypervisor suggests OS reissue these HCALLs after 1 or 10msecs.
The open and close VAS window functions hold mutex and then issue
these HCALLs. So these operations can take longer than the
necessary when multiple threads issue open or close window APIs
simultaneously, especially might affect the performance in the
case of repeat open/close APIs for each compression request.
On the large machine configuration which allows more simultaneous
open/close windows (Ex: 240 cores provides 4800 VAS credits), the
user can observe hung task traces in dmesg due to mutex contention
around open/close HCAlls.
So instead of msleep(), use usleep_range() to ensure sleep with
the expected value before issuing HCALL again.
Signed-off-by: Haren Myneni
Suggested-by: Nathan Lynch
---
v1 -> v2:
- Use usleep_range instead of using RTAS sleep routine as
suggested by Nathan
v2 -> v3:
- Sleep 10MSecs even for HCALL delay > 10MSecs and the other
commit / comemnt changes as suggested by Nathan and Ellerman.
v3 -> v4:
- More description in the commit log with the visible impact for
the current code as suggested by Aneesh
v4 -> v5:
- Use USEC_PER_MSEC macro in usleep_range as suggested by Aneesh
---
arch/powerpc/platforms/pseries/vas.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/vas.c
b/arch/powerpc/platforms/pseries/vas.c
index 71d52a670d95..79ffe8868c04 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -38,7 +38,27 @@ static long hcall_return_busy_check(long rc)
{
/* Check if we are stalled for some time */
if (H_IS_LONG_BUSY(rc)) {
- msleep(get_longbusy_msecs(rc));
+ unsigned int ms;
+ /*
+* Allocate, Modify and Deallocate HCALLs returns
+* H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC
+* for the long delay. So the sleep time should always
+* be either 1 or 10msecs, but in case if the HCALL
+* returns the long delay > 10 msecs, clamp the sleep
+* time to 10msecs.
+*/
+ ms = clamp(get_longbusy_msecs(rc), 1, 10);
+
+ /*
+* msleep() will often sleep at least 20 msecs even
+* though the hypervisor suggests that the OS reissue
+* HCALLs after 1 or 10msecs. Also the delay hint from
+* the HCALL is just a suggestion. So OK to pause for
+* less time than the hinted delay. Use usleep_range()
+* to ensure we don't sleep much longer than actually
+* needed.
+*/
+ usleep_range(ms * 100, ms * USEC_PER_MSEC);
rc = H_BUSY;
} else if (rc == H_BUSY) {
cond_resched();
--
2.26.3
Re: [PATCH 1/1] selftests: mm: hugepage-vmemmap fails on 64K page size systems.
> On Jan 10, 2024, at 23:53, Andrew Morton wrote:
>
> (cc Muchun)
> On Wed, 10 Jan 2024 14:03:35 +0530 Donet Tom
> wrote:
>
>> The kernel sefltest mm/hugepage-vmemmap fails on architectures
>> which has different page size other than 4K. In hugepage-vmemmap
>> page size used is 4k so the pfn calculation will go wrong on systems
>> which has different page size .The length of MAP_HUGETLB memory must
>> be hugepage aligned but in hugepage-vmemmap map length is 2M so this
>> will not get aligned if the system has differnet hugepage size.
>>
>> Added psize() to get the page size and default_huge_page_size() to
>> get the default hugepage size at run time, hugepage-vmemmap test pass
>> on powerpc with 64K page size and x86 with 4K page size.
>>
>> Result on powerpc without patch (page size 64K)
>> *# ./hugepage-vmemmap
>> Returned address is 0x7e00 whose pfn is 0
>> Head page flags (1) is invalid
>> check_page_flags: Invalid argument
>> *#
>>
>> Result on powerpc with patch (page size 64K)
>> *# ./hugepage-vmemmap
>> Returned address is 0x7e00 whose pfn is 600
>> *#
>>
>> Result on x86 with patch (page size 4K)
>> *# ./hugepage-vmemmap
>> Returned address is 0x7fc7c2c0 whose pfn is 1dac00
>> *#
>>
>> Signed-off-by: Donet Tom
>> Reported-by : Geetika Moolchandani (geet...@linux.ibm.com)
>> Tested-by : Geetika Moolchandani (geet...@linux.ibm.com)
Acked-by: Muchun Song
>
> I'll add
>
> Fixes: b147c89cd429 ("selftests: vm: add a hugetlb test case")
> Cc:
Yes. It should be a real bug fix.
Thanks.
Re: [PATCH 0/3] Update LLVM Phabricator and Bugzilla links
On Tue, Jan 09, 2024 at 03:16:28PM -0700, Nathan Chancellor wrote: > This series updates all instances of LLVM Phabricator and Bugzilla links > to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue > shortlinks respectively. > > I split up the Phabricator patch into BPF selftests and the rest of the > kernel in case the BPF folks want to take it separately from the rest of > the series, there are obviously no dependency issues in that case. The > Bugzilla change was mechanical enough and should have no conflicts. > > I am aiming this at Andrew and CC'ing other lists, in case maintainers > want to chime in, but I think this is pretty uncontroversial (famous > last words...). > > --- > Nathan Chancellor (3): > selftests/bpf: Update LLVM Phabricator links > arch and include: Update LLVM Phabricator links > treewide: Update LLVM Bugzilla links > > arch/arm64/Kconfig | 4 +-- > arch/powerpc/Makefile | 4 +-- > arch/powerpc/kvm/book3s_hv_nested.c| 2 +- > arch/riscv/Kconfig | 2 +- > arch/riscv/include/asm/ftrace.h| 2 +- > arch/s390/include/asm/ftrace.h | 2 +- > arch/x86/power/Makefile| 2 +- > crypto/blake2b_generic.c | 2 +- > drivers/firmware/efi/libstub/Makefile | 2 +- > drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 2 +- > drivers/media/test-drivers/vicodec/codec-fwht.c| 2 +- > drivers/regulator/Kconfig | 2 +- > include/asm-generic/vmlinux.lds.h | 2 +- > include/linux/compiler-clang.h | 2 +- > lib/Kconfig.kasan | 2 +- > lib/raid6/Makefile | 2 +- > lib/stackinit_kunit.c | 2 +- > mm/slab_common.c | 2 +- > net/bridge/br_multicast.c | 2 +- > security/Kconfig | 2 +- > tools/testing/selftests/bpf/README.rst | 32 > +++--- > tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +- > .../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +- > 23 files changed, 40 insertions(+), 40 deletions(-) > --- > base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a > change-id: 20240109-update-llvm-links-d03f9d649e1e > > Best regards, > -- > Nathan Chancellor > Excellent! Thanks for doing this. I spot checked a handful I was familiar with and everything looks good to me. Reviewed-by: Kees Cook -- Kees Cook
[PATCH] powerpc/pseries/iommu: DLPAR ADD of pci device doesn't completely initialize pci_controller structure
When a PCI device is Dynamically added, LPAR OOPS with NULL pointer
exception.
Complete stack is as below
[ 211.239206] BUG: Kernel NULL pointer dereference on read at 0x0030
[ 211.239210] Faulting instruction address: 0xc06bbe5c
[ 211.239214] Oops: Kernel access of bad area, sig: 11 [#1]
[ 211.239218] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[ 211.239223] Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5
auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding
nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc
rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser
libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs
ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core
mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto
pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse
[ 211.239280] CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66
[ 211.239284] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06
of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
[ 211.239289] NIP: c06bbe5c LR: c0a13e68 CTR: c00579f8
[ 211.239293] REGS: c0009924f240 TRAP: 0300 Not tainted (6.7.0-203405+)
[ 211.239298] MSR: 80009033 CR: 24002220
XER: 20040006
[ 211.239306] CFAR: c0a13e64 DAR: 0030 DSISR: 4000
IRQMASK: 0
[ 211.239306] GPR00: c0a13e68 c0009924f4e0 c15a2b00
[ 211.239306] GPR04: c13c5590 c6d07970
c000d8f8f180
[ 211.239306] GPR08: 06ec c000d8f8f180 c2c35d58
24002228
[ 211.239306] GPR12: c00579f8 c003ffeb3880
[ 211.239306] GPR16:
[ 211.239306] GPR20:
[ 211.239306] GPR24: c000919460c0 f000
c10088e8
[ 211.239306] GPR28: c13c5590 c6d07970 c000919460c0
c000919460c0
[ 211.239354] NIP [c06bbe5c] sysfs_add_link_to_group+0x34/0x94
[ 211.239361] LR [c0a13e68] iommu_device_link+0x5c/0x118
[ 211.239367] Call Trace:
[ 211.239369] [c0009924f4e0] [c0a109b8]
iommu_init_device+0x26c/0x318 (unreliable)
[ 211.239376] [c0009924f520] [c0a13e68]
iommu_device_link+0x5c/0x118
[ 211.239382] [c0009924f560] [c0a107f4]
iommu_init_device+0xa8/0x318
[ 211.239387] [c0009924f5c0] [c0a11a08]
iommu_probe_device+0xc0/0x134
[ 211.239393] [c0009924f600] [c0a11ac0]
iommu_bus_notifier+0x44/0x104
[ 211.239398] [c0009924f640] [c018dcc0]
notifier_call_chain+0xb8/0x19c
[ 211.239405] [c0009924f6a0] [c018df88]
blocking_notifier_call_chain+0x64/0x98
[ 211.239411] [c0009924f6e0] [c0a250fc] bus_notify+0x50/0x7c
[ 211.239416] [c0009924f720] [c0a20838] device_add+0x640/0x918
[ 211.239421] [c0009924f7f0] [c08f1a34] pci_device_add+0x23c/0x298
[ 211.239427] [c0009924f840] [c0077460]
of_create_pci_dev+0x400/0x884
[ 211.239432] [c0009924f8e0] [c0077a08] of_scan_pci_dev+0x124/0x1b0
[ 211.239437] [c0009924f980] [c0077b0c] __of_scan_bus+0x78/0x18c
[ 211.239442] [c0009924fa10] [c0073f90]
pcibios_scan_phb+0x2a4/0x3b0
[ 211.239447] [c0009924fad0] [c01007a8] init_phb_dynamic+0xb8/0x110
[ 211.239453] [c0009924fb40] [c00806920620] dlpar_add_slot+0x170/0x3b8
[rpadlpar_io]
[ 211.239461] [c0009924fbe0] [c00806920d64]
add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]
[ 211.239468] [c0009924fc70] [c0fb4144] kobj_attr_store+0x2c/0x48
[ 211.239473] [c0009924fc90] [c06b90e4] sysfs_kf_write+0x64/0x78
[ 211.239479] [c0009924fcb0] [c06b7b78]
kernfs_fop_write_iter+0x1b0/0x290
[ 211.239485] [c0009924fd00] [c05b6fdc] vfs_write+0x350/0x4a0
[ 211.239491] [c0009924fdc0] [c05b7450] ksys_write+0x84/0x140
[ 211.239496] [c0009924fe10] [c0030a04]
system_call_exception+0x124/0x330
[ 211.239502] [c0009924fe50] [c000cedc]
system_call_vectored_common+0x15c/0x2ec
Commit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities
and allow blocking domains") broke DLPAR ADD of pci devices.
The above added iommu_device structure to pci_controller. During
system boot, pci devices are discovered and this newly added iommu_device
structure initialized by a call to iommu_device_register().
During DLPAR ADD of a PCI device, a new pci_controller structure is
allocated but there are no calls made to iommu_device_register()
interface.
Fix would be to register iommu device during DLPAR ADD as well.
Fixes: a940904443e4 ("powerpc/iommu: Add iommu
Re: [PATCH 08/22] [v2] arch: consolidate arch_irq_work_raise prototypes
On Wed, Jan 10, 2024, at 10:03, Geert Uytterhoeven wrote: > On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote: >> From: Arnd Bergmann >> >> The prototype was hidden in an #ifdef on x86, which causes a warning: >> >> kernel/irq_work.c:72:13: error: no previous prototype for >> 'arch_irq_work_raise' [-Werror=missing-prototypes] > > This issue is now present upstream. > >> Some architectures have a working prototype, while others don't. >> Fix this by providing it in only one place that is always visible. >> >> Acked-by: Catalin Marinas >> Acked-by: Palmer Dabbelt >> Acked-by: Guo Ren >> Reviewed-by: Alexander Gordeev >> Signed-off-by: Arnd Bergmann > > Tested-by: Geert Uytterhoeven I've sent out the asm-generic pull request now, that contains the fix. Thanks for the reminder. Arnd
Re: [PATCH 08/22] [v2] arch: consolidate arch_irq_work_raise prototypes
On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The prototype was hidden in an #ifdef on x86, which causes a warning:
>
> kernel/irq_work.c:72:13: error: no previous prototype for
> 'arch_irq_work_raise' [-Werror=missing-prototypes]
This issue is now present upstream.
> Some architectures have a working prototype, while others don't.
> Fix this by providing it in only one place that is always visible.
>
> Acked-by: Catalin Marinas
> Acked-by: Palmer Dabbelt
> Acked-by: Guo Ren
> Reviewed-by: Alexander Gordeev
> Signed-off-by: Arnd Bergmann
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 1/1] selftests: mm: hugepage-vmemmap fails on 64K page size systems.
The kernel sefltest mm/hugepage-vmemmap fails on architectures
which has different page size other than 4K. In hugepage-vmemmap
page size used is 4k so the pfn calculation will go wrong on systems
which has different page size .The length of MAP_HUGETLB memory must
be hugepage aligned but in hugepage-vmemmap map length is 2M so this
will not get aligned if the system has differnet hugepage size.
Added psize() to get the page size and default_huge_page_size() to
get the default hugepage size at run time, hugepage-vmemmap test pass
on powerpc with 64K page size and x86 with 4K page size.
Result on powerpc without patch (page size 64K)
*# ./hugepage-vmemmap
Returned address is 0x7e00 whose pfn is 0
Head page flags (1) is invalid
check_page_flags: Invalid argument
*#
Result on powerpc with patch (page size 64K)
*# ./hugepage-vmemmap
Returned address is 0x7e00 whose pfn is 600
*#
Result on x86 with patch (page size 4K)
*# ./hugepage-vmemmap
Returned address is 0x7fc7c2c0 whose pfn is 1dac00
*#
Signed-off-by: Donet Tom
Reported-by : Geetika Moolchandani (geet...@linux.ibm.com)
Tested-by : Geetika Moolchandani (geet...@linux.ibm.com)
---
tools/testing/selftests/mm/hugepage-vmemmap.c | 29 ---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/mm/hugepage-vmemmap.c
b/tools/testing/selftests/mm/hugepage-vmemmap.c
index 5b354c209e93..894d28c3dd47 100644
--- a/tools/testing/selftests/mm/hugepage-vmemmap.c
+++ b/tools/testing/selftests/mm/hugepage-vmemmap.c
@@ -10,10 +10,7 @@
#include
#include
#include
-
-#define MAP_LENGTH (2UL * 1024 * 1024)
-
-#define PAGE_SIZE 4096
+#include "vm_util.h"
#define PAGE_COMPOUND_HEAD (1UL << 15)
#define PAGE_COMPOUND_TAIL (1UL << 16)
@@ -39,6 +36,9 @@
#define MAP_FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB)
#endif
+static size_t pagesize;
+static size_t maplength;
+
static void write_bytes(char *addr, size_t length)
{
unsigned long i;
@@ -56,7 +56,7 @@ static unsigned long virt_to_pfn(void *addr)
if (fd < 0)
return -1UL;
- lseek(fd, (unsigned long)addr / PAGE_SIZE * sizeof(pagemap), SEEK_SET);
+ lseek(fd, (unsigned long)addr / pagesize * sizeof(pagemap), SEEK_SET);
read(fd, &pagemap, sizeof(pagemap));
close(fd);
@@ -86,7 +86,7 @@ static int check_page_flags(unsigned long pfn)
* this also verifies kernel has correctly set the fake page_head to
tail
* while hugetlb_free_vmemmap is enabled.
*/
- for (i = 1; i < MAP_LENGTH / PAGE_SIZE; i++) {
+ for (i = 1; i < maplength / pagesize; i++) {
read(fd, &pageflags, sizeof(pageflags));
if ((pageflags & TAIL_PAGE_FLAGS) != TAIL_PAGE_FLAGS ||
(pageflags & HEAD_PAGE_FLAGS) == HEAD_PAGE_FLAGS) {
@@ -106,18 +106,25 @@ int main(int argc, char **argv)
void *addr;
unsigned long pfn;
- addr = mmap(MAP_ADDR, MAP_LENGTH, PROT_READ | PROT_WRITE, MAP_FLAGS,
-1, 0);
+ pagesize = psize();
+ maplength = default_huge_page_size();
+ if (!maplength) {
+ printf("Unable to determine huge page size\n");
+ exit(1);
+ }
+
+ addr = mmap(MAP_ADDR, maplength, PROT_READ | PROT_WRITE, MAP_FLAGS, -1,
0);
if (addr == MAP_FAILED) {
perror("mmap");
exit(1);
}
/* Trigger allocation of HugeTLB page. */
- write_bytes(addr, MAP_LENGTH);
+ write_bytes(addr, maplength);
pfn = virt_to_pfn(addr);
if (pfn == -1UL) {
- munmap(addr, MAP_LENGTH);
+ munmap(addr, maplength);
perror("virt_to_pfn");
exit(1);
}
@@ -125,13 +132,13 @@ int main(int argc, char **argv)
printf("Returned address is %p whose pfn is %lx\n", addr, pfn);
if (check_page_flags(pfn) < 0) {
- munmap(addr, MAP_LENGTH);
+ munmap(addr, maplength);
perror("check_page_flags");
exit(1);
}
/* munmap() length of MAP_HUGETLB memory must be hugepage aligned */
- if (munmap(addr, MAP_LENGTH)) {
+ if (munmap(addr, maplength)) {
perror("munmap");
exit(1);
}
--
2.43.0
[PATCH 3/7] macintosh: windfarm_pm121: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/windfarm_pm121.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm121.c
b/drivers/macintosh/windfarm_pm121.c
index 82500417ebee..cd45fbc4fe1c 100644
--- a/drivers/macintosh/windfarm_pm121.c
+++ b/drivers/macintosh/windfarm_pm121.c
@@ -992,15 +992,14 @@ static int pm121_probe(struct platform_device *ddev)
return 0;
}
-static int pm121_remove(struct platform_device *ddev)
+static void pm121_remove(struct platform_device *ddev)
{
wf_unregister_client(&pm121_events);
- return 0;
}
static struct platform_driver pm121_driver = {
.probe = pm121_probe,
- .remove = pm121_remove,
+ .remove_new = pm121_remove,
.driver = {
.name = "windfarm",
.bus = &platform_bus_type,
--
2.43.0
[PATCH 1/7] macintosh: therm_windtunnel: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/therm_windtunnel.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 3c1b29476ce2..37cdc6931f6d 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -481,11 +481,9 @@ static int therm_of_probe(struct platform_device *dev)
return -ENODEV;
}
-static int
-therm_of_remove( struct platform_device *dev )
+static void therm_of_remove(struct platform_device *dev)
{
i2c_del_driver( &g4fan_driver );
- return 0;
}
static const struct of_device_id therm_of_match[] = {{
@@ -501,7 +499,7 @@ static struct platform_driver therm_of_driver = {
.of_match_table = therm_of_match,
},
.probe = therm_of_probe,
- .remove = therm_of_remove,
+ .remove_new = therm_of_remove,
};
struct apple_thermal_info {
--
2.43.0
[PATCH 6/7] macintosh: windfarm_pm91: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/windfarm_pm91.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm91.c
b/drivers/macintosh/windfarm_pm91.c
index 120a9cfba0c5..fba02a375435 100644
--- a/drivers/macintosh/windfarm_pm91.c
+++ b/drivers/macintosh/windfarm_pm91.c
@@ -647,7 +647,7 @@ static int wf_smu_probe(struct platform_device *ddev)
return 0;
}
-static int wf_smu_remove(struct platform_device *ddev)
+static void wf_smu_remove(struct platform_device *ddev)
{
wf_unregister_client(&wf_smu_events);
@@ -691,13 +691,11 @@ static int wf_smu_remove(struct platform_device *ddev)
kfree(wf_smu_slots_fans);
kfree(wf_smu_drive_fans);
kfree(wf_smu_cpu_fans);
-
- return 0;
}
static struct platform_driver wf_smu_driver = {
-.probe = wf_smu_probe,
-.remove = wf_smu_remove,
+ .probe = wf_smu_probe,
+ .remove_new = wf_smu_remove,
.driver = {
.name = "windfarm",
},
--
2.43.0
[PATCH 2/7] macintosh: windfarm_pm112: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/windfarm_pm112.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm112.c
b/drivers/macintosh/windfarm_pm112.c
index d1dec314ae30..876b4d8cbe37 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++ b/drivers/macintosh/windfarm_pm112.c
@@ -662,16 +662,14 @@ static int wf_pm112_probe(struct platform_device *dev)
return 0;
}
-static int wf_pm112_remove(struct platform_device *dev)
+static void wf_pm112_remove(struct platform_device *dev)
{
wf_unregister_client(&pm112_events);
- /* should release all sensors and controls */
- return 0;
}
static struct platform_driver wf_pm112_driver = {
.probe = wf_pm112_probe,
- .remove = wf_pm112_remove,
+ .remove_new = wf_pm112_remove,
.driver = {
.name = "windfarm",
},
--
2.43.0
[PATCH 0/7] macintosh: Convert to platform remove callback returning void
Hello,
this series converts all drivers below drivers/macintosh to use
.remove_new(). See commit 5c5a7680e67b ("platform: Provide a remove
callback that returns no value") for an extended explanation and the
eventual goal. The TL;DR; is to make it harder for driver authors to
leak resources without noticing.
This is merge window material. All patches are pairwise independent of
each other so they can be applied individually. There isn't a maintainer
for drivers/macintosh, I'm still sending this as a series in the hope
Michael feels repsonsible and applies it completely.
Best regards
Uwe
Uwe Kleine-König (7):
macintosh: therm_windtunnel: Convert to platform remove callback returning
void
macintosh: windfarm_pm112: Convert to platform remove callback returning void
macintosh: windfarm_pm121: Convert to platform remove callback returning void
macintosh: windfarm_pm72: Convert to platform remove callback returning void
macintosh: windfarm_pm81: Convert to platform remove callback returning void
macintosh: windfarm_pm91: Convert to platform remove callback returning void
macintosh: windfarm_rm31: Convert to platform remove callback returning void
drivers/macintosh/therm_windtunnel.c | 6 ++
drivers/macintosh/windfarm_pm112.c | 6 ++
drivers/macintosh/windfarm_pm121.c | 5 ++---
drivers/macintosh/windfarm_pm72.c| 7 ++-
drivers/macintosh/windfarm_pm81.c| 8 +++-
drivers/macintosh/windfarm_pm91.c| 8 +++-
drivers/macintosh/windfarm_rm31.c| 7 ++-
7 files changed, 16 insertions(+), 31 deletions(-)
base-commit: 8cb47d7cd090a690c1785385b2f3d407d4a53ad0
--
2.43.0
[PATCH 4/7] macintosh: windfarm_pm72: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/windfarm_pm72.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm72.c
b/drivers/macintosh/windfarm_pm72.c
index e21f973551cc..14fa1e9ac3e0 100644
--- a/drivers/macintosh/windfarm_pm72.c
+++ b/drivers/macintosh/windfarm_pm72.c
@@ -775,17 +775,14 @@ static int wf_pm72_probe(struct platform_device *dev)
return 0;
}
-static int wf_pm72_remove(struct platform_device *dev)
+static void wf_pm72_remove(struct platform_device *dev)
{
wf_unregister_client(&pm72_events);
-
- /* should release all sensors and controls */
- return 0;
}
static struct platform_driver wf_pm72_driver = {
.probe = wf_pm72_probe,
- .remove = wf_pm72_remove,
+ .remove_new = wf_pm72_remove,
.driver = {
.name = "windfarm",
},
--
2.43.0
[PATCH 7/7] macintosh: windfarm_rm31: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/windfarm_rm31.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/macintosh/windfarm_rm31.c
b/drivers/macintosh/windfarm_rm31.c
index e9eb7fdde48c..dc8f2c7ef103 100644
--- a/drivers/macintosh/windfarm_rm31.c
+++ b/drivers/macintosh/windfarm_rm31.c
@@ -668,17 +668,14 @@ static int wf_rm31_probe(struct platform_device *dev)
return 0;
}
-static int wf_rm31_remove(struct platform_device *dev)
+static void wf_rm31_remove(struct platform_device *dev)
{
wf_unregister_client(&rm31_events);
-
- /* should release all sensors and controls */
- return 0;
}
static struct platform_driver wf_rm31_driver = {
.probe = wf_rm31_probe,
- .remove = wf_rm31_remove,
+ .remove_new = wf_rm31_remove,
.driver = {
.name = "windfarm",
},
--
2.43.0
[PATCH 5/7] macintosh: windfarm_pm81: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/windfarm_pm81.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm81.c
b/drivers/macintosh/windfarm_pm81.c
index 257fb2c695c5..404d2454e33d 100644
--- a/drivers/macintosh/windfarm_pm81.c
+++ b/drivers/macintosh/windfarm_pm81.c
@@ -724,7 +724,7 @@ static int wf_smu_probe(struct platform_device *ddev)
return 0;
}
-static int wf_smu_remove(struct platform_device *ddev)
+static void wf_smu_remove(struct platform_device *ddev)
{
wf_unregister_client(&wf_smu_events);
@@ -761,13 +761,11 @@ static int wf_smu_remove(struct platform_device *ddev)
/* Destroy control loops state structures */
kfree(wf_smu_sys_fans);
kfree(wf_smu_cpu_fans);
-
- return 0;
}
static struct platform_driver wf_smu_driver = {
-.probe = wf_smu_probe,
-.remove = wf_smu_remove,
+ .probe = wf_smu_probe,
+ .remove_new = wf_smu_remove,
.driver = {
.name = "windfarm",
},
--
2.43.0
Re: [PATCH 1/1] selftests: mm: hugepage-vmemmap fails on 64K page size systems.
(cc Muchun)
On Wed, 10 Jan 2024 14:03:35 +0530 Donet Tom
wrote:
> The kernel sefltest mm/hugepage-vmemmap fails on architectures
> which has different page size other than 4K. In hugepage-vmemmap
> page size used is 4k so the pfn calculation will go wrong on systems
> which has different page size .The length of MAP_HUGETLB memory must
> be hugepage aligned but in hugepage-vmemmap map length is 2M so this
> will not get aligned if the system has differnet hugepage size.
>
> Added psize() to get the page size and default_huge_page_size() to
> get the default hugepage size at run time, hugepage-vmemmap test pass
> on powerpc with 64K page size and x86 with 4K page size.
>
> Result on powerpc without patch (page size 64K)
> *# ./hugepage-vmemmap
> Returned address is 0x7e00 whose pfn is 0
> Head page flags (1) is invalid
> check_page_flags: Invalid argument
> *#
>
> Result on powerpc with patch (page size 64K)
> *# ./hugepage-vmemmap
> Returned address is 0x7e00 whose pfn is 600
> *#
>
> Result on x86 with patch (page size 4K)
> *# ./hugepage-vmemmap
> Returned address is 0x7fc7c2c0 whose pfn is 1dac00
> *#
>
> Signed-off-by: Donet Tom
> Reported-by : Geetika Moolchandani (geet...@linux.ibm.com)
> Tested-by : Geetika Moolchandani (geet...@linux.ibm.com)
I'll add
Fixes: b147c89cd429 ("selftests: vm: add a hugetlb test case")
Cc:
>
> diff --git a/tools/testing/selftests/mm/hugepage-vmemmap.c
> b/tools/testing/selftests/mm/hugepage-vmemmap.c
> index 5b354c209e93..894d28c3dd47 100644
> --- a/tools/testing/selftests/mm/hugepage-vmemmap.c
> +++ b/tools/testing/selftests/mm/hugepage-vmemmap.c
> @@ -10,10 +10,7 @@
> #include
> #include
> #include
> -
> -#define MAP_LENGTH (2UL * 1024 * 1024)
> -
> -#define PAGE_SIZE4096
> +#include "vm_util.h"
>
> #define PAGE_COMPOUND_HEAD (1UL << 15)
> #define PAGE_COMPOUND_TAIL (1UL << 16)
> @@ -39,6 +36,9 @@
> #define MAP_FLAGS(MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB)
> #endif
>
> +static size_t pagesize;
> +static size_t maplength;
> +
> static void write_bytes(char *addr, size_t length)
> {
> unsigned long i;
> @@ -56,7 +56,7 @@ static unsigned long virt_to_pfn(void *addr)
> if (fd < 0)
> return -1UL;
>
> - lseek(fd, (unsigned long)addr / PAGE_SIZE * sizeof(pagemap), SEEK_SET);
> + lseek(fd, (unsigned long)addr / pagesize * sizeof(pagemap), SEEK_SET);
> read(fd, &pagemap, sizeof(pagemap));
> close(fd);
>
> @@ -86,7 +86,7 @@ static int check_page_flags(unsigned long pfn)
>* this also verifies kernel has correctly set the fake page_head to
> tail
>* while hugetlb_free_vmemmap is enabled.
>*/
> - for (i = 1; i < MAP_LENGTH / PAGE_SIZE; i++) {
> + for (i = 1; i < maplength / pagesize; i++) {
> read(fd, &pageflags, sizeof(pageflags));
> if ((pageflags & TAIL_PAGE_FLAGS) != TAIL_PAGE_FLAGS ||
> (pageflags & HEAD_PAGE_FLAGS) == HEAD_PAGE_FLAGS) {
> @@ -106,18 +106,25 @@ int main(int argc, char **argv)
> void *addr;
> unsigned long pfn;
>
> - addr = mmap(MAP_ADDR, MAP_LENGTH, PROT_READ | PROT_WRITE, MAP_FLAGS,
> -1, 0);
> + pagesize = psize();
> + maplength = default_huge_page_size();
> + if (!maplength) {
> + printf("Unable to determine huge page size\n");
> + exit(1);
> + }
> +
> + addr = mmap(MAP_ADDR, maplength, PROT_READ | PROT_WRITE, MAP_FLAGS, -1,
> 0);
> if (addr == MAP_FAILED) {
> perror("mmap");
> exit(1);
> }
>
> /* Trigger allocation of HugeTLB page. */
> - write_bytes(addr, MAP_LENGTH);
> + write_bytes(addr, maplength);
>
> pfn = virt_to_pfn(addr);
> if (pfn == -1UL) {
> - munmap(addr, MAP_LENGTH);
> + munmap(addr, maplength);
> perror("virt_to_pfn");
> exit(1);
> }
> @@ -125,13 +132,13 @@ int main(int argc, char **argv)
> printf("Returned address is %p whose pfn is %lx\n", addr, pfn);
>
> if (check_page_flags(pfn) < 0) {
> - munmap(addr, MAP_LENGTH);
> + munmap(addr, maplength);
> perror("check_page_flags");
> exit(1);
> }
>
> /* munmap() length of MAP_HUGETLB memory must be hugepage aligned */
> - if (munmap(addr, MAP_LENGTH)) {
> + if (munmap(addr, maplength)) {
> perror("munmap");
> exit(1);
> }
> --
> 2.43.0
Re: [PATCH v2 10/14] riscv: Add support for kernel-mode FPU
On Wed, 27 Dec 2023 17:42:00 PST (-0800), samuel.holl...@sifive.com wrote:
This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.
Signed-off-by: Samuel Holland
---
Changes in v2:
- Remove RISC-V architecture-specific preprocessor check
arch/riscv/Kconfig | 1 +
arch/riscv/Makefile | 3 +++
arch/riscv/include/asm/fpu.h| 16
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/kernel_mode_fpu.c | 28
5 files changed, 49 insertions(+)
create mode 100644 arch/riscv/include/asm/fpu.h
create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 24c1799e2ec4..4d4d1d64ce34 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -27,6 +27,7 @@ config RISCV
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
+ select ARCH_HAS_KERNEL_FPU_SUPPORT if FPU
select ARCH_HAS_MMIOWB
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_PMEM_API
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index a74be78678eb..2e719c369210 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -81,6 +81,9 @@ KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed
-E 's/(rv32ima|rv64i
KBUILD_AFLAGS += -march=$(riscv-march-y)
+# For C code built with floating-point support, exclude V but keep F and D.
+CC_FLAGS_FPU := -march=$(shell echo $(riscv-march-y) | sed -E
's/(rv32ima|rv64ima)([^v_]*)v?/\1\2/')
+
KBUILD_CFLAGS += -mno-save-restore
KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
diff --git a/arch/riscv/include/asm/fpu.h b/arch/riscv/include/asm/fpu.h
new file mode 100644
index ..91c04c244e12
--- /dev/null
+++ b/arch/riscv/include/asm/fpu.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_RISCV_FPU_H
+#define _ASM_RISCV_FPU_H
+
+#include
+
+#define kernel_fpu_available() has_fpu()
+
+void kernel_fpu_begin(void);
+void kernel_fpu_end(void);
+
+#endif /* ! _ASM_RISCV_FPU_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index fee22a3d1b53..662c483e338d 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_MMU) += vdso.o vdso/
obj-$(CONFIG_RISCV_MISALIGNED) += traps_misaligned.o
obj-$(CONFIG_FPU) += fpu.o
+obj-$(CONFIG_FPU) += kernel_mode_fpu.o
obj-$(CONFIG_RISCV_ISA_V) += vector.o
obj-$(CONFIG_SMP) += smpboot.o
obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/riscv/kernel/kernel_mode_fpu.c
b/arch/riscv/kernel/kernel_mode_fpu.c
new file mode 100644
index ..0ac8348876c4
--- /dev/null
+++ b/arch/riscv/kernel/kernel_mode_fpu.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+void kernel_fpu_begin(void)
+{
+ preempt_disable();
+ fstate_save(current, task_pt_regs(current));
+ csr_set(CSR_SSTATUS, SR_FS);
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+
+void kernel_fpu_end(void)
+{
+ csr_clear(CSR_SSTATUS, SR_FS);
+ fstate_restore(current, task_pt_regs(current));
+ preempt_enable();
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_end);
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
assuming you want to keep these together -- it touches a lot of stuff,
so LMK if you want me to pick something up.
Thanks!
[PATCH v2] powerpc/Makefile: Remove bits related to the previous use of -mcmodel=large
All supported compilers today (gcc v5.1+ and clang v11+) have support for -mcmodel=medium. As such, NO_MINIMAL_TOC is no longer being set. Remove NO_MINIMAL_TOC as well as the fallback to -mminimal-toc. Reviewed-by: Christophe Leroy Signed-off-by: Naveen N Rao --- v2: Drop the call to cc-option so we break the build if we ever use a compiler that does not support the medium code model. arch/powerpc/Makefile | 6 +- arch/powerpc/kernel/Makefile| 3 --- arch/powerpc/lib/Makefile | 2 -- arch/powerpc/mm/Makefile| 2 -- arch/powerpc/mm/book3s64/Makefile | 2 -- arch/powerpc/mm/nohash/Makefile | 2 -- arch/powerpc/platforms/pseries/Makefile | 1 - arch/powerpc/sysdev/Makefile| 2 -- arch/powerpc/xmon/Makefile | 2 -- 9 files changed, 1 insertion(+), 21 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 051247027da0..bbe0f99b50e8 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -114,7 +114,6 @@ LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y) ifdef CONFIG_PPC64 ifndef CONFIG_PPC_KERNEL_PCREL -ifeq ($(call cc-option-yn,-mcmodel=medium),y) # -mcmodel=medium breaks modules because it uses 32bit offsets from # the TOC pointer to create pointers where possible. Pointers into the # percpu data area are created by this method. @@ -124,9 +123,6 @@ ifeq ($(call cc-option-yn,-mcmodel=medium),y) # kernel percpu data space (starting with 0xc...). We need a full # 64bit relocation for this to work, hence -mcmodel=large. KBUILD_CFLAGS_MODULE += -mcmodel=large -else - export NO_MINIMAL_TOC := -mno-minimal-toc -endif endif endif @@ -139,7 +135,7 @@ CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc) endif endif -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc)) +CFLAGS-$(CONFIG_PPC64) += -mcmodel=medium CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mlong-double-128) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 2919433be355..2b0567926259 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -3,9 +3,6 @@ # Makefile for the linux kernel. # -ifdef CONFIG_PPC64 -CFLAGS_prom_init.o += $(NO_MINIMAL_TOC) -endif ifdef CONFIG_PPC32 CFLAGS_prom_init.o += -fPIC CFLAGS_btext.o += -fPIC diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 6eac63e79a89..50d88651d04f 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -3,8 +3,6 @@ # Makefile for ppc-specific library files.. # -ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC) - CFLAGS_code-patching.o += -fno-stack-protector CFLAGS_feature-fixups.o += -fno-stack-protector diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile index 503a6e249940..0fe2f085c05a 100644 --- a/arch/powerpc/mm/Makefile +++ b/arch/powerpc/mm/Makefile @@ -3,8 +3,6 @@ # Makefile for the linux ppc-specific parts of the memory manager. # -ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC) - obj-y := fault.o mem.o pgtable.o maccess.o pageattr.o \ init_$(BITS).o pgtable_$(BITS).o \ pgtable-frag.o ioremap.o ioremap_$(BITS).o \ diff --git a/arch/powerpc/mm/book3s64/Makefile b/arch/powerpc/mm/book3s64/Makefile index cad2abc1730f..33af5795856a 100644 --- a/arch/powerpc/mm/book3s64/Makefile +++ b/arch/powerpc/mm/book3s64/Makefile @@ -1,7 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -ccflags-y := $(NO_MINIMAL_TOC) - obj-y += mmu_context.o pgtable.o trace.o ifdef CONFIG_PPC_64S_HASH_MMU CFLAGS_REMOVE_slb.o = $(CC_FLAGS_FTRACE) diff --git a/arch/powerpc/mm/nohash/Makefile b/arch/powerpc/mm/nohash/Makefile index f3894e79d5f7..b3f0498dd42f 100644 --- a/arch/powerpc/mm/nohash/Makefile +++ b/arch/powerpc/mm/nohash/Makefile @@ -1,7 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC) - obj-y += mmu_context.o tlb.o tlb_low.o kup.o obj-$(CONFIG_PPC_BOOK3E_64)+= tlb_low_64e.o book3e_pgtable.o obj-$(CONFIG_40x) += 40x.o diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile index f936962a2946..7bf506f6b8c8 100644 --- a/arch/powerpc/platforms/pseries/Makefile +++ b/arch/powerpc/platforms/pseries/Makefile @@ -1,5 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC) ccflags-$(CONFIG_PPC_PSERIES_DEBUG)+= -DDEBUG obj-y := lpar.o hvCall.o nvram.o reconfig.o \ diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile index 9cb1d029511a..24a177d1
Re: [PATCH] powerpc/Makefile: Remove bits related to the previous use of -mcmodel=large
On Tue, Jan 09, 2024 at 12:39:36PM -0600, Segher Boessenkool wrote: > On Tue, Jan 09, 2024 at 03:15:35PM +, Christophe Leroy wrote: > > > CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc) > > > endif > > > endif > > > -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call > > > cc-option,-mminimal-toc)) > > > +CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium) > > > > Should we still use $(call cc-option here ? > > As we only deal with medium model now, shouldn't we make it such that it > > fails in case the compiler doesn't support -mcmodel=medium ? Yup, v2 on its way. > > The -mcmodel= flag has been supported since 2010. The kernel requires > a GCC from 2015 or later (GCC 5.1 is the minimum). -mcmodel=medium is > (and always has been) the default, so it is always supported, yes. Thanks for confirming! - Naveen
Re: [PATCH 2/3] arch and include: Update LLVM Phabricator links
On Tue, Jan 09, 2024 at 03:16:30PM -0700, Nathan Chancellor wrote: > reviews.llvm.org was LLVM's Phabricator instances for code review. It > has been abandoned in favor of GitHub pull requests. While the majority > of links in the kernel sources still work because of the work Fangrui > has done turning the dynamic Phabricator instance into a static archive, > there are some issues with that work, so preemptively convert all the > links in the kernel sources to point to the commit on GitHub. > > Most of the commits have the corresponding differential review link in > the commit message itself so there should not be any loss of fidelity in > the relevant information. > > Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172 > Signed-off-by: Nathan Chancellor > --- > arch/riscv/Kconfig | 2 +- > arch/riscv/include/asm/ftrace.h | 2 +- Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 3/3] ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 platform
On Tue, Jan 09, 2024 at 04:55:51PM +0900, Chancel Liu wrote: > Add compatible string "fsl,imx95-micfil" for i.MX95 platform. > > Signed-off-by: Chancel Liu > --- > .../devicetree/bindings/sound/fsl,micfil.yaml | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml > b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml > index b7e605835639..f0d3d11d07d2 100644 > --- a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml > +++ b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml > @@ -15,10 +15,17 @@ description: | > > properties: >compatible: > -enum: > - - fsl,imx8mm-micfil > - - fsl,imx8mp-micfil > - - fsl,imx93-micfil > +oneOf: > + - items: > + - enum: > + - fsl,imx95-micfil > + - const: fsl,imx93-micfil > + > + - items: This items is not needed, as the only item in the list is the enum. You can just do properties: compatible: oneOf: - items: - enum: - fsl,imx95-micfil - const: fsl,imx93-micfil - enum: - fsl,imx8mm-micfil - fsl,imx8mp-micfil - fsl,imx93-micfil Cheers, Conor. > + - enum: > + - fsl,imx8mm-micfil > + - fsl,imx8mp-micfil > + - fsl,imx93-micfil > >reg: > maxItems: 1 > -- > 2.42.0 > signature.asc Description: PGP signature
RE: Re: [PATCH 3/3] ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 platform
> On Tue, Jan 9, 2024 at 9:58 AM Chancel Liu wrote:
> >
> > Add compatible string "fsl,imx95-micfil" for i.MX95 platform.
> >
> > Signed-off-by: Chancel Liu
> > ---
> > .../devicetree/bindings/sound/fsl,micfil.yaml | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
> b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
> > index b7e605835639..f0d3d11d07d2 100644
> > --- a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
> > +++ b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
> > @@ -15,10 +15,17 @@ description: |
> >
> > properties:
> >compatible:
> > -enum:
> > - - fsl,imx8mm-micfil
> > - - fsl,imx8mp-micfil
> > - - fsl,imx93-micfil
> > +oneOf:
> > + - items:
> > + - enum:
> > + - fsl,imx95-micfil
> > + - const: fsl,imx93-micfil
> > +
> > + - items:
> > + - enum:
> > + - fsl,imx8mm-micfil
> > + - fsl,imx8mp-micfil
> > + - fsl,imx93-micfil
>
> My yaml knowledge is very limited. Can you describe in natural
> language in the commit what exactly we are doing here.
>
> Why something like this:
>
>
> >compatible:
> > enum:
> > - fsl,imx8mm-micfil
> > - fsl,imx8mp-micfil
> > - fsl,imx93-micfil
> +- fsl,imx95-micfil
>
> Isn't enough?
No. This shows MICFIL on i.MX95 is different from it on I.MX93.
However i.MX95 MICFIL is compatible with i.MX93 MICFIL.
The DT node of MICFIL on i.MX95 looks like:
micfil: micfil@4452 {
compatible = "fsl,imx95-micfil", "fsl,imx93-micfil";
...
};
Regards,
Chancel Liu
