On 04/07/16 17:12, Andrew Donnellan wrote:
Remove the CXL_KERNEL_API and CXL_EEH Kconfig options, as they were only
needed to coordinate the merging of the cxlflash driver. Also remove the
stub implementation of cxl_perst_reloads_same_image() in cxlflash which is
only used if CXL_EEH isn't define
Laurent Dufour writes:
> On 07/07/2016 15:21, Benjamin Herrenschmidt wrote:
>> On Thu, 2016-07-07 at 15:12 +0200, Laurent Dufour wrote:
>>> Most of the time this is fine, but in the case a thread which has really
>>> used those registers is catching a signal just after the restore and
>>> before i
If we don't find registers for the PHB or don't know the model
specific invalidation method, use OPAL calls instead.
Signed-off-by: Benjamin Herrenschmidt
---
v2. Missed some new invalidation calls that went upstream since I
wrote the original patch.
arch/powerpc/platforms/powernv/pci-ioda
Ravi Bangoria writes:
> On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote:
>
> I've sent v4 which enables annotate for bctr' instructions.
>
> for 'bctr', it will show down arrow(indicate jump) and 'bctrl' will show
> right arrow(indicate call). But no navigation options will be provided
* Kees Cook wrote:
> - I couldn't detect a measurable performance change with these features
> enabled. Kernel build times were unchanged, hackbench was unchanged,
> etc. I think we could flip this to "on by default" at some point.
Could you please try to find some syscall workload that doe
On Thu, 7 Jul 2016 09:45:08 -0300 Mauricio Faria De Oliveira wrote:
Use the DMA_ATTR_NO_WARN attribute on dma_map_sg() calls of nvme driver.
Signed-off-by: Mauricio Faria de Oliveira
Reviewed-by: Gabriel Krisman Bertazi
---
Changelog:
v2:
- address warnings from checkpatch.pl (line wrapp
On Thursday, July 7, 2016 1:37:43 PM CEST Kees Cook wrote:
> >
> >> + /* Allow kernel bss region (if not marked as Reserved). */
> >> + if (ptr >= (const void *)__bss_start &&
> >> + end <= (const void *)__bss_stop)
> >> + return NULL;
> >
> > accesses to .data/.rodata/.
Greg Kurz writes:
> Ping ?
Thanks. It got lost in the flood.
It's in my testing tree and should show up in next soon.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
From: Arvind Yadav
> Sent: 07 July 2016 19:38
> -Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
> assigned in ucc_fast_tx_virtual_fifo_base_offset and
> ucc_fast_rx_virtual_fifo_base_offset. These variable are 'unsigned int'.
> So before assginment need a proper type casting
Benjamin Herrenschmidt writes:
> On Thu, 2016-07-07 at 23:21 +1000, Benjamin Herrenschmidt wrote:
>>
>> I think the right fix is that if a restore_sigcontext() has the MSR
>> bits set,
>> it should set the corresponding used_* flag.
>
> Something like this:
>
> (totally untested)
Simon/Laurent,
Kees Cook writes:
> On Thu, Jul 7, 2016 at 12:35 AM, Michael Ellerman wrote:
>> I gave this a quick spin on powerpc, it blew up immediately :)
>
> Wheee :) This series is rather easy to test: blows up REALLY quickly
> if it's wrong. ;)
Better than subtle race conditions which is the usual :)
>>
On Wed, 2016-06-07 at 06:05:54 UTC, Sam bobroff wrote:
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 02416fe..06d79bc 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -588,6 +588,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm
On 07/08/2016 04:54 AM, Masayoshi Mizuma wrote:
Here, I think the error messages should not be suppressed because
the return value of nvme_map_data() is BLK_MQ_RQ_QUEUE_ERROR, so
the IO returns as -EIO.
Agree; good point. fixed in v3.
Thanks for reviewing.
--
Mauricio Faria de Oliveira
IBM L
This patchset introduces dma_attr DMA_ATTR_NO_WARN (just like __GFP_NOWARN),
which tells the DMA-mapping subsystem to suppress allocation failure reports.
On some architectures allocation failures are reported with error messages
to the system logs. Although this can help to identify and debug pr
Introduce the DMA_ATTR_NO_WARN attribute, and document it.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v3:
- dma: none.
v2:
- all: address warnings from checkpatch.pl (line wrapping and typos)
Documentation/DMA-attributes.txt | 17 +
include/linux/dma-attrs.h
Use the DMA_ATTR_NO_WARN attribute on dma_map_sg() calls of nvme driver.
Signed-off-by: Mauricio Faria de Oliveira
Reviewed-by: Gabriel Krisman Bertazi
---
Changelog:
v3:
- nvme: use DMA_ATTR_NO_WARN when ret = BLK_MQ_RQ_QUEUE_BUSY (io will be
requeued) but not when ret = BLK_MQ_RQ_QUEUE_
Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v3:
- powerpc: none
v2:
- all: address warnings from checkpatch.pl (line wrapping and typos)
arch/powerpc/kernel/iommu.c | 6 --
1 file changed, 4 insertions(
On Wed, 2016-06-07 at 21:42:30 UTC, jba...@akamai.com wrote:
> The stringify_in_c() macro may not be included. Make the dependency
> explicit.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Jason Baron
I didn't t
On Fri, 8 Jul 2016, Michael Ellerman wrote:
> > I wonder if this code should be using size_from_object() instead of s->size?
>
> Hmm, not sure. Who's SLUB maintainer? :)
Me.
s->size is the size of the whole object including debugging info etc.
ksize() gives you the actual usable size of an objec
On Tue, 2016-05-07 at 05:07:52 UTC, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e93d8e67737e5b1405792d0a5b
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@li
On Tue, 2016-05-07 at 05:07:53 UTC, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d468fcafb7a42f4e5a73219692
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@li
On Tue, 2016-05-07 at 05:07:54 UTC, Benjamin Herrenschmidt wrote:
> For memory hotplug to work, the MMU code needs to provide the functions
> create_section_mapping() and remove_section_mapping() to respectively
> map and unmap portions of the linear mapping.
>
> At the moment only hash64 provides
On Wed, 2016-29-06 at 18:14:22 UTC, "Guilherme G. Piccoli" wrote:
> The domain/PHB field of PCI addresses has its value obtained from a
> global variable, incremented each time a new domain (represented by
> struct pci_controller) is added on the system. The domain addition
> process happens during
On Wed, 2016-29-06 at 11:25:33 UTC, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman
Applied to powerpc next.
https://git.kernel.org/powerpc/c/fc022fdf41b7f8c48714af154b
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On Wed, 2016-06-07 at 05:18:55 UTC, Michael Ellerman wrote:
> Use "Delta" to refer to the difference between measurements, rather than
> "Error", so scripts that look for "Error" aren't confused into thinking
> there was a failure.
>
> Signed-off-by: Michael Ellerman
Applied to powerpc next.
ht
Am Donnerstag, 07 Juli 2016, 14:12:45 schrieb Dave Young:
> If so maybe change a bit from your precious mentioned 7 args proposal like
> below?
>
> struct kexec_file_fd {
> enum kexec_file_type;
> int fd;
> }
>
> struct kexec_fdset {
> int nr_fd;
> struct kexec_file_fd fd[
On Thu, Jul 07, 2016 at 10:31:11PM +0530, Arvind Yadav wrote:
> -Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
> assigned in ucc_fast_tx_virtual_fifo_base_offset and
> ucc_fast_rx_virtual_fifo_base_offset. These variable are 'unsigned int'.
> So before assginment need a pro
On Fri, Jul 8, 2016 at 9:45 AM, Christoph Lameter wrote:
> On Fri, 8 Jul 2016, Michael Ellerman wrote:
>
>> > I wonder if this code should be using size_from_object() instead of
>> > s->size?
BTW, I can't reproduce this on x86 yet...
>>
>> Hmm, not sure. Who's SLUB maintainer? :)
>
> Me.
>
> s-
On Fri, Jul 8, 2016 at 1:46 AM, Ingo Molnar wrote:
>
> Could you please try to find some syscall workload that does many small user
> copies and thus excercises this code path aggressively?
Any stat()-heavy path will hit cp_new_stat() very heavily. Think the
usual kind of "traverse the whole tree
On Fri, 8 Jul 2016, Kees Cook wrote:
> Is check_valid_pointer() making sure the pointer is within the usable
> size? It seemed like it was checking that it was within the slub
> object (checks against s->size, wants it above base after moving
> pointer to include redzone, etc).
check_valid_pointe
On Fri, Jul 8, 2016 at 12:20 PM, Christoph Lameter wrote:
> On Fri, 8 Jul 2016, Kees Cook wrote:
>
>> Is check_valid_pointer() making sure the pointer is within the usable
>> size? It seemed like it was checking that it was within the slub
>> object (checks against s->size, wants it above base aft
* Linus Torvalds wrote:
> On Fri, Jul 8, 2016 at 1:46 AM, Ingo Molnar wrote:
> >
> > Could you please try to find some syscall workload that does many small user
> > copies and thus excercises this code path aggressively?
>
> Any stat()-heavy path will hit cp_new_stat() very heavily. Think the
On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote:
> On Fri, Jul 8, 2016 at 12:20 PM, Christoph Lameter wrote:
>> On Fri, 8 Jul 2016, Kees Cook wrote:
>>
>>> Is check_valid_pointer() making sure the pointer is within the usable
>>> size? It seemed like it was checking that it was within the slub
>>
On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:
> Quoting Scott Wood (2016-07-06 21:13:23)
> >
> > On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > >
> > > Quoting Scott Wood (2016-06-15 23:21:25)
> > > >
> > > >
> > > > -static struct device_node *cpu_to_clk_node(int
-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assigned in ucc_fast_tx_virtual_fifo_base_offset and
ucc_fast_rx_virtual_fifo_base_offset. It will work on 32-bit architectures
But data can be loss on 64-bit architectures if 'qe_muram_alloc' will
return greater then MAX value
As per your concern, I have changed and submitted one more patch.
This answer of your all questions,
-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assigned in ucc_fast_tx_virtual_fifo_base_offset and
ucc_fast_rx_virtual_fifo_base_offset. It will work on 32-bit architectu
PowerVM seems to only ever provide a single hotplug slot per PHB.
The under lying slot hotplug registration code assumed multiple slots,
but the actual implementation is broken for multiple slots. This went
unnoticed for years due to the nature of PowerVM as mentioned
previously. Under qemu/kvm the
On 07/08/2016 06:19 PM, Tyrel Datwyler wrote:
> PowerVM seems to only ever provide a single hotplug slot per PHB.
> The under lying slot hotplug registration code assumed multiple slots,
> but the actual implementation is broken for multiple slots. This went
> unnoticed for years due to the nature
On 07/07/2016 06:48 PM, Daniel Walker wrote:
> On 07/07/2016 03:37 PM, Scott Wood wrote:
>> On 07/07/2016 05:01 PM, Daniel Walker wrote:
>>> On 07/07/2016 02:59 PM, Scott Wood wrote:
On 07/07/2016 04:49 PM, Daniel Walker wrote:
> On 07/07/2016 02:23 PM, Scott Wood wrote:
>> I suspect t
As per you concern, I have submitted one more patch with some changes.
Please review it.
Thanks,
On Friday 08 July 2016 09:03 PM, Guenter Roeck wrote:
On Thu, Jul 07, 2016 at 10:31:11PM +0530, Arvind Yadav wrote:
-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assign
On 07/08/2016 02:44 PM, Arvind Yadav wrote:
I would really suggest to read section 14 of Documentation/SubmittingPatches
and to follow the guidance it provides.
For the subject line: The subsystem/driver is still not listed,
and I am quite sure that this is not v1 of this patch.
It also does not
On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote:
>
> Even with the SLUB fixup I'm still seeing this blow up on my arm64
> system. This is a
> Fedora rawhide kernel + the patches
>
> [0.666700] usercopy: kernel memory exposure attempt detected from
> fc0008b4dd58 () (8 bytes)
> [
-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assigned in ucc_fast_tx_virtual_fifo_base_offset and
ucc_fast_rx_virtual_fifo_base_offset. It will work on 32-bit architectures
But data can be loss on 64-bit architectures if 'qe_muram_alloc' will
return greater then MAX value
Kees Cook writes:
> On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote:
>> So, as found already, the position in the usercopy check needs to be
>> bumped down by red_left_pad, which is what Michael's fix does, so I'll
>> include it in the next version.
>
> Actually, after some offline chats, I thin
Michael Ellerman writes:
> Kees Cook writes:
>
>> On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote:
>>> So, as found already, the position in the usercopy check needs to be
>>> bumped down by red_left_pad, which is what Michael's fix does, so I'll
>>> include it in the next version.
>>
>> Actual
On Sat, 09 Jul 2016 15:58:20 +1000, Michael Ellerman said:
> I then get two hits, which may or may not be valid:
>
> [2.309556] usercopy: kernel memory overwrite attempt detected to
> d3510028 (kernfs_node_cache) (64 bytes)
> [2.309995] CPU: 7 PID: 2241 Comm: wait-for-root Not tai
46 matches
Mail list logo
