Linus Torvalds writes:
> On Mon, Sep 13, 2021 at 7:08 PM Stephen Rothwell
> wrote:
>>
>> That patch works for me - for the ppc64_defconfig build at least.
>
> Yeah, I just tested the allmodconfig case too, although I suspect it's
> essentially the same wrt the boot *.S files, so it probably
Hi all,
On Tue, 14 Sep 2021 12:08:18 +1000 Stephen Rothwell
wrote:
>
> That patch works for me - for the ppc64_defconfig build at least.
also allnoconfig, 64bit allnoconfig, pseries_le_defconfig and ppc44x_defconfig
--
Cheers,
Stephen Rothwell
pgpJX7oVVSmfh.pgp
Description: OpenPGP digital
On Mon, Sep 13, 2021 at 7:08 PM Stephen Rothwell wrote:
>
> That patch works for me - for the ppc64_defconfig build at least.
Yeah, I just tested the allmodconfig case too, although I suspect it's
essentially the same wrt the boot *.S files, so it probably doesn't
matter.
I'd like to have
Hi Linus,
On Mon, 13 Sep 2021 18:29:26 -0700 Linus Torvalds
wrote:
>
> On Mon, Sep 13, 2021 at 5:58 PM Stephen Rothwell
> wrote:
> >
> > > I have no idea why it then complains about removal of the GCC4 macros.
> >
> > Me neither :-(
>
> Ooh.
>
> So I'm looking at gcc sources, just to see if
On Mon, Sep 13, 2021 at 6:37 PM Linus Torvalds
wrote:
>
> Anyway, that just makes me think that something like that patch in my
> previous email is the way to go, but I would like to stress (again)
> how little testing it had: exactly none.
>
> So please consider that nothing more than a
On Mon, Sep 13, 2021 at 6:29 PM Linus Torvalds
wrote:
>
> Now, do I know *why* that ppc Makefile it does that? No.
Well, that is simple enough to find out..
git show 77433830ed164
just tells us.
Of course, that also points to scripts/Makefile.lib, which doesn't
have this problem,
On Mon, Sep 13, 2021 at 5:58 PM Stephen Rothwell wrote:
>
> > I have no idea why it then complains about removal of the GCC4 macros.
>
> Me neither :-(
Ooh.
So I'm looking at gcc sources, just to see if "maybe this thing is
somehow conditional".
And bingo.
In cpp_init_special_builtins(), gcc
Hi Linus,
On Mon, 13 Sep 2021 17:24:11 -0700 Linus Torvalds
wrote:
>
> On Mon, Sep 13, 2021 at 5:19 PM Linus Torvalds
> wrote:
> >
> > What version of gcc is this? Are you maybe on gcc-4.9 and we just
> > didn't check that properly?
>
> Hmm. That version check works for me (tested by just
On Mon, Sep 13, 2021 at 5:19 PM Linus Torvalds
wrote:
>
> What version of gcc is this? Are you maybe on gcc-4.9 and we just
> didn't check that properly?
Hmm. That version check works for me (tested by just arbitrarily
making min-tool-version return version 15 for gcc ;)
So you got far enough
On Mon, Sep 13, 2021 at 5:09 PM Stephen Rothwell wrote:
>
> gcc -Wp,-MD,arch/powerpc/boot/.crt0.o.d
Ok, so it's not the funky "clang reports gcc-4" that caused tool breakage.
What version of gcc is this? Are you maybe on gcc-4.9 and we just
didn't check that properly?
Linus
Hi all,
After merging the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from :
include/linux/compiler_attributes.h:62:5: warning: "__has_attribute" is not
defined, evaluates to 0 [-Wundef]
62 | #if __has_attribute(__assume_aligned__)
On Mon, 13 Sept 2021 at 13:48, Cédric Le Goater wrote:
>
> The ICS native driver relies on the IRQ chip data to find the struct
> 'ics_native' describing the ICS controller but it was removed by commit
> 248af248a8f4 ("powerpc/xics: Rename the map handler in a check handler").
> Revert this
On Mon, Sep 13, 2021, Eduardo Habkost wrote:
> On Mon, Sep 13, 2021 at 12:24 PM Sean Christopherson
> wrote:
> >
> > On Mon, Sep 13, 2021, Juergen Gross wrote:
> > > KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> > > number of allowed vcpu-ids. This has already led to
On Mon, Sep 13, 2021 at 10:02 AM Ondrej Mosnacek wrote:
>
> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> lockdown") added an implementation of the locked_down LSM hook to
> SELinux, with the aim to restrict which domains are allowed to perform
> operations that would
On Mon, Sep 13, 2021, Juergen Gross wrote:
> KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> number of allowed vcpu-ids. This has already led to confusion, so
> rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> clear
My hesitation with this rename is
Christophe Leroy writes:
> Le 13/09/2021 à 18:21, Eric W. Biederman a écrit :
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>>> Christophe Leroy writes:
>>>
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access block.
On an mpc 8321
Revert commit 76b4f357d0e7d8f6f00 which was based on wrong reasoning
and rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS in order to avoid the
same issue in future.
Juergen Gross (2):
x86/kvm: revert commit 76b4f357d0e7d8f6f00
kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
number of allowed vcpu-ids. This has already led to confusion, so
rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
clear
Suggested-by: Eduardo Habkost
Signed-off-by: Juergen Gross
---
Hi,
I confirm that if this fix is *not* applied to current Linus
tree (c605c39677b9) and kernel boots on Microwatt (18eb029) the
kernel will crash with the following exception:
[1.846437] BUG: Kernel NULL pointer dereference on read at 0x0048
[1.853121] Faulting instruction
Le 13/09/2021 à 18:21, Eric W. Biederman a écrit :
ebied...@xmission.com (Eric W. Biederman) writes:
Christophe Leroy writes:
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access block.
On an mpc 8321 (book3s/32) the improvment is about 5% on a process
Le 13/09/2021 à 17:57, Eric W. Biederman a écrit :
Christophe Leroy writes:
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access block.
On an mpc 8321 (book3s/32) the improvment is about 5% on a process
sending a signal to itself.
Signed-off-by: Christophe
On Mon, Sep 13, 2021 at 4:04 PM Ondrej Mosnacek wrote:
>
> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> lockdown") added an implementation of the locked_down LSM hook to
> SELinux, with the aim to restrict which domains are allowed to perform
> operations that would breach
Le 13/09/2021 à 17:54, Eric W. Biederman a écrit :
Christophe Leroy writes:
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user32() in order to use it within user access blocks.
To do so, we need
ebied...@xmission.com (Eric W. Biederman) writes:
> Christophe Leroy writes:
>
>> Use unsafe_copy_siginfo_to_user() in order to do the copy
>> within the user access block.
>>
>> On an mpc 8321 (book3s/32) the improvment is about 5% on a process
>> sending a signal to itself.
If you can't make
On 9/11/21 4:35 PM, Sasha Levin wrote:
> On Fri, Sep 10, 2021 at 07:48:18AM +0200, Cédric Le Goater wrote:
>> On 9/10/21 2:14 AM, Sasha Levin wrote:
>>> From: Cédric Le Goater
>>>
>>> [ Upstream commit 1753081f2d445f9157550692fcc4221cd3ff0958 ]
>>>
>>> PCI MSIs now live in an MSI domain but the
Christophe Leroy writes:
> Use unsafe_copy_siginfo_to_user() in order to do the copy
> within the user access block.
>
> On an mpc 8321 (book3s/32) the improvment is about 5% on a process
> sending a signal to itself.
>
> Signed-off-by: Christophe Leroy
> ---
> v3: Don't leave compat aside, use
Christophe Leroy writes:
> In the same spirit as commit fb05121fd6a2 ("signal: Add
> unsafe_get_compat_sigset()"), implement an 'unsafe' version of
> copy_siginfo_to_user32() in order to use it within user access blocks.
>
> To do so, we need inline version of copy_siginfo_to_external32() as we
The general convention for pcibios_* hooks is that they're named after
the corresponding pci_* function they provide a hook for. The exception
is pcibios_add_device() which provides a hook for pci_device_add(). This
has been irritating me for years so rename it.
Also, remove the export of the
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user32() in order to use it within user access blocks.
To do so, we need inline version of copy_siginfo_to_external32() as we
don't want any function call inside
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access block.
On an mpc 8321 (book3s/32) the improvment is about 5% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy
---
v3: Don't leave compat aside, use the new unsafe_copy_siginfo_to_user32()
Include the new stack frame inside the user access block and set it up
using unsafe_put_user().
On an mpc 8321 (book3s/32) the improvment is about 4% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/signal_32.c | 29 +
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user() in order to use it within user access blocks.
For that, also add an 'unsafe' version of clear_user().
This commit adds the generic fallback for
Access the function descriptor of the handler within a
user access block.
Signed-off-by: Christophe Leroy
---
Resending with correct date, sorry for the noise, my new PC seems to have used
the fake date from Git instead of adding proper Date: from current date/time.
v3: Flatten the change to
Implement unsafe_clear_user() for powerpc.
It's a copy/paste of unsafe_copy_to_user() with value 0 as source.
It may be improved in a later patch by using 'dcbz' instruction
to zeroize full cache lines at once.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/uaccess.h | 20
Commit 8e11d62e2e87 ("powerpc/mem: Add back missing header to fix 'no
previous prototype' error") was supposed to fix the problem, but in
the meantime commit a927bd6ba952 ("mm: fix phys_to_target_node() and*
memory_add_physaddr_to_nid() exports") moved create_section_mapping()
prototype from
On Sat, Sep 11, 2021 at 9:09 PM Michael Ellerman wrote:
>
> Niklas Schnelle writes:
> > On powerpc, pci_dev_is_added() is called as part of SR-IOV fixups
> > that are done under pcibios_add_device() which in turn is only called in
> > pci_device_add() whih is called when a PCI device is scanned.
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
lockdown") added an implementation of the locked_down LSM hook to
SELinux, with the aim to restrict which domains are allowed to perform
operations that would breach lockdown.
However, in several places the security_locked_down()
The ICS native driver relies on the IRQ chip data to find the struct
'ics_native' describing the ICS controller but it was removed by commit
248af248a8f4 ("powerpc/xics: Rename the map handler in a check handler").
Revert this change to fix the Microwatt SoC platform.
Fixes: 248af248a8f4
Le 02/09/2021 à 08:54, Christoph Hellwig a écrit :
On Mon, Aug 23, 2021 at 03:35:53PM +, Christophe Leroy wrote:
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user() in order to use it within user
Scheduler expects the number of unique node distances to be available
at boot. It iterates over all pairs of nodes and records
node_distance() for that pair, and then calculates the set of unique
distances. As per PAPR, node distances for offline nodes is not
available. However, PAPR already
Le 11/09/2021 à 17:58, Eric W. Biederman a écrit :
Christophe Leroy writes:
On 9/8/21 6:17 PM, Eric W. Biederman wrote:
Christophe Leroy writes:
Le 02/09/2021 à 20:43, Eric W. Biederman a écrit :
Christophe Leroy writes:
In the same spirit as commit fb05121fd6a2 ("signal: Add
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access block.
On an mpc 8321 (book3s/32) the improvment is about 5% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy
---
v3: Don't leave compat aside, use the new unsafe_copy_siginfo_to_user32()
Implement unsafe_clear_user() for powerpc.
It's a copy/paste of unsafe_copy_to_user() with value 0 as source.
It may be improved in a later patch by using 'dcbz' instruction
to zeroize full cache lines at once.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/uaccess.h | 20
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user32() in order to use it within user access blocks.
To do so, we need inline version of copy_siginfo_to_external32() as we
don't want any function call inside
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user() in order to use it within user access blocks.
For that, also add an 'unsafe' version of clear_user().
This commit adds the generic fallback for
Include the new stack frame inside the user access block and set it up
using unsafe_put_user().
On an mpc 8321 (book3s/32) the improvment is about 4% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/signal_32.c | 29 +
Access the function descriptor of the handler within a
user access block.
Signed-off-by: Christophe Leroy
---
v3: Flatten the change to avoid nested gotos.
---
arch/powerpc/kernel/signal_64.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git
Dear Linux folks,
Building Linux with LLVM’s integrated assembler fails with the error
below [1].
```
$ ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- make LLVM=1
LLVM_IAS=1 -j72 pseries_defconfig arch/powerpc/kernel/vdso32/gettimeofday.o
...
https://bugzilla.kernel.org/show_bug.cgi?id=206669
--- Comment #16 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de)
---
Hi Michael!
Thanks a lot for looking into this!
If you have installed a Debian unstable big-endian system, the easiest way to
get such a setup by creating an
https://bugzilla.kernel.org/show_bug.cgi?id=206669
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |NEEDINFO
Please kindly note that this is a powerpc32 build.
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.14 next-20210903]
[cannot apply to powerpc/next scottwood/next]
[If your patch is applied to the wrong git tree,
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
CC|
While debugging an issue, we wanted to check whether the arch specific
kernel memmove implementation is correct.
This selftest could help test that.
Suggested-by: Aneesh Kumar K.V
Suggested-by: Vaibhav Jain
Signed-off-by: Ritesh Harjani
---
v1 -> v2: Integrated memmove_64 test within copyloops
54 matches
Mail list logo
