Le 08/01/2019 à 13:21, Christophe Leroy a écrit :
Le 08/01/2019 à 13:05, Michael Ellerman a écrit :
The page size the kernel is built with is useful info when debugging a
crash, so add it to the output in __die().
Result looks like eg:
kernel BUG at drivers/misc/lkdtm/bugs.c:63!
On Wed, 2019-01-09 at 17:32 +1100, Alexey Kardashevskiy wrote:
> I have just moved the "Mellanox Technologies MT27700 Family
> [ConnectX-4]" from garrison to firestone machine and there it does not
> produce an EEH, with the same kernel and skiboot (both upstream + my
> debug). Hm. I cannot really
On Wed, 2019-01-09 at 15:53 +1100, Alexey Kardashevskiy wrote:
> "A PCI completion timeout occurred for an outstanding PCI-E transaction"
> it is.
>
> This is how I bind the device to vfio:
>
> echo vfio-pci > '/sys/bus/pci/devices/:01:00.0/driver_override'
> echo vfio-pci >
On 09/01/2019 16:30, David Gibson wrote:
> On Wed, Jan 09, 2019 at 04:09:02PM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
>>>
In a very cryptic way that requires manual parsing using non-public
docs sadly but yes. From the look of
Le 09/01/2019 à 02:14, Kees Cook a écrit :
On Fri, Dec 14, 2018 at 7:26 AM Christophe Leroy
wrote:
Introduce lkdtm tests for NULL pointer dereference: check
access or exec at NULL address.
Why is this not already covered by the existing tests? (Is there
something special about NULL that
Hello Thiago,
Wish you a happy 2019!
On Sat, Dec 08, 2018 at 12:40:52AM -0200, Thiago Jung Bauermann wrote:
>
> Gautham R Shenoy writes:
> > On Fri, Dec 07, 2018 at 04:13:11PM +0530, Gautham R Shenoy wrote:
> >> Sure. I will test the patch and report back.
> >
> > I added the following debug
On Wed, Jan 09, 2019 at 04:09:02PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
> >
> > > In a very cryptic way that requires manual parsing using non-public
> > > docs sadly but yes. From the look of it, it's a completion timeout.
> > >
> > >
On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
>
> > In a very cryptic way that requires manual parsing using non-public
> > docs sadly but yes. From the look of it, it's a completion timeout.
> >
> > Looks to me like we don't get a response to a config space access
> > during the
On Mon, Jan 07, 2019 at 07:43:15PM +0100, Cédric Le Goater wrote:
> We will have different KVM devices for interrupts, one for the
> XICS-over-XIVE mode and one for the XIVE native exploitation
> mode. Let's add some checks to make sure we are not mixing the
> interfaces in KVM.
>
>
On Mon, Jan 07, 2019 at 07:43:14PM +0100, Cédric Le Goater wrote:
> The support for XIVE native exploitation mode in Linux/KVM needs a
> couple more OPAL calls to configure the sPAPR guest and to get/set the
> state of the XIVE internal structures.
>
> Signed-off-by: Cédric Le Goater
On 06/01/2019 09:43, Benjamin Herrenschmidt wrote:
> On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote:
>>
>>> Interesting. I've investigated this further, though I don't have as
>>> many new clues as I'd like. The problem occurs reliably, at least on
>>> one particular type of machine
Hi Arnaldo,
Yes. I'm aware of it. Just that I was busy with something else so couldn't do
it.
Thanks for reminding :). Will post a patch soon.
Ravi
On 1/8/19 10:34 PM, Arnaldo Carvalho de Melo wrote:
> Hi Ravi,
>
> I noticed that in:
>
> commit
On Mon, Jan 07, 2019 at 07:43:13PM +0100, Cédric Le Goater wrote:
> These flags are shared between Linux/KVM implementing the hypervisor
> calls for the XIVE native exploitation mode and the driver for the
> sPAPR guests.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
> ---
>
On Tue, Jan 08, 2019 at 10:21:07AM +0530, Aneesh Kumar K.V wrote:
> This patch add PF_MEMALLOC_NOCMA which make sure any allocation in that
> context
> is marked non movable and hence cannot be satisfied by CMA region.
>
> This is useful with get_user_pages_cma_migrate where we take a page pin
Hello,
On Tue, Jan 08, 2019 at 10:21:09AM +0530, Aneesh Kumar K.V wrote:
> @@ -187,41 +149,25 @@ static long mm_iommu_do_alloc(struct mm_struct *mm,
> unsigned long ua,
> goto unlock_exit;
> }
>
> + ret = get_user_pages_cma_migrate(ua, entries, 1, mem->hpages);
In
On Fri, Dec 14, 2018 at 7:26 AM Christophe Leroy
wrote:
>
> Introduce lkdtm tests for NULL pointer dereference: check
> access or exec at NULL address.
Why is this not already covered by the existing tests? (Is there
something special about NULL that is being missed?) I'd expect SMAP
and SMEP to
On Wed, Jan 9, 2019 at 9:31 AM Bjorn Helgaas wrote:
>
> Hi,
>
> I want to update the PCI Kconfig labels so they're more consistent and
> useful to users, something like the patch below. IIUC, the items
> below are all IBM-related; please correct me if not.
>
> I'd also like to expand (or remove)
On Tue, 8 Jan 2019, Michael Ellerman wrote:
> > The reason why that doesn't work boils down to introspection. (This
> > was mentioned elsewhere in this email thread.) For example, we
> > presently have code like this,
> >
> > ssize_t nvram_get_size(void)
> > {
> >if (ppc_md.nvram_size)
Hi,
I want to update the PCI Kconfig labels so they're more consistent and
useful to users, something like the patch below. IIUC, the items
below are all IBM-related; please correct me if not.
I'd also like to expand (or remove) "RPA" because Google doesn't find
anything about "IBM RPA", except
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 elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct
On Tue, Jan 8, 2019 at 12:10 PM Arnd Bergmann wrote:
>
> This is a cleanup to prepare for the addition of 64-bit time_t
> in O_SNDTIMEO/O_RCVTIMEO. The existing compat handler seems
> unnecessarily complex and error-prone, moving it all into the
> main setsockopt()/getsockopt() implementation
On Tue, Jan 8, 2019 at 12:04 PM Arnd Bergmann wrote:
>
> On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani wrote:
> >
> > SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> > as the time format. struct timeval is not y2038 safe.
> > The subsequent patches in the series add support for
On Tue, Jan 8, 2019 at 1:11 PM Christophe Leroy wrote:
>
>
>
> Le 08/01/2019 à 20:48, Andrew Morton a écrit :
> > On Tue, 8 Jan 2019 07:37:44 + (UTC) Christophe Leroy
> > wrote:
> >
> >> In powerpc code, there are several places implementing safe
> >> access to user data. This is sometimes
Le 08/01/2019 à 20:48, Andrew Morton a écrit :
On Tue, 8 Jan 2019 07:37:44 + (UTC) Christophe Leroy
wrote:
In powerpc code, there are several places implementing safe
access to user data. This is sometimes implemented using
probe_kernel_address() with additional access_ok()
This is a cleanup to prepare for the addition of 64-bit time_t
in O_SNDTIMEO/O_RCVTIMEO. The existing compat handler seems
unnecessarily complex and error-prone, moving it all into the
main setsockopt()/getsockopt() implementation requires half
as much code and is easier to extend.
32-bit user
On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani wrote:
>
> SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> as the time format. struct timeval is not y2038 safe.
> The subsequent patches in the series add support for new socket
> timeout options with _NEW suffix that are y2038 safe.
On Tue, 8 Jan 2019 10:21:06 +0530 "Aneesh Kumar K.V"
wrote:
> ppc64 use CMA area for the allocation of guest page table (hash page table).
> We won't
> be able to start guest if we fail to allocate hash page table. We have
> observed
> hash table allocation failure because we failed to
On Tue, 8 Jan 2019 07:37:44 + (UTC) Christophe Leroy
wrote:
> In powerpc code, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a
From: Breno Leitao
[ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]
When booting a pseries kernel with PREEMPT enabled, it dumps the
following warning:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is pseries_processor_idle_init+0x5c/0x22c
From: Breno Leitao
[ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]
When booting a pseries kernel with PREEMPT enabled, it dumps the
following warning:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is pseries_processor_idle_init+0x5c/0x22c
From: Breno Leitao
[ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]
When booting a pseries kernel with PREEMPT enabled, it dumps the
following warning:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is pseries_processor_idle_init+0x5c/0x22c
From: Breno Leitao
[ Upstream commit 8d4a862276a9c30a269d368d324fb56529e6d5fd ]
Currently xmon needs to get devtree_lock (through rtas_token()) during its
invocation (at crash time). If there is a crash while devtree_lock is being
held, then xmon tries to get the lock but spins forever and
From: Breno Leitao
[ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]
When booting a pseries kernel with PREEMPT enabled, it dumps the
following warning:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is pseries_processor_idle_init+0x5c/0x22c
From: Breno Leitao
[ Upstream commit 8d4a862276a9c30a269d368d324fb56529e6d5fd ]
Currently xmon needs to get devtree_lock (through rtas_token()) during its
invocation (at crash time). If there is a crash while devtree_lock is being
held, then xmon tries to get the lock but spins forever and
From: Breno Leitao
[ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]
When booting a pseries kernel with PREEMPT enabled, it dumps the
following warning:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is pseries_processor_idle_init+0x5c/0x22c
From: Breno Leitao
[ Upstream commit 8d4a862276a9c30a269d368d324fb56529e6d5fd ]
Currently xmon needs to get devtree_lock (through rtas_token()) during its
invocation (at crash time). If there is a crash while devtree_lock is being
held, then xmon tries to get the lock but spins forever and
From: Suraj Jitindar Singh
[ Upstream commit 8b23eee4e55a32a2b51a180dfd27a8d214acc7a1 ]
The shadow page table contains ptes for translations from nested guest
address to host address. Currently when creating these ptes we take the
rc bits from the pte for the L1 guest address to host address
From: Suraj Jitindar Singh
[ Upstream commit 8400f8740651c1a3081c30b46004451c448f4d5f ]
Nested rmap entries are used to store the translation from L1 gpa to L2
gpa when entries are inserted into the shadow (nested) page tables. This
rmap list is located by indexing the rmap array in the memslot
From: Breno Leitao
[ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]
When booting a pseries kernel with PREEMPT enabled, it dumps the
following warning:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is pseries_processor_idle_init+0x5c/0x22c
From: Breno Leitao
[ Upstream commit 8d4a862276a9c30a269d368d324fb56529e6d5fd ]
Currently xmon needs to get devtree_lock (through rtas_token()) during its
invocation (at crash time). If there is a crash while devtree_lock is being
held, then xmon tries to get the lock but spins forever and
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 elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kmalloc(sizeof(struct
On Tue, Jan 08, 2019 at 11:36:33AM -0500, Boris Ostrovsky wrote:
> On 1/8/19 5:48 AM, Peter Zijlstra wrote:
> > On the various exclude options; they are as follows (IIUC):
> >
> > - exclude_guest: we're a HV/host-kernel and we don't want the counter
> >to run when we run a
On Tuesday, January 8, 2019 10:54:28 AM CET Michael Ellerman wrote:
> Christian Lamparter writes:
> > On Wednesday, January 2, 2019 12:31:50 PM CET Michael Ellerman wrote:
> >> On Tue, 2019-01-01 at 03:56:00 UTC, Michael Ellerman wrote:
> >> > Currently the code produces several warnings, eg:
>
Hi Ravi,
I noticed that in:
commit ab66dcc76d6ab8fae9d69d149ae38c42605e7fc5
Author: Firoz Khan
Date: Mon Dec 17 16:10:36 2018 +0530
powerpc: generate uapi header and system call table files
powerpc now generates its syscall tables headers from a syscall.tbl just
like x86
On 1/8/19 5:48 AM, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
>> For drivers that do not support context exclusion let's advertise the
>> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
>> prevent us from handling events where any
ipic_set_highest_priority(), ipic_enable_mcp() and ipic_disable_mcp()
are unused. This patch drops them.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ipic.h | 3 ---
arch/powerpc/sysdev/ipic.c | 35 ---
2 files changed, 38 deletions(-)
diff
On Tue, 8 Jan 2019, Christophe Leroy wrote:
> Oops, forgot to actually copy Thomas.
>
> Le 08/01/2019 à 12:37, Christophe Leroy a écrit :
> > arch_early_irq_init() does nothing different than
> > the weak arch_early_irq_init() in kernel/softirq.c
> >
> > Fixes: 089fb442f301 ("powerpc: Use
On Tue, Jan 08, 2019 at 01:13:57PM +, Andrew Murray wrote:
> On Tue, Jan 08, 2019 at 02:10:31PM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote:
> >
> > > Yes I found lots of examples like this across the tree whilst doing this
> > > work.
Hi,
On Tue, Jan 08, 2019 at 01:43:09PM +, 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
>
Hi,
On Tue, Jan 08, 2019 at 11:02:24AM +0100, Christophe Leroy wrote:
>
> Le 31/12/2018 à 10:29, Mike Rapoport a écrit :
> >There are a several places that allocate memory using memblock APIs that
> >return a physical address, convert the returned address to the virtual
> >address and frequently
> -Original Message-
> From: Scott Wood
> Sent: Saturday, December 22, 2018 06:07
> To: Camelia Alexandra Groza ;
> robh...@kernel.org; mark.rutl...@arm.com; b...@kernel.crashing.org
> Cc: devicet...@vger.kernel.org; linux-ker...@vger.kernel.org;
> pau...@samba.org;
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
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
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
---
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
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
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
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
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:
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
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
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
Signed-off-by: Christophe Leroy
---
@Mike: Part of this is taken from your serie. I was
On Tue, Jan 08, 2019 at 02:10:31PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote:
>
> > Yes I found lots of examples like this across the tree whilst doing this
> > work. However I decided to initially start with simply removing duplicated
> > code
On Tue, Jan 08, 2019 at 11:48:41AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
> > For drivers that do not support context exclusion let's advertise the
> > PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
> > prevent us from handling
On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote:
> Yes I found lots of examples like this across the tree whilst doing this
> work. However I decided to initially start with simply removing duplicated
> code as a result of adding this flag and attempting to preserve existing
>
On Tue, Jan 08, 2019 at 11:49:40AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:28PM +, Andrew Murray wrote:
>
> This patch has the exact same subject as the previous one.. that seems
> sub-optimal.
Ah yes, I'll update that in subsquent revisions. (The reason for two patches
On Tue, Jan 08, 2019 at 11:28:02AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:22PM +, Andrew Murray wrote:
> > @@ -393,9 +386,8 @@ __hw_perf_event_init(struct perf_event *event)
> > /*
> > * Check whether we need to exclude the counter from certain modes.
> > */
Add the DT binding documentation for Audio Mixer
machine driver.
Signed-off-by: Viorel Suman
---
.../devicetree/bindings/sound/imx-audmix.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/imx-audmix.txt
diff
This patch implements Audio Mixer machine driver for NXP iMX8 SOCs.
It connects together Audio Mixer and related SAI instances.
Signed-off-by: Viorel Suman
---
sound/soc/fsl/Kconfig | 9 ++
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/imx-audmix.c | 333
Add the DT binding documentation for NXP Audio Mixer
CPU DAI driver.
Signed-off-by: Viorel Suman
---
.../devicetree/bindings/sound/fsl,audmix.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt
diff
This patch implements Audio Mixer CPU DAI driver for NXP iMX8 SOCs.
The Audio Mixer is a on-chip functional module that allows mixing of
two audio streams into a single audio stream.
Audio Mixer datasheet is available here:
https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
The patchset adds NXP Audio Mixer (AUDMIX) device and machine
drivers and related DT bindings documentation.
Changes since V1:
1. Original patch split into distinct patches for the device driver and
DT binding documentation.
2. Replaced AMIX with AUDMIX in both code and file names as it looks
I wanted to test the virtex440-ml507 qemu machine and found that the dtb
for it was not builded.
All powerpc DTB are only built when CONFIG_OF_ALL_DTBS is set which depend on
COMPILE_TEST.
This patchs adds build of virtex dtbs depending on
CONFIG_XILINX_VIRTEX440_GENERIC_BOARD option.
Le 08/01/2019 à 13:05, Michael Ellerman a écrit :
The page size the kernel is built with is useful info when debugging a
crash, so add it to the output in __die().
Result looks like eg:
kernel BUG at drivers/misc/lkdtm/bugs.c:63!
Oops: Exception in kernel mode, sig: 5 [#1]
LE
Le 08/01/2019 à 13:04, Michael Ellerman a écrit :
Using pr_cont() risks having our output interleaved with other output
from other CPUs. Instead use a seq_buf to construct the line and then
print it as a whole.
Why not simply doing a single printk() or similar on the same model as
X86 for
The page size the kernel is built with is useful info when debugging a
crash, so add it to the output in __die().
Result looks like eg:
kernel BUG at drivers/misc/lkdtm/bugs.c:63!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K SMP NR_CPUS=2048 NUMA pSeries
Modules linked
Using pr_cont() risks having our output interleaved with other output
from other CPUs. Instead use a seq_buf to construct the line and then
print it as a whole.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/traps.c | 23 ---
1 file changed, 16 insertions(+), 7
Oops, forgot to actually copy Thomas.
Le 08/01/2019 à 12:37, Christophe Leroy a écrit :
arch_early_irq_init() does nothing different than
the weak arch_early_irq_init() in kernel/softirq.c
Fixes: 089fb442f301 ("powerpc: Use ARCH_IRQ_INIT_FLAGS")
Cc: Thomas Gleixner
Signed-off-by: Christophe
arch_early_irq_init() does nothing different than
the weak arch_early_irq_init() in kernel/softirq.c
Fixes: 089fb442f301 ("powerpc: Use ARCH_IRQ_INIT_FLAGS")
Cc: Thomas Gleixner
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c | 5 -
1 file changed, 5 deletions(-)
diff --git
On 1/8/19 9:14 AM, Christophe Leroy wrote:
> Le 08/01/2019 à 12:11, Breno Leitao a écrit :
>> Hi Michael,
>>
>> On 1/8/19 7:20 AM, Michael Ellerman wrote:
>>> Breno Leitao writes:
>>>
hi Christophe,
On 1/3/19 3:19 PM, LEROY Christophe wrote:
> Breno Leitao a écrit :
>
A new self test that forces MSR[TS] to be set without calling any TM
instruction. This test also tries to cause a page fault at a signal
handler, exactly between MSR[TS] set and tm_recheckpoint(), forcing
thread->texasr to be rewritten with TEXASR[FS] = 0, which will cause a BUG
when
Le 08/01/2019 à 12:11, Breno Leitao a écrit :
Hi Michael,
On 1/8/19 7:20 AM, Michael Ellerman wrote:
Breno Leitao writes:
hi Christophe,
On 1/3/19 3:19 PM, LEROY Christophe wrote:
Breno Leitao a écrit :
This patch simply adds definitions for the MSR bits and some macros to
test for
Hi Michael,
On 1/8/19 7:20 AM, Michael Ellerman wrote:
> Breno Leitao writes:
>
>> hi Christophe,
>>
>> On 1/3/19 3:19 PM, LEROY Christophe wrote:
>>> Breno Leitao a écrit :
>>>
This patch simply adds definitions for the MSR bits and some macros to
test for MSR TM bits.
On Mon, Jan 07, 2019 at 04:27:28PM +, Andrew Murray wrote:
This patch has the exact same subject as the previous one.. that seems
sub-optimal.
On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
> For drivers that do not support context exclusion let's advertise the
> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
> prevent us from handling events where any exclusion flags are set.
> Let's also remove the now
On Mon, Jan 07, 2019 at 04:27:22PM +, Andrew Murray wrote:
> @@ -393,9 +386,8 @@ __hw_perf_event_init(struct perf_event *event)
> /*
>* Check whether we need to exclude the counter from certain modes.
>*/
> + if (armpmu->set_event_filter &&
> +
Darren Stevens writes:
> Hello Michael
>
> On 22/12/2018, Michael Ellerman wrote:
>> On Sun, 2018-08-19 at 20:21:47 UTC, Darren Stevens wrote:
>>> Add a IRQ init routine for the Nemo board which inits and attatches
>>> the i8259 found in the SB600, and a cascade routine to dispatch the
>>>
Breno Leitao writes:
> On 12/20/18 10:51 AM, Michael Ellerman wrote:
>> Breno Leitao writes:
>>
>>> A new self test that forces MSR[TS] to be set without calling any TM
>>> instruction. This test also tries to cause a page fault at a signal
>>> handler, exactly between MSR[TS] set and
Rob Herring writes:
> On Fri, Jan 4, 2019 at 3:58 AM Corentin Labbe wrote:
>>
>> I wanted to test the virtex440-ml507 qemu machine and found that the dtb
>> for it was not builded.
>
> Just do:
>
> make virtex440-ml507.dtb
I actually thought you had to do that, so I've never done anything
Le 31/12/2018 à 10:29, Mike Rapoport a écrit :
There are a several places that allocate memory using memblock APIs that
return a physical address, convert the returned address to the virtual
address and frequently also memset(0) the allocated range.
Update these places to use memblock
On Tue, 2019-01-08 at 10:37 +0100, Christophe Leroy wrote:
> Hi Michael and Russell,
>
> Any idea why:
> - checkpatch reports missing Signed-off-by:
> - Snowpatch build fails on PPC64 (it seems unrelated to the patch,
> something wrong in lib/genalloc.c)
Upstream kernel broke for powerpc
Christian Lamparter writes:
> On Wednesday, January 2, 2019 12:31:50 PM CET Michael Ellerman wrote:
>> On Tue, 2019-01-01 at 03:56:00 UTC, Michael Ellerman wrote:
>> > Currently the code produces several warnings, eg:
>> >
>> > arch/powerpc/platforms/4xx/ocm.c:240:38: error: format '%llx'
>> >
Le 08/01/2019 à 07:56, Christophe Leroy a écrit :
This patch moves the mapping of IV after the kmalloc(). This
avoids having to unmap in case kmalloc() fails.
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
new in v4
drivers/crypto/talitos.c | 25
On 1/8/2019 8:56 AM, Christophe Leroy wrote:
> [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
> dma_nommu_map_page+0x44/0xd4
> [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
> 4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
> [
On 1/8/2019 8:56 AM, Christophe Leroy wrote:
> This patch moves the mapping of IV after the kmalloc(). This
> avoids having to unmap in case kmalloc() fails.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Horia Geantă
Since patch 2/2 is Cc-ing stable, this one should do the same.
Herbert,
Hi Michael and Russell,
Any idea why:
- checkpatch reports missing Signed-off-by:
- Snowpatch build fails on PPC64 (it seems unrelated to the patch,
something wrong in lib/genalloc.c)
Thanks
Christophe
Le 08/01/2019 à 08:37, Christophe Leroy a écrit :
Instead of opencoding, use
Finn Thain writes:
> On Mon, 7 Jan 2019, Michael Ellerman wrote:
>
>> Arnd Bergmann writes:
>> > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
>> > wrote:
>> >
>> >> +static ssize_t ppc_nvram_get_size(void)
>> >> +{
>> >> + if (ppc_md.nvram_size)
>> >> + return
Breno Leitao writes:
> hi Christophe,
>
> On 1/3/19 3:19 PM, LEROY Christophe wrote:
>> Breno Leitao a écrit :
>>
>>> This patch simply adds definitions for the MSR bits and some macros to
>>> test for MSR TM bits.
>>>
>>> This was copied from arch/powerpc/include/asm/reg.h generic MSR part.
Le 08/01/2019 à 10:04, David Hildenbrand a écrit :
On 08.01.19 08:37, Christophe Leroy wrote:
Instead of opencoding, use probe_user_read() to failessly
read a user location.
Signed-off-by: Christophe Leroy
---
v2: Using probe_user_read() instead of probe_user_address()
On 08.01.19 08:37, Christophe Leroy wrote:
> Instead of opencoding, use probe_user_read() to failessly
> read a user location.
>
> Signed-off-by: Christophe Leroy
> ---
> v2: Using probe_user_read() instead of probe_user_address()
>
> arch/powerpc/kernel/process.c | 12 +---
>
1 - 100 of 101 matches
Mail list logo
