On Thu, Jan 24, 2019 at 04:58:41PM +0100, Christophe Leroy wrote:
>
>
> Le 24/01/2019 à 16:01, Christophe Leroy a écrit :
> >
> >
> > Le 24/01/2019 à 10:43, Christophe Leroy a écrit :
> > >
> > >
> > > On 01/24/2019 01:06 AM, Michael Ellerman wrote:
> > > > Christophe Leroy writes:
> > > > >
Le 25/01/2019 à 01:55, Benjamin Herrenschmidt a écrit :
On Thu, 2019-01-24 at 19:48 +0530, Chandan Rajendra wrote:
- Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned
value and hence ends up accessing the "next" double word. The "next" double
word happens to occ
Hi Vinod,
Sorry to replay late.
1:This patch has already send to the patchwork.
Please see the patch link: https://patchwork.kernel.org/patch/10741521/
2:I have already compile the fsl patches on arm and powerpc after patched
https://patchwork.kernel.org/patch/10741521/
The compil
This patch forces shutdown of CAPP when CXL module is unloaded. This
is accomplished via a call to pnv_phb_to_cxl_mode() with mode ==
OPAL_PHB_CAPI_MODE_PCIE.
Signed-off-by: Vaibhav Jain
---
drivers/misc/cxl/cxl.h | 1 +
drivers/misc/cxl/main.c | 3 +++
drivers/misc/cxl/pci.c | 25 ++
Recent updates to OPAL [1] have provided support for new CXL modes on
PHB that need to force a cold reset on the bridge (CRESET). However
PHB CRESET is a multi step process and cannot be completed
synchronously as expected by current kernel implementation that issues
opal call opal_pci_set_phb_cxl_
Recent updates to OPAL have implemented necessary infrastructure [1] to disable
CAPP and switch PHB back to PCIE mode during fast reset. This small patch-set
uses the same OPAL infrastructure to force disable of CAPP when CXL module is
unloaded via rmmod.
References:
[1]: https://lists.ozlabs.org/
Within cxl module, iteration over array 'adapter->slices' may be racy
at few points as it might be simultaneously read during an EEH and its
contents being set to NULL while driver is being unloaded or unbound
from the adapter. This might result in a NULL pointer to 'struct afu'
being de-referenced
On Thu, 2019-01-24 at 19:48 +0530, Chandan Rajendra wrote:
> - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned
> value and hence ends up accessing the "next" double word. The "next" double
> word happens to occur after the last page mapped into the kernel's address
>
On 01/14/2019 04:28 PM, Bjorn Helgaas wrote:
> On Fri, Dec 14, 2018 at 02:51:31PM -0600, Michael Bringmann wrote:
>> The implementation of the pseries-specific drc info properties
>> is currently implemented in pseries-specific and non-pseries-specific
>> files. This patch set uses a new implement
On 12/14/2018 12:50 PM, Michael Bringmann wrote:
> Define interface to acquire arch-specific drc info to match against
> hotpluggable devices. The current implementation exposes several
> pseries-specific dynamic memory properties in generic kernel code.
> This patch set provides an interface to p
On 12/14/2018 12:51 PM, Michael Bringmann wrote:
> This patch provides a common interface to parse ibm,drc-indexes,
> ibm,drc-names, ibm,drc-types, ibm,drc-power-domains, or ibm,drc-info.
> The generic interface arch_find_drc_match is provided which accepts
> callback functions that may be applied
On 12/14/2018 12:50 PM, Michael Bringmann wrote:
> Define interface to acquire arch-specific drc info to match against
> hotpluggable devices. The current implementation exposes several
> pseries-specific dynamic memory properties in generic kernel code.
> This patch set provides an interface to p
When executing fstests' generic/026 test, I hit the following call trace,
[ 417.061038] BUG: Unable to handle kernel data access at 0xc0062ac4
[ 417.062172] Faulting instruction address: 0xc0092240
[ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1]
[ 417.062299] LE SMP
On 1/24/19 6:17 AM, Michal Hocko wrote:
> and nr_cpus set to 4. The underlying reason is tha the device is bound
> to node 2 which doesn't have any memory and init_cpu_to_node only
> initializes memory-less nodes for possible cpus which nr_cpus restrics.
> This in turn means that proper zonelists a
On Thu, Jan 24, 2019 at 03:17:27PM +0100, Michal Hocko wrote:
> a friendly ping for this. Does anybody see any problem with this
> approach?
FWIW, it looks fine to me.
It'd just be nice to have a few more words in the changelog about *how* the
x86 init was reworked ;-)
> On Mon 14-01-19 09:24:1
On 1/23/19 9:40 PM, Michael Ellerman wrote:
> On Tue, 2019-01-08 at 21:00:10 UTC, "Gustavo A. R. Silva" wrote:
>> One of the more common cases of allocation size calculations is finding the
>> size of a structure that has a zero-sized array at the end, along with memory
>> for some number of ele
On 1/24/19 8:01 AM, Breno Leitao wrote:
> 'regno' is directly controlled by user space, hence leading to a potential
> exploitation of the Spectre variant 1 vulnerability.
>
> On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
> register number that would be read or written. T
On Thu, Jan 24, 2019 at 07:25:53PM +0200, Mike Rapoport wrote:
> On Thu, Jan 24, 2019 at 04:51:53PM +, Mark Rutland wrote:
> > On Thu, Jan 24, 2019 at 04:19:33PM +, Christophe Leroy wrote:
> > > Since only the virtual address of allocated blocks is used,
> > > lets use functions returning d
On Thu, Jan 24, 2019 at 04:51:53PM +, Mark Rutland wrote:
> On Thu, Jan 24, 2019 at 04:19:33PM +, Christophe Leroy wrote:
> > Since only the virtual address of allocated blocks is used,
> > lets use functions returning directly virtual address.
> >
> > Those functions have the advantage of
On Thu, Jan 24, 2019 at 04:19:43PM +, Christophe Leroy wrote:
> This patch activates CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
>
> Moving thread_info into task_struct has the following advantages:
> - It protects thread_info from corruption in the case of stack
On Thu, Jan 24, 2019 at 04:19:39PM +, Christophe Leroy wrote:
> [text copied from commit 9bbd4c56b0b6
> ("arm64: prep stack walkers for THREAD_INFO_IN_TASK")]
>
> When CONFIG_THREAD_INFO_IN_TASK is selected, task stacks may be freed
> before a task is destroyed. To account for this, the stacks
On Thu, Jan 24, 2019 at 04:19:33PM +, Christophe Leroy wrote:
> Since only the virtual address of allocated blocks is used,
> lets use functions returning directly virtual address.
>
> Those functions have the advantage of also zeroing the block.
>
> Suggested-by: Mike Rapoport
> Acked-by: M
Since only the virtual address of allocated blocks is used,
lets use functions returning directly virtual address.
Those functions have the advantage of also zeroing the block.
Suggested-by: Mike Rapoport
Acked-by: Mike Rapoport
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c
Now that current_thread_info is located at the beginning of 'current'
task struct, CURRENT_THREAD_INFO macro is not really needed any more.
This patch replaces it by loads of the value at PACACURRENT(r13).
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/exception-64s.h | 4 +
This patch activates CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following advantages:
- It protects thread_info from corruption in the case of stack
overflows.
- Its address is harder to determine if stack addresses are
leak
When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h
includes asm/current.h. This generates a circular dependency.
To avoid that, asm/processor.h shall not be included in mmu-hash.h
In order to do that, this patch moves into a new header called
asm/task_size_user64.h the information from asm/
Some stack pointers used to also be thread_info pointers
and were called tp. Now that they are only stack pointers,
rename them sp.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c | 17 +++--
arch/powerpc/kernel/setup_64.c | 11 +++
2 files changed, 10 inse
Now that thread_info is similar to task_struct, its address is in r2
so CURRENT_THREAD_INFO() macro is useless. This patch removes it.
At the same time, as the 'cpu' field is not anymore in thread_info,
this patch renames it to TASK_CPU.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Makefile
The table of pointers 'current_set' has been used for retrieving
the stack and current. They used to be thread_info pointers as
they were pointing to the stack and current was taken from the
'task' field of the thread_info.
Now, the pointers of 'current_set' table are now both pointers
to task_str
thread_info is not anymore in the stack, so the entire stack
can now be used.
There is also no risk anymore of corrupting task_cpu(p) with a
stack overflow so the patch removes the test.
When doing this, an explicit test for NULL stack pointer is
needed in validate_sp() as it is not anymore impli
This patch cleans the powerpc kernel before activating
CONFIG_THREAD_INFO_IN_TASK:
- The purpose of the pointer given to call_do_softirq() and
call_do_irq() is to point the new stack ==> change it to void* and
rename it 'sp'
- Don't use CURRENT_THREAD_INFO() to locate the stack.
- Fix a few comment
[text copied from commit 9bbd4c56b0b6
("arm64: prep stack walkers for THREAD_INFO_IN_TASK")]
When CONFIG_THREAD_INFO_IN_TASK is selected, task stacks may be freed
before a task is destroyed. To account for this, the stacks are
refcounted, and when manipulating the stack of another task, it is
nece
When moving to CONFIG_THREAD_INFO_IN_TASK, the thread_info 'cpu' field
gets moved into task_struct and only defined when CONFIG_SMP is set.
This patch ensures that TI_CPU is only used when CONFIG_SMP is set and
that task_struct 'cpu' field is not used directly out of SMP code.
Signed-off-by: Chri
40x/booke have another path to reach 3f from transfer_to_handler,
so ACCOUNT_CPU_USER_ENTRY() have to be moved there.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/entry_32.S | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.
The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following advantages:
- It protects thread_info from corruption in the case of stack
overflows.
- Its address is harder to determine if stac
Le 24/01/2019 à 16:01, Christophe Leroy a écrit :
Le 24/01/2019 à 10:43, Christophe Leroy a écrit :
On 01/24/2019 01:06 AM, Michael Ellerman wrote:
Christophe Leroy writes:
Le 12/01/2019 à 10:55, Christophe Leroy a écrit :
The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_
Le 24/01/2019 à 01:59, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 19/01/2019 à 11:23, Michael Ellerman a écrit :
Christophe Leroy writes:
The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into
Le 24/01/2019 à 10:43, Christophe Leroy a écrit :
On 01/24/2019 01:06 AM, Michael Ellerman wrote:
Christophe Leroy writes:
Le 12/01/2019 à 10:55, Christophe Leroy a écrit :
The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK
which
moves the thread_info into task_struct.
a friendly ping for this. Does anybody see any problem with this
approach?
On Mon 14-01-19 09:24:16, Michal Hocko wrote:
> From: Michal Hocko
>
> Pingfan Liu has reported the following splat
> [5.772742] BUG: unable to handle kernel paging request at 2088
> [5.773618] PGD 0 P
'regno' is directly controlled by user space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
register number that would be read or written. This register number is
called 'regno' which is part o
On 01/24/2019 01:06 AM, Michael Ellerman wrote:
Christophe Leroy writes:
Le 12/01/2019 à 10:55, Christophe Leroy a écrit :
The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following
On 1/23/19 10:25 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2019-01-23 at 21:30 +1100, Paul Mackerras wrote:
>>> Afaik bcs we change the mapping to point to the real HW irq ESB page
>>> instead of the "IPI" that was there at VM init time.
>>
>> So that makes it sound like there is a whole lot goin
42 matches
Mail list logo
