David Howells wrote:
>
> Hillf Danton wrote:
>
> > - struct request_key_auth *rka = dereference_key_rcu(key);
> > + struct request_key_auth *rka;
> > +
> > + rcu_read_lock();
> > + rka = dereference_key_rcu(key);
>
> This shouldn't help as the caller, proc_keys_show(), is holding the RCU
David Howells wrote:
>> 1, callee has no pre defined duty to help caller in general; they should not
>> try to do anything, however, to help their callers in principle due to
>> limited info on their hands IMO.
>
> Ah, no. It's entirely reasonable for an API to specify that one of its
> methods w
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the
setting of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in th
On Fri, Aug 30, 2019 at 09:54:43PM +0200, Arnd Bergmann wrote:
> > -#if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT)
> > +#ifdef __ARCH_WANT_SYS_LLSEEK
> > SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned long, offset_high,
> > unsigned long, offset_low, loff_t __user *, resu
On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
> of proximity domain is optional, as below:
>
> This optional object is used to describe proximity domain
> associations within a machine. _PXM evaluates to an integer
>
On 2019/8/31 14:53, David Miller wrote:
> From: Yunsheng Lin
> Date: Sat, 31 Aug 2019 13:58:21 +0800
>
>> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
>> of proximity domain is optional, as below:
>
> What in the world does the ACPI spec have to do with sparc64 NUMA
> node ID
On 2019/8/31 16:55, Peter Zijlstra wrote:
> On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
>> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
>> of proximity domain is optional, as below:
>>
>> This optional object is used to describe proximity domain
>> associatio
The purpose of this serie is to enable CONFIG_VMAP_STACK on PPC32.
For the time being we have something working on 8xx.
Further work I'm working on:
- Fix stack overflow detection (doesn't work all the time yet, with the LKDTM
STACK_EXHAUST test it hang).
- Add support to powerpc 603
- Add suppo
To support CONFIG_VMAP_STACK, the kernel has to activate Data MMU
Translation for accessing the stack. Before doing that it must save
SRR0, SRR1 and DAR in order to not loose them in case there is a
Data TLB Miss once the translation is reactivated.
This patch defines fields in the thread struct f
On PPC32, MTMSRD() is simply defined as mtmsr.
Replace MTMSRD(reg) by mtmsr reg in files dedicated to PPC32,
this makes the code less obscure.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/entry_32.S | 18 +-
arch/powerpc/kernel/head_32.h | 4 ++--
2 files changed, 1
This patch creates a macro for the very first part of
exception prolog, this will help when implementing
CONFIG_VMAP_STACK
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_32.S | 4 +---
arch/powerpc/kernel/head_32.h | 9 ++---
arch/powerpc/kernel/head_8xx.S | 9 ++---
3 fi
In preparation of handling CONFIG_VMAP_STACK, we need DTLB miss handler
to use different scratch registers than other exception handlers in
order to not jeopardise exception entry on stack DTLB misses.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_8xx.S | 28 +++---
Breakpoint exception is big.
Split it to support future growth on exception prolog.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_8xx.S | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/he
Move DataStoreTLBMiss perf handler in order to cope
with future growing exception prolog.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_8xx.S | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerp
head_8xx.S has entries for all exceptions from 0x100 to 0x1f00.
Several of them do not exist and are never generated by the 8xx
in accordance with the documentation.
Remove those entry points to make some room for future growing
exception code.
Signed-off-by: Christophe Leroy
---
arch/powerpc/k
This patch enables CONFIG_VMAP_STACK. For that, a few changes are
done in head_8xx.S.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/head_8xx.S | 47 +-
2 files changed, 47 insertions(+), 1 deletion(-)
diff
In order to ease stack overflow detection, align
stack to 2 * THREAD_SIZE when using VMAP_STACK.
This allow overflow detection using a single bit check.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/thread_info.h | 13 +
arch/powerpc/kernel/setup_32.c | 2 +-
To avoid recursive faults, stack overflow detection has to be
performed before writing in the stack in exception prologs.
Do it by checking the alignment. If the stack pointer alignment is
wrong, it means it is pointing to the following or preceding page.
Signed-off-by: Christophe Leroy
---
arc
On Fri, 30 Aug 2019 23:03:41 +0200
Michal Suchanek wrote:
> There are numerous references to 32bit functions in generic and 64bit
> code so ifdef them out.
>
> Signed-off-by: Michal Suchanek
> ---
> v2:
> - fix 32bit ifdef condition in signal.c
> - simplify the compat ifdef condition in vdso.c
On Sat, Aug 31, 2019 at 10:39 AM Christoph Hellwig wrote:
>
> On Fri, Aug 30, 2019 at 09:54:43PM +0200, Arnd Bergmann wrote:
> > > -#if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT)
> > > +#ifdef __ARCH_WANT_SYS_LLSEEK
> > > SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned long, offset_high,
Hi Yunsheng,
On Sat, Aug 31, 2019 at 01:58:22PM +0800, Yunsheng Lin wrote:
> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
> of proximity domain is optional, as below:
>
> This optional object is used to describe proximity domain
> associations within a machine. _PXM evaluates t
On Sat, Aug 31, 2019 at 06:09:39PM +0800, Yunsheng Lin wrote:
>
>
> On 2019/8/31 16:55, Peter Zijlstra wrote:
> > On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
> >> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
> >> of proximity domain is optional, as below:
> >>
On Sat, 31 Aug 2019 08:41:58 +0200
Christophe Leroy wrote:
> Le 30/08/2019 à 23:03, Michal Suchanek a écrit :
> > Less code means less bugs so add a knob to skip the compat stuff.
>
> I guess on PPC64 you have Gigabytes of memory and thousands of bogomips,
> hence you focus on bugs.
>
> My m
On Fri, 30 Aug 2019 23:03:43 +0200
Michal Suchanek wrote:
> Building callchain.c with !COMPAT proved quite ugly with all the
> defines. Splitting out the 32bit and 64bit parts looks better.
>
> No code change intended.
valid_user_sp is broken in compat. It needs to be ifdefed for the 32bit
case
From: Yunsheng Lin
Date: Sat, 31 Aug 2019 16:57:04 +0800
> Did you mean sparc64 system does not has ACPI, the device's node id will
> not specified by ACPI, so the ACPI is unrelated here?
Yes, sparc64 never has and never will have ACPI.
This is also true for several other platforms where you ha
34 matches
Mail list logo
