On Thu, Feb 17, 2022 at 8:20 AM Christophe Leroy
wrote:
> Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> >
> > Christoph Hellwig and a few others spent a huge effort on removing
> > set_fs() from most of the important architectures, but about half the
> > other architectures were never
Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
>
On Thu, 17 Feb 2022 at 01:07, Michael Ellerman wrote:
>
> Michal Suchánek writes:
> > On Mon, Feb 14, 2022 at 01:33:24PM +0100, Paul Menzel wrote:
> >> Yes, simple `nproc` suffice, but I was more thinking about, that the Linux
> >> log is often used for debugging and the changes of amount of
x86 added a control for turning SMT on and off in commit 05736e4ac13c
("cpu/hotplug: Provide knobs to control SMT").
Implement this for powerpc as an alternative to the currently method of
iterating through /sys/devices/system/cpu/cpuN/online for every CPU.
# ppc64_cpu --info
Core 0:0*
powerpc mpc834x_itx_defconfig
arm randconfig-c002-20220216
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68k
sh7785lcr_32bit_defconfig
powerpc mpc834x_itx_defconfig
arm randconfig-c002-20220216
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
Michal Suchánek writes:
> On Mon, Feb 14, 2022 at 01:33:24PM +0100, Paul Menzel wrote:
>> Am 14.02.22 um 10:43 schrieb Michal Suchánek:
>> > On Mon, Feb 14, 2022 at 07:08:07AM +0100, Paul Menzel wrote:
>> > > On the POWER8 server IBM S822LC running `ppc64_cpu --smt=off` or
>> > > `ppc64_cpu
>> >
On Wed, Feb 16, 2022 at 7:44 PM Sam Ravnborg wrote:
>
> Hi Arnd,
>
> Fix spelling in $subject...
done
> sparc/Kconfig b/arch/sparc/Kconfig
> > index 9f6f9bce5292..9276f321b3e3 100644
> > --- a/arch/sparc/Kconfig
> > +++ b/arch/sparc/Kconfig
> > @@ -46,7 +46,6 @@ config SPARC
> > select
On Wed, Feb 16, 2022 at 7:41 PM Sam Ravnborg wrote:
> On Wed, Feb 16, 2022 at 07:34:59PM +0100, Sam Ravnborg wrote:
> >
> > I think you somehow missed the Kconfig change, and also the related
> > sparc32 change which continue to have set_fs() after this patch.
Right, thanks for pointing out the
[adding fsdevel to this party, since iomap is core code, not just XFS...]
On Wed, Feb 16, 2022 at 12:55:02PM +0530, Sachin Sant wrote:
> While running xfstests on IBM Power10 logical partition (LPAR) booted
> with 5.17.0-rc4-next-20220215 following warning was seen:
>
> [ 2547.384210] xfs
Hi Arnd.
On Wed, Feb 16, 2022 at 02:13:29PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> sparc64 uses address space identifiers to differentiate between kernel
> and user space, using ASI_P for kernel threads but ASI_AIUS for normal
> user space, with the option of changing between
Le 15/02/2022 à 10:12, Arnd Bergmann a écrit :
> On Tue, Feb 15, 2022 at 9:17 AM Ard Biesheuvel wrote:
>> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann wrote:
>>> From: Arnd Bergmann
>>>
>>
>> With set_fs() out of the picture, wouldn't it be sufficient to check
>> that bit #55 is clear? (the
Hi Arnd,
Fix spelling in $subject...
sparc/Kconfig b/arch/sparc/Kconfig
> index 9f6f9bce5292..9276f321b3e3 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -46,7 +46,6 @@ config SPARC
> select LOCKDEP_SMALL if LOCKDEP
> select NEED_DMA_MAP_STATE
> select
Hi Arnd,
On Wed, Feb 16, 2022 at 07:34:59PM +0100, Sam Ravnborg wrote:
> Hi Arnd.
>
> On Wed, Feb 16, 2022 at 02:13:29PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > sparc64 uses address space identifiers to differentiate between kernel
> > and user space, using ASI_P for kernel
On Wed, Feb 16, 2022 at 09:35:04AM -0800, Darrick J. Wong wrote:
> On Wed, Feb 16, 2022 at 12:55:02PM +0530, Sachin Sant wrote:
> > [ 2547.662818] [ cut here ]
> > [ 2547.662832] WARNING: CPU: 24 PID: 2463718 at fs/iomap/buffered-io.c:75
> > iomap_page_release+0x1b0/0x1e0
On Wed, 16 Feb 2022 11:15:17 +0800
Chao Gao wrote:
> This partially reverts commit b99040853738 ("KVM: Pass kvm_init()'s opaque
> param to additional arch funcs") remove opaque from
> kvm_arch_check_processor_compat because no one uses this opaque now.
> Address conflicts for ARM (due to file
On Wed, Feb 16, 2022 at 11:22:33PM +1100, Michael Ellerman wrote:
> Kees Cook writes:
> > On Tue, Feb 15, 2022 at 01:40:55PM +0100, Christophe Leroy wrote:
> >> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
> >> on those three architectures because LKDTM messes up function
> >>
From: Arnd Bergmann
> Sent: 16 February 2022 13:13
>
> These two architectures implement 8-byte get_user() through
> a memcpy() into a four-byte variable, which won't fit.
>
> Use a temporary 64-bit variable instead here, and use a double
> cast the way that risc-v and openrisc do to avoid
On 2/15/22 17:07, Kees Cook wrote:
> On Tue, Feb 15, 2022 at 01:40:55PM +0100, Christophe Leroy wrote:
>> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
>> on those three architectures because LKDTM messes up function
>> descriptors with functions.
>>
>> This series does some
Heiko Carstens writes:
> So, the in both variants s390 provides nearly identical data. The only
> difference is that for FL_SAVE_REGS the program status word mask is
> missing; therefore it is not possible to figure out the condition code
> or if interrupts were enabled/disabled.
>
> Vasily,
From: Arnd Bergmann
There are no remaining callers of set_fs(), so CONFIG_SET_FS
can be removed globally, along with the thread_info field and
any references to it.
This turns access_ok() into a cheaper check against TASK_SIZE_MAX.
With CONFIG_SET_FS gone, so drop all remaining references to
From: Arnd Bergmann
ia64 only uses set_fs() in one file to handle unaligned access for
both user space and kernel instructions. Rewrite this to explicitly
pass around a flag about which one it is and drop the feature from
the architecture.
Signed-off-by: Arnd Bergmann
---
arch/ia64/Kconfig
From: Arnd Bergmann
sh uses set_fs/get_fs only in one file, to handle address
errors in both user and kernel memory.
It already has an abstraction to differentiate between I/O
and memory, so adding a third class for kernel memory fits
into the same scheme and lets us kill off CONFIG_SET_FS.
From: Arnd Bergmann
sparc64 uses address space identifiers to differentiate between kernel
and user space, using ASI_P for kernel threads but ASI_AIUS for normal
user space, with the option of changing between them.
As nothing really changes the ASI any more, just hardcode ASI_AIUS
everywhere.
From: Arnd Bergmann
test_kernel_ptr() uses access_ok() to figure out if a given address
points to user space instead of kernel space. However on architectures
that set CONFIG_ALTERNATE_USER_ADDRESS_SPACE, a pointer can be valid
for both, and the check always fails because access_ok() returns
From: Arnd Bergmann
There are many different ways that access_ok() is defined across
architectures, but in the end, they all just compare against the
user_addr_max() value or they accept anything.
Provide one definition that works for most architectures, checking
against TASK_SIZE_MAX for user
From: Arnd Bergmann
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that I found either through my own test builds or
that were
From: Arnd Bergmann
arm64 has an inline asm implementation of access_ok() that is derived from
the 32-bit arm version and optimized for the case that both the limit and
the size are variable. With set_fs() gone, the limit is always constant,
and the size usually is as well, so just using the
From: Arnd Bergmann
While most m68k platforms use separate address spaces for user
and kernel space, at least coldfire does not, and the other
ones have a TASK_SIZE that is less than the entire 4GB address
range.
Using the default implementation of __access_ok() stops coldfire
user space from
From: Arnd Bergmann
Before unifying the mips version of __access_ok() with the generic
code, this converts it to the same algorithm. This is a change in
behavior on mips64, as now address in the user segment, the lower
2^62 bytes, is taken to be valid, relying on a page fault for
addresses that
From: Arnd Bergmann
Nine architectures are still missing __{get,put}_kernel_nofault:
alpha, ia64, microblaze, nds32, nios2, openrisc, sh, sparc32, xtensa.
Add a generic version that lets everything use the normal
copy_{from,to}_kernel_nofault() code based on these, removing the last
use of
From: Arnd Bergmann
Unlike other architectures, the nios2 version of __put_user() has an
extra check for access_ok(), preventing it from being used to implement
__put_kernel_nofault().
Split up put_user() along the same lines as __get_user()/get_user()
Signed-off-by: Arnd Bergmann
---
From: Arnd Bergmann
The way that access_ok() is defined on x86 is slightly different from
most other architectures, and a bit more complex.
The generic version tends to result in the best output on all
architectures, as it results in single comparison against a constant
limit for calls with a
From: Arnd Bergmann
The __range_not_ok() helper is an x86 (and sparc64) specific interface
that does roughly the same thing as __access_ok(), but with different
calling conventions.
Change this to use the normal interface in order for consistency as we
clean up all access_ok() implementations.
From: Arnd Bergmann
sparc64 is one of the architectures that uses separate address
spaces for kernel and user addresses, so __get_kernel_nofault()
can not just call into the normal __get_user() without the
access_ok() check.
Instead duplicate __get_user() and __put_user() into their
in-kernel
From: Arnd Bergmann
The get_user()/put_user() functions are meant to check for
access_ok(), while the __get_user()/__put_user() functions
don't.
This broke in 4.19 for nds32, when it gained an extraneous
check in __get_user(), but lost the check it needs in
__put_user().
Fixes: 487913ab18c2
From: Arnd Bergmann
These two architectures implement 8-byte get_user() through
a memcpy() into a four-byte variable, which won't fit.
Use a temporary 64-bit variable instead here, and use a double
cast the way that risc-v and openrisc do to avoid compile-time
warnings.
Fixes: 6a090e97972d
From: Arnd Bergmann
Three architectures check the end of a user access against the
address limit without taking a possible overflow into account.
Passing a negative length or another overflow in here returns
success when it should not.
Use the most common correct implementation here, which
From: Arnd Bergmann
Christoph Hellwig and a few others spent a huge effort on removing
set_fs() from most of the important architectures, but about half the
other architectures were never completed even though most of them don't
actually use set_fs() at all.
I did a patch for microblaze at some
On Sat, 12 Feb 2022 22:13:49 +1100, Michael Ellerman wrote:
> Our skiroot_defconfig doesn't enable FTRACE, and so doesn't get
> STACKTRACE enabled either. That leads to a build failure since commit
> 1614b2b11fab ("arch: Make ARCH_STACKWALK independent of STACKTRACE")
> made stacktrace.c build
On Tue, 25 Jan 2022 00:05:44 +1100, Michael Ellerman wrote:
> Mahesh & Sourabh identified two problems[1][2] with ppc64_bolted_size()
> and paca allocation.
>
> The first is that on a Radix capable machine but with "disable_radix" on
> the command line, there is a window during early boot where
>
On Tue, Feb 15, 2022 at 1:48 AM Al Viro wrote:
>
> On Mon, Feb 14, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote:
>
> > -/*
> > - * Sparc64 is segmented, though more like the M68K than the I386.
> > - * We use the secondary ASI to address user memory, which references a
> > - * completely
On Mon, Feb 14, 2022 at 6:06 PM Christoph Hellwig wrote:
>
> > void prom_world(int enter)
> > {
> > - if (!enter)
> > - set_fs(get_fs());
> > -
> > __asm__ __volatile__("flushw");
> > }
>
> The enter argument is now unused.
Right, good point. I'll add a comment, but I
On Tue, Feb 15, 2022 at 09:55:52PM +0530, Naveen N. Rao wrote:
> > > > > > > I think this is wrong. We need to differentiate
> > > > > > > between ftrace_caller() and ftrace_regs_caller()
> > > > > > > here, and only return pt_regs if coming in through
> > > > > > > ftrace_regs_caller() (i.e.,
On Tue, 25 Jan 2022 18:56:50 -0300, Fabiano Rosas wrote:
> Changes from v4:
>
> -patch 4: switched to kvm_debug_ratelimited.
>
> -patch 5: kept the Program interrupt for BookE.
>
> v4:
> https://lore.kernel.org/r/20220121222626.972495-1-faro...@linux.ibm.com
>
> [...]
Applied to
On Fri, 4 Feb 2022 14:26:01 +0530, Sourabh Jain wrote:
> On large config LPARs (having 192 and more cores), Linux fails to boot
> due to insufficient memory in the first memblock. It is due to the
> memory reservation for the crash kernel which starts at 128MB offset of
> the first memblock. This
On Mon, 13 Sep 2021 11:47:20 +0530, Ritesh Harjani wrote:
> While debugging an issue, we wanted to check whether the arch specific
> kernel memmove implementation is correct.
> This selftest could help test that.
>
>
Applied to powerpc/next.
[1/1] selftests/powerpc/copyloops: Add memmove_64
On Mon, 7 Feb 2022 16:12:47 -0600, Nathan Lynch wrote:
> pseries_devicetree_update() has only one call site, in the same file in
> which it is defined. Make it static.
>
>
Applied to powerpc/next.
[1/1] powerpc/pseries: make pseries_devicetree_update() static
On Fri, 3 Sep 2021 11:18:34 + (UTC), Christophe Leroy wrote:
> The purpose of this series is to convert machine dependent
> functions in structure ppc_md into static calls.
>
> First part of the series remove some dust in and around machdep.h
>
> Then some helpers are defined to abstract the
On Fri, 21 Jan 2022 16:30:21 +, Christophe Leroy wrote:
> VDSO64 cacheflush.S datapage.S gettimeofday.S and vgettimeofday.c
> are very similar to their VDSO32 counterpart.
>
> VDSO32 counterpart is already more complete than the VDSO64 version
> as it supports both PPC32 vdso and 32 bits VDSO
On Fri, 24 Dec 2021 11:07:33 +, Christophe Leroy wrote:
> Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
> included a spin_lock() to change_page_attr() in order to
> safely perform the three step operations. But then
> commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*()
On Mon, 20 Dec 2021 16:37:58 +, Christophe Leroy wrote:
> This series implements livepatch on PPC32 and implements
> CONFIG_DYNAMIC_FTRACE_WITH_ARGS to simplify ftracing.
>
> v2:
> - Fix problem with strict modules RWX
> - Convert powerpc to CONFIG_DYNAMIC_FTRACE_WITH_ARGS
> - Convert
On Fri, 21 Jan 2022 07:58:47 +, Christophe Leroy wrote:
> Two places deserve using the macro is_tsk_32bit_task() added by
> commit 252745240ba0 ("powerpc/audit: Fix syscall_get_arch()")
>
>
Applied to powerpc/next.
[1/1] powerpc: Use the newly added is_tsk_32bit_task() macro
On Mon, 10 Jan 2022 12:29:42 +, Christophe Leroy wrote:
> BPF_REG_5, BPF_REG_AX and TMP_REG are mapped on non volatile registers
> because there are not enough volatile registers, but they don't need
> to be preserved on function calls.
>
> So when some volatile registers become available,
On Mon, 17 Jan 2022 10:06:39 +, Christophe Leroy wrote:
> The book3s/32 MMU doesn't support per page execution protection and
> doesn't support RO protection for kernel pages.
>
> However, on the 603 which implements software loaded TLBs, execution
> protection is honored by the TLB Miss
On Fri, 21 Jan 2022 08:06:27 +, Christophe Leroy wrote:
> Don't opencode dcache size retrieval based on whether that's ppc32 or ppc64.
>
> Use l1_dcache_bytes()
>
>
Applied to powerpc/next.
[1/3] powerpc/lib/sstep: Use l1_dcache_bytes() instead of opencoding
On Tue, 30 Nov 2021 13:04:49 +0100, Christophe Leroy wrote:
> STABS debug format has been superseded long time ago by DWARF.
>
> Remove the few remaining .stabs annotations from old 32 bits code.
>
>
Applied to powerpc/next.
[1/2] powerpc/32: Remove remaining .stabs annotations
On Fri, 11 Feb 2022 12:22:15 +0530, Aneesh Kumar K.V wrote:
> commit: d9c234005227 ("Do not depend on MAX_ORDER when grouping pages by
> mobility")
> introduced pageblock_order which will be used to group pages better.
> The kernel now groups pages based on the value of HPAGE_SHIFT. Hence
>
Hi!
On 2/15/22 13:40, Christophe Leroy wrote:
> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
> on those three architectures because LKDTM messes up function
> descriptors with functions.
>
> This series does some cleanup in the three architectures and
> refactors function
Kees Cook writes:
> On Tue, Feb 15, 2022 at 01:40:55PM +0100, Christophe Leroy wrote:
>> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
>> on those three architectures because LKDTM messes up function
>> descriptors with functions.
>>
>> This series does some cleanup in the
Hi Sachin,
On Wed, 16 Feb 2022 15:17:14 +0530 Sachin Sant wrote:
>
> >> While running xfstests on IBM Power10 logical partition (LPAR) booted
> >> with 5.17.0-rc4-next-20220215 following warning was seen:
> >>
> >> The warning is seen when test tries to unmount the file system. This
> >>
Christophe Leroy wrote:
Add some line breaks to better match the file's style, add
some space after comma and fix a couple of misplaced blanks.
Suggested-by: Naveen N. Rao
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace_mprofile.S | 12
1 file changed, 8
Hi,
side notes about the subject (following private notes from Nicolai):
I dared to use "crypto: vmx: " in subject, next version I'll use "crypto: vmx -
"
as it's used in crypto.
Also continue the subject line into the rest of the commit message isn't
probably wanted.
Kind regards,
Petr
Hi Nicolai,
thanks for all your comments.
> Hi Petr,
> Petr Vorel writes:
> > and remove CRYPTO_DEV_VMX, which looked redundant when only
> > CRYPTO_DEV_VMX_ENCRYPT used it. Also it forces CRYPTO_GHASH to be
> > builtin even CRYPTO_DEV_VMX_ENCRYPT was configured as module.
> I'm confused by
>> While running xfstests on IBM Power10 logical partition (LPAR) booted
>> with 5.17.0-rc4-next-20220215 following warning was seen:
>>
>> The warning is seen when test tries to unmount the file system. This problem
>> is seen
>> while running generic/475 sub test. Have attached captured
Hi Petr,
Petr Vorel writes:
> and remove CRYPTO_DEV_VMX, which looked redundant when only
> CRYPTO_DEV_VMX_ENCRYPT used it. Also it forces CRYPTO_GHASH to be
> builtin even CRYPTO_DEV_VMX_ENCRYPT was configured as module.
I'm confused by the description. CRYPTO_DEV_VMX_ENCRYPT has been a
66 matches
Mail list logo
