On 2024-08-30 02:35, Baoquan He wrote:
> The overrall looks good to me except of the CRASH_DUMP=n on sh, do you
> have a comment about the reasoning since you have discussed with John?
> Is it because of below config items?
I don't yet know why John asked to turn this off by default on sh, though
Hi Will,
On Fri, 23 Aug 2024 14:48:11 +0100,
Will Deacon wrote:
>
> On Thu, Aug 22, 2024 at 04:10:51PM +0100, Joey Gouly wrote:
> > To allow using newer instructions that current assemblers don't know about,
> > replace the `at` instruction with the underlying SYS instruction.
> >
> > Signed-of
Hey Marc,
On Fri, Aug 30, 2024 at 09:01:18AM +0100, Marc Zyngier wrote:
> On Fri, 23 Aug 2024 14:48:11 +0100,
> Will Deacon wrote:
> >
> > On Thu, Aug 22, 2024 at 04:10:51PM +0100, Joey Gouly wrote:
> > > To allow using newer instructions that current assemblers don't know
> > > about,
> > > re
On Thu, Aug 22, 2024 at 04:10:51PM +0100, Joey Gouly wrote:
> To allow using newer instructions that current assemblers don't know about,
> replace the `at` instruction with the underlying SYS instruction.
>
> Signed-off-by: Joey Gouly
> Cc: Marc Zyngier
> Cc: Oliver Upton
> Cc: Catalin Marinas
On 2024/8/29 20:46, Pierre Gondois wrote:
> Hello Yicong,
>
> On 8/29/24 09:40, Yicong Yang wrote:
>> Hi Pierre,
>>
>> On 2024/8/27 23:40, Pierre Gondois wrote:
>>> Hello Yicong,
>>> IIUC we are looking for the maximum number of threads a CPU can have
>>> in the platform. But is is actually possib
On Thu, Aug 29, 2024 at 03:16:53PM GMT, Charlie Jenkins wrote:
> On Thu, Aug 29, 2024 at 10:54:25AM +0100, Lorenzo Stoakes wrote:
> > On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> > > On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> > > > Some applications rely on
Segher Boessenkool writes:
> On Thu, Aug 29, 2024 at 07:36:38PM +0200, Christophe Leroy wrote:
>>
>>
>> Le 28/08/2024 à 19:25, Segher Boessenkool a écrit :
>> >
>> >>Not sure about static binaries, though: do those even use the VDSO?
>> >
>> >With "static binary" people usually mean "a binary no
cuigaosheng writes:
> On 2024/8/22 22:16, LEROY Christophe wrote:
>>
>> Le 22/08/2024 à 15:06, Gaosheng Cui a écrit :
>>> [Vous ne recevez pas souvent de courriers de cuigaoshe...@huawei.com.
>>> Découvrez pourquoi ceci est important à
>>> https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>>
Christophe Leroy writes:
> Le 27/08/2024 à 11:12, Ritesh Harjani (IBM) a écrit :
>> [Vous ne recevez pas souvent de courriers de ritesh.l...@gmail.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Use pr_warn_once instead of WARN_ON_ONCE as
On 08/20/24 at 12:10pm, Sourabh Jain wrote:
> Hello Baoquan,
>
> On 19/08/24 11:45, Baoquan He wrote:
> > On 08/19/24 at 09:45am, Sourabh Jain wrote:
> > > Hello Michael and Boaquan
> > >
> > > On 01/08/24 12:21, Sourabh Jain wrote:
> > > > Hello Michael,
> > > >
> > > > On 01/08/24 08:04, Micha
On Fri, 30 Aug 2024 10:25:27 +0100,
Will Deacon wrote:
>
> On Thu, Aug 22, 2024 at 04:10:51PM +0100, Joey Gouly wrote:
> > To allow using newer instructions that current assemblers don't know about,
> > replace the `at` instruction with the underlying SYS instruction.
> >
> > Signed-off-by: Joey
Use dev_err_probe() to simplify the error path and unify a message
template.
Using this helper is totally fine even if err is known to never
be -EPROBE_DEFER.
The benefit compared to a normal dev_err() is the standardized format
of the error code, it being emitted symbolically and the fact that
t
This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
Replace kretprobe with rethook on x86") to powerpc.
Rethook follows the existing kretprobe implementation, but separates
it from kprobes so that it can be used by fprobe (ftrace-based
function entry/exit probes). As such, this pat
On Fri, Aug 30, 2024 at 12:23:33PM +0100, Marc Zyngier wrote:
> On Fri, 30 Aug 2024 10:25:27 +0100,
> Will Deacon wrote:
> >
> > On Thu, Aug 22, 2024 at 04:10:51PM +0100, Joey Gouly wrote:
> > > To allow using newer instructions that current assemblers don't know
> > > about,
> > > replace the `
On Fri, 30 Aug 2024 10:05:22 +0100,
Will Deacon wrote:
>
> Hey Marc,
>
> On Fri, Aug 30, 2024 at 09:01:18AM +0100, Marc Zyngier wrote:
> > On Fri, 23 Aug 2024 14:48:11 +0100,
> > Will Deacon wrote:
> > >
> > > On Thu, Aug 22, 2024 at 04:10:51PM +0100, Joey Gouly wrote:
> > > > To allow using n
Following error occurs when running vdso_test_correctness on powerpc:
~ # ./vdso_test_correctness
[WARN] failed to find vDSO
[SKIP] No vDSO, so skipping clock_gettime() tests
[SKIP] No vDSO, so skipping clock_gettime64() tests
[RUN] Testing getcpu...
[OK]CPU 0: syscall: cpu 0, node 0
On
Running vdso_test_correctness on powerpc64 gives the following warning:
~ # ./vdso_test_correctness
Warning: failed to find clock_gettime64 in vDSO
This is because vdso_test_correctness was built with VDSO_32BIT defined.
__powerpc__ macro is defined on both powerpc32 and powerpc64 so
__power
On powerpc64, following tests fail locating vDSO functions:
~ # ./vdso_test_abi
TAP version 13
1..16
# [vDSO kselftest] VDSO_VERSION: LINUX_2.6.15
# Couldn't find __kernel_gettimeofday
ok 1 # SKIP __kernel_gettimeofday
# clock_id: CLOCK_REALTIME
# Couldn't find __kernel_clock_getti
vdso_test_correctness test fails on powerpc:
~ # ./vdso_test_correctness
...
[RUN] Testing clock_gettime for clock CLOCK_REALTIME_ALARM (8)...
[FAIL] No such clock, but __vdso_clock_gettime returned 22
[RUN] Testing clock_gettime for clock CLOCK_BOOTTIME_ALARM (9)...
[FAIL] No such clock, bu
Don't duplicate parse_vdso function prototypes, include
the header instead.
Fixes: 693f5ca08ca0 ("kselftest: Extend vDSO selftest")
Signed-off-by: Christophe Leroy
---
tools/testing/selftests/vDSO/vdso_test_abi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/testi
Hi Shuah,
No 0/5 patch, so replying to the first one.
These are fixes to the vDSO selftests that Christophe is ostensibly
providing as a preamble to his work porting vgetrandom to PPC. Do you
mind if I take these via my random tree so his PPC vgetrandom code can
go on top of it?
Jason
On Tue, 14 May 2024, Ilpo Järvinen wrote:
> This series has the remaining patches of the AER & DPC TLP Log handling
> consolidation and now includes a few minor improvements to the earlier
> accepted TLP Logging code.
>
> v5:
> - Fix build with AER=y and DPC=n
> - Match kerneldoc and function par
On 8/30/24 06:41, Jason A. Donenfeld wrote:
Hi Shuah,
No 0/5 patch, so replying to the first one.
These are fixes to the vDSO selftests that Christophe is ostensibly
providing as a preamble to his work porting vgetrandom to PPC. Do you
mind if I take these via my random tree so his PPC vgetrand
Zero and negative number is not a valid IRQ for in-kernel code and the
irq_of_parse_and_map() function returns zero on error. So this check for
valid IRQs should only accept values > 0.
Cc: sta...@vger.kernel.org
Fixes: f7578496a671 ("of/irq: Use irq_of_parse_and_map()")
Signed-off-by: Ma Ke
---
Inspired by commit d57d6fe5bf34 ("drivers: hv: log when enabling
crash_kexec_post_notifiers"),
a good idea is to signal on dmesg about unconditionally enabling the kernel
parameter crash_kexec_post_notifiers, which affects how kdump works.
By checking the source code, found 2 more cases besides H
On 8/29/24 01:42, Lorenzo Stoakes wrote:
>> These applications work on x86 because x86 does an implicit 47-bit
>> restriction of mmap() address that contain a hint address that is less
>> than 48 bits.
> You mean x86 _has_ to limit to physically available bits in a canonical
> format 🙂 this will no
On Fri, Aug 30, 2024 at 08:03:25AM GMT, Dave Hansen wrote:
> On 8/29/24 01:42, Lorenzo Stoakes wrote:
> >> These applications work on x86 because x86 does an implicit 47-bit
> >> restriction of mmap() address that contain a hint address that is less
> >> than 48 bits.
> > You mean x86 _has_ to limi
This series wires up getrandom() vDSO implementation on powerpc.
Tested on PPC32 on real hardware.
Tested on PPC64 (both BE and LE) on QEMU:
Performance on powerpc 885:
~# ./vdso_test_getrandom bench-single
vdso: 2500 times in 62.938002291 seconds
libc: 2500
Commit 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always
lazily freeable mappings") only adds VM_DROPPABLE for 64 bits
architectures.
In order to also use the getrandom vDSO implementation on powerpc/32,
use VM_ARCH_1 for VM_DROPPABLE on powerpc/32. This is possible because
VM_ARCH_1 is
Commit 08c18b63d965 ("powerpc/vdso32: Add missing _restgpr_31_x to fix
build failure") added _restgpr_31_x to the vdso for gettimeofday, but
the work on getrandom shows that we will need more of those functions.
Remove _restgpr_31_x and link in crtsavres.o so that we get all
save/restore functions
In order to avoid two much duplication when we add new VDSO
functionnalities in C like getrandom, refactor common CFLAGS.
Signed-off-by: Christophe Leroy
---
v3: Also refactor removed flags
---
arch/powerpc/kernel/vdso/Makefile | 32 +--
1 file changed, 13 insertions(
To be consistent with other VDSO functions, the function is called
__kernel_getrandom()
__arch_chacha20_blocks_nostack() fonction is implemented basically
with 32 bits operations. It performs 4 QUARTERROUND operations in
parallele. There are enough registers to avoid using the stack:
On input:
Extend getrandom() vDSO implementation to powerpc64.
Tested on QEMU on both ppc64_defconfig and ppc64le_defconfig.
The results are not precise as it is QEMU on an x86 laptop, but
no need to be precise to see the benefit.
~ # ./vdso_test_getrandom bench-single
vdso: 2500 times in 4.971
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
> + * r5: 8-byte counter input/output (saved on stack)
> + *
> + * r14-r15: counter
> + */
> +SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> + stwur1, -96(r1)
> + stw r5, 20(r1)
> + stmwr14, 24(r1)
> +
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
> @@ -14,6 +14,10 @@ ifeq ($(uname_M),x86_64)
> TEST_GEN_PROGS += vdso_test_getrandom
> TEST_GEN_PROGS += vdso_test_chacha
> endif
> +ifeq ($(ARCH),powerpc)
> +TEST_GEN_PROGS += vdso_test_getrandom
> +TEST_GEN_PROGS += vdso_test_c
Le 30/08/2024 à 18:14, Jason A. Donenfeld a écrit :
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
+ * r5: 8-byte counter input/output (saved on stack)
+ *
+ * r14-r15: counter
+ */
+SYM_FUNC_START(__arch_chacha20_blocks_nostack)
+ stwur1, -96(r1)
+
Le 30/08/2024 à 18:42, Christophe Leroy a écrit :
Le 30/08/2024 à 18:14, Jason A. Donenfeld a écrit :
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
+ * r5: 8-byte counter input/output (saved on stack)
+ *
+ * r14-r15: counter
+ */
+SYM_FUNC_START(__arch_chacha20_b
On 30/08/2024 14:54, Stephen Brennan wrote:
> [...]
> Could we maybe go further than this, and delete the public declarations
> of crash_kexec_post_notifiers in "include/linux"? (I see two). We could
> replace the users that set it to true with a function that logs the
> change so that it's impossi
Le 30/08/2024 à 18:17, Jason A. Donenfeld a écrit :
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
@@ -14,6 +14,10 @@ ifeq ($(uname_M),x86_64)
TEST_GEN_PROGS += vdso_test_getrandom
TEST_GEN_PROGS += vdso_test_chacha
endif
+ifeq ($(ARCH),powerpc)
+TEST_GEN_PROGS += vds
config-001-20240830 gcc-12
i386 buildonly-randconfig-002-20240830 gcc-12
i386 buildonly-randconfig-003-20240830 gcc-12
i386 buildonly-randconfig-004-20240830 gcc-12
i386 buildonly-randconfig-005-20240830 gcc-12
i386 buildonly-randconfig-006-2024083
On Tue, May 14, 2024 at 02:31:09PM +0300, Ilpo Järvinen wrote:
> Add pcie_print_tlp_log() helper to print TLP Header and Prefix Log.
> Print End-End Prefixes only if they are non-zero.
>
> Consolidate the few places which currently print TLP using custom
> formatting.
>
> The first attempt used p
On Thu, Aug 29, 2024 at 06:15:27PM +0200, Maxime Chevallier wrote:
> There's no user of the struct phy_info, the 'phy' field and the
> mii_if_info in the fs_enet driver, probably dating back when phylib
> wasn't as widely used. Drop these from the driver code.
>
> Acked-by: Christophe Leroy
> Re
On Thu, Aug 29, 2024 at 06:15:27PM +0200, Maxime Chevallier wrote:
> There's no user of the struct phy_info, the 'phy' field and the
> mii_if_info in the fs_enet driver, probably dating back when phylib
> wasn't as widely used. Drop these from the driver code.
There might be an include of linux/m
> @@ -235,15 +219,15 @@ static int fs_enet_napi(struct napi_struct *napi, int
> budget)
> if (pkt_len <= fpi->rx_copybreak) {
> /* +2 to make IP header L1 cache aligned */
> skbn = netdev_alloc_skb(dev, pkt_len + 2);
On Thu, Aug 29, 2024 at 06:15:28PM +0200, Maxime Chevallier wrote:
> The PHY speed and duplex should be manipulated using the SPEED_XXX and
> DUPLEX_XXX macros available. Use it in the fcc, fec and scc MAC for fs_enet.
>
> Acked-by: Christophe Leroy
> Reviewed-by: Christophe Leroy
> Signed-off-b
On Fri, Aug 30, 2024 at 10:52:01AM +0100, Lorenzo Stoakes wrote:
> On Thu, Aug 29, 2024 at 03:16:53PM GMT, Charlie Jenkins wrote:
> > On Thu, Aug 29, 2024 at 10:54:25AM +0100, Lorenzo Stoakes wrote:
> > > On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> > > > On Thu, Aug 29, 2024 at
"Guilherme G. Piccoli" writes:
> Inspired by commit d57d6fe5bf34 ("drivers: hv: log when enabling
> crash_kexec_post_notifiers"),
> a good idea is to signal on dmesg about unconditionally enabling the kernel
> parameter crash_kexec_post_notifiers, which affects how kdump works.
>
> By checking th
> --- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> +++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> @@ -649,12 +649,7 @@ static void fs_adjust_link(struct net_device *dev)
> unsigned long flags;
>
> spin_lock_irqsave(&fep->lock, flags);
> -
> - if (fep->o
On Thu, Aug 29, 2024 at 06:15:29PM +0200, Maxime Chevallier wrote:
> devm_clock_get_enabled() can be used to simplify clock handling for the
> PER register clock.
>
> Signed-off-by: Maxime Chevallier
Reviewed-by: Andrew Lunn
Andrew
On Thu, Aug 29, 2024 at 06:15:24PM +0200, Maxime Chevallier wrote:
> The ENET driver has SPDX tags in the header files, but they were missing
> in the C files. Change the licence information to SPDX format.
>
> Acked-by: Christophe Leroy
> Reviewed-by: Christophe Leroy
> Signed-off-by: Maxime Ch
50 matches
Mail list logo
