On Tue, Sep 15, 2015 at 08:49:35PM +1000, Alexey Kardashevskiy wrote:
> At the moment pages used for TCE tables (in addition to pages addressed
> by TCEs) are not counted in locked_vm counter so a malicious userspace
> tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and
> l
On Tue, Sep 15, 2015 at 08:49:36PM +1000, Alexey Kardashevskiy wrote:
> SPAPR_TCE_SHIFT is used in few places only and since IOMMU_PAGE_SHIFT_4K
> can be easily used instead, remove SPAPR_TCE_SHIFT.
>
> Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
> ---
> arch/powerpc/include
On Tue, Sep 15, 2015 at 08:49:38PM +1000, Alexey Kardashevskiy wrote:
> The KVM_SMI capability is following the KVM_S390_SET_IRQ_STATE capability
> which is "4.95", this changes the number of the KVM_SMI chapter to 4.96.
>
> Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
--
Da
On Tue, Sep 15, 2015 at 08:49:37PM +1000, Alexey Kardashevskiy wrote:
> Upcoming multi-tce support (H_PUT_TCE_INDIRECT/H_STUFF_TCE hypercalls)
> will validate TCE (not to have unexpected bits) and IO address
> (to be within the DMA window boundaries).
>
> This introduces helpers to validate TCE an
On Tue, Sep 15, 2015 at 08:49:39PM +1000, Alexey Kardashevskiy wrote:
> This adds real and virtual mode handlers for the H_PUT_TCE_INDIRECT and
> H_STUFF_TCE hypercalls for user space emulated devices such as IBMVIO
> devices or emulated PCI. These calls allow adding multiple entries
> (up to 512)
I found that there are unimplemented OPAL message types "OPAL_MSG_EPOW" and
"OPAL_MSG_DPO" in PowerNV Platform. If skiboot send such messages to kernel,
nothing will happen(notifier_call_chain() will silently drop it). So I add a
warning
to inform what has happened, is it necessary?
Signed-of
Regards,
Igal Liberman
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, December 03, 2015 10:24 PM
> To: Liberman Igal-B31950
> Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; Wood Scott-B07421 ;
> Bucur
> Take the scenario where CPU1 is in the middle of a printk(), and is
> holding its lock.
>
> CPU0 comes along and decides to trigger a NMI backtrace. This sends
> a NMI to CPU1, which takes it in the middle of the serial console
> output.
>
> With the existing solution, the NMI output will be w
On Mon 2015-12-07 15:48:33, David Laight wrote:
> From: Russell King - ARM Linux
> > Sent: 04 December 2015 17:13
> ...
> > I have a slightly different view...
> >
> > > > I don't see bust_spinlocks() dealing with any of these locks, so IMHO
> > > > trying to make this work in NMI context strikes
It has come to my attention that kprobe event stack tracing does not
work on powerpc. You can see with the following:
# cd /sys/kernel/debug/tracing
# echo stacktrace > trace_options
# echo 'p kfree' > kprobe_events
# echo 'r exit_mmap' >> kprobe_events
# echo 1 > events/kprobes/enable
Gives
On Thu, Dec 3, 2015 at 1:19 AM, wrote:
> From: Igal Liberman
>
> This patch adds the Ethernet MAC driver supporting the three
> different types of MACs: dTSEC, tGEC and mEMAC.
>
> Signed-off-by: Igal Liberman
[...]
> +
> +MODULE_LICENSE("Dual BSD/GPL");
> +
> +MODULE_AUTHOR("Emil Medve ");
I
When a transaction is aborted, VSR values should rollback to the
checkpointed values before the transaction began. VSRs used elsewhere in
the kernel during a transaction, or while the transaction is suspended
should not affect the checkpointed values.
Signed-off-by: Rashmica Gupta
---
Prior to t
On Tue, 2015-12-08 at 14:18 -0600, Andy Fleming wrote:
> On Thu, Dec 3, 2015 at 1:19 AM, wrote:
> > From: Igal Liberman
> >
> > This patch adds the Ethernet MAC driver supporting the three
> > different types of MACs: dTSEC, tGEC and mEMAC.
> >
> > Signed-off-by: Igal Liberman
>
> [...]
>
>
On Mon, 2015-12-07 at 15:12 +0100, Christian Zigotzky wrote:
> Hi all,
>
> I have some good news for you. I was able to fix the issue with the
> P.A.
> Semi Ethernet. It was a problem with the new DMA handling. The patch
> '
> [RFC/PATCH,v2] powerpc/iommu: Support "hybrid" iommu/direct DMA ops
>
Hi Wen,
Thanks for the patch.
On Tue, 2015-12-08 at 15:30 +0800, wen...@powercore.com.cn wrote:
> I found that there are unimplemented OPAL message types "OPAL_MSG_EPOW" and
> "OPAL_MSG_DPO" in PowerNV Platform. If skiboot send such messages to kernel,
> nothing will happen(notifier_call_chain(
On Tue, 2015-12-08 at 13:50 -0500, Steven Rostedt wrote:
> It has come to my attention that kprobe event stack tracing does not
> work on powerpc.
Yep looks like you're right. I didn't realise it was separate from the regular
stack trace stuff.
> diff --git a/arch/powerpc/kernel/stacktrace.c
>
On Wed, 09 Dec 2015 11:20:22 +1100
Michael Ellerman wrote:
> On Tue, 2015-12-08 at 13:50 -0500, Steven Rostedt wrote:
>
> > It has come to my attention that kprobe event stack tracing does not
> > work on powerpc.
>
> Yep looks like you're right. I didn't realise it was separate from the regu
This file was originally cloned off of the MPC8641D-HPCN reference
platform, which actually had a PHY IRQ line connected. However
this board does not. The bogus entry was largely inert and went
undetected until commit 321beec5047af83db90c88114b7e664b156f49fe
("net: phy: Use interrupts when availa
On Tue, 2015-12-08 at 17:30 +1100, Andrew Donnellan wrote:
> Finally looking at this patch again for the first time in a couple of
> months...
>
> On 04/11/15 17:17, Andrew Donnellan wrote:
> > On 03/11/15 20:09, Michael Ellerman wrote:
> > > Part of your problem is you're storing afu->crs_len whi
On Tue, 2015-12-08 at 19:28 -0500, Steven Rostedt wrote:
> On Wed, 09 Dec 2015 11:20:22 +1100
> Michael Ellerman wrote:
> > On Tue, 2015-12-08 at 13:50 -0500, Steven Rostedt wrote:
> > > It has come to my attention that kprobe event stack tracing does not
> > > work on powerpc.
> > > diff --git
On Wed, 2015-12-09 at 12:00 +1100, Michael Neuling wrote:
> On Tue, 2015-12-08 at 17:30 +1100, Andrew Donnellan wrote:
> > Finally looking at this patch again for the first time in a couple of
> > months...
> >
> > On 04/11/15 17:17, Andrew Donnellan wrote:
> > > On 03/11/15 20:09, Michael Ellerma
On Tue, 2015-12-08 at 17:44 -0500, Paul Gortmaker wrote:
> This file was originally cloned off of the MPC8641D-HPCN reference
> platform, which actually had a PHY IRQ line connected. However
> this board does not. The bogus entry was largely inert and went
> undetected until commit 321beec5047af
On Wed, 09 Dec 2015 12:03:05 +1100
Michael Ellerman wrote:
> Looks like we actually have:
>
> #define kernel_stack_pointer(regs) ((regs)->gpr[1])
>
> So that would be the most self documenting way to do it I guess, though I've
> never actually seen that macro used anywhere before :)
Cool, t
From: Scott Wood
Date: Tue, 8 Dec 2015 16:44:38 -0600
> On Tue, 2015-12-08 at 14:18 -0600, Andy Fleming wrote:
>> On Thu, Dec 3, 2015 at 1:19 AM, wrote:
>> > From: Igal Liberman
>> >
>> > This patch adds the Ethernet MAC driver supporting the three
>> > different types of MACs: dTSEC, tGEC an
[Re: [PATCH] sbc8641: drop bogus PHY IRQ entries from DTS file] On 09/12/2015
(Wed 12:10) Michael Ellerman wrote:
> On Tue, 2015-12-08 at 17:44 -0500, Paul Gortmaker wrote:
>
> > This file was originally cloned off of the MPC8641D-HPCN reference
> > platform, which actually had a PHY IRQ line co
From: Paul Gortmaker
Date: Tue, 8 Dec 2015 17:44:02 -0500
> This file was originally cloned off of the MPC8641D-HPCN reference
> platform, which actually had a PHY IRQ line connected. However
> this board does not. The bogus entry was largely inert and went
> undetected until commit 321beec504
On Tue, 2015-12-08 at 21:40 -0500, David Miller wrote:
> From: Paul Gortmaker
> Date: Tue, 8 Dec 2015 17:44:02 -0500
> > This file was originally cloned off of the MPC8641D-HPCN reference
> > platform, which actually had a PHY IRQ line connected. However
> > this board does not. The bogus entry
On Tue, 2015-12-08 at 21:04 -0500, Paul Gortmaker wrote:
> [Re: [PATCH] sbc8641: drop bogus PHY IRQ entries from DTS file] On 09/12/2015
> (Wed 12:10) Michael Ellerman wrote:
> > On Tue, 2015-12-08 at 17:44 -0500, Paul Gortmaker wrote:
> > > This file was originally cloned off of the MPC8641D-HPCN
On Tue, Dec 08, 2015 at 05:44:02PM -0500, Paul Gortmaker wrote:
> This file was originally cloned off of the MPC8641D-HPCN reference
> platform, which actually had a PHY IRQ line connected. However
> this board does not. The bogus entry was largely inert and went
> undetected until commit 321beec
commit 152d523e6307 ("powerpc: Create context switch helpers save_sprs()
and restore_sprs()") has an issue with newly created processes and
kernel threads. These do not call back through __switch_to(), instead
returning straight to ret_from_fork() or ret_from_kernel_thread().
This means restore_sp
Hi Anton,
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20151208]
[cannot apply to v4.4-rc4]
url:
https://github.com/0day-ci/linux/commits/Anton-Blanchard/powerpc-Call-restore_sprs-on-initial-context-switch/20151209-123550
base: https://git.kernel.org/pub/scm/linux
The OpenPower Abstraction Layer firmware went through a couple
of iterations in the lab before being released. What we now know
as OPAL advertises itself as OPALv3.
OPALv2 and OPALv1 never made it outside the lab, and the possibility
of anyone at all ever building a mainline kernel today and expec
Long ago, only in the lab, there was OPALv1 and OPALv2. Now there is
just OPALv3, with nobody ever expecting anything on pre-OPALv3 to
be cared about or supported by mainline kernels.
So, let's remove FW_FEATURE_OPALv3 and instead use FW_FEATURE_OPAL
exclusively.
Signed-off-by: Stewart Smith
---
Everything that ever made it out of the lab is OPALv3.
The number of machines in the lab even that are OPAL pre v3 is so
likely to be zero it's not funny, and the number of people expecting
to run mainline kernels on OPAL pre v3 is even lower than that.
So, this patch series removes things refere
OPALv2 only ever existed in the lab and didn't escape to the world.
All OPAL systems in the wild are OPALv3.
The probability of there being an OPALv2 system still powered on
anywhere inside IBM is approximately zero, let alone anyone
expecting to run mainline kernels.
So, start to remove referenc
35 matches
Mail list logo
