On 18/04/18 11:08, Alastair D'Silva wrote:
From: Alastair D'Silva
In order to successfully issue as_notify, an AFU needs to know the TID
to notify, which in turn means that this information should be
available in userspace so it can be communicated to the AFU.
Signed-off-by: Alastair D'Silva
On Tue, Apr 17, 2018 at 04:33:15PM +0200, Laurent Dufour wrote:
> The VMA sequence count has been introduced to allow fast detection of
> VMA modification when running a page fault handler without holding
> the mmap_sem.
>
> This patch provides protection against the VMA modification done in :
>
On Tue, Apr 17, 2018 at 04:33:18PM +0200, Laurent Dufour wrote:
> When handling speculative page fault, the vma->vm_flags and
> vma->vm_page_prot fields are read once the page table lock is released. So
> there is no more guarantee that these fields would not change in our back.
> They will be save
In order to use the rtc_tm_to_time64() and rtc_time64_to_tm()
helper functions in later patches, we have to ensure that
CONFIG_RTC_LIB is always built-in.
Note that this symbol only controls a couple of helper functions,
not the actual RTC subsystem, which remains optional and is
enabled with CONF
Looking through the remaining users of the deprecated mktime()
function, I found the powerpc rtc handlers, which use it in
place of rtc_tm_to_time64().
To clean this up, I'm changing over the read_persistent_clock()
function to the read_persistent_clock64() variant, and change
all the platform spe
update_persistent_clock() is deprecated because it suffers from overflow
in 2038 on 32-bit architectures. This changes powerpc to use the
update_persistent_clock64() replacement, and to pass down 64-bit
timestamps consistently.
This is now simpler, as we no longer have to worry about the offset
nu
to_tm() is now completely unused, the only reference being in the
_dump_time() helper that is also unused. This removes both, leaving
the rest of the powerpc RTC code y2038 safe to as far as the hardware
supports.
Signed-off-by: Arnd Bergmann
---
arch/powerpc/include/asm/time.h | 2 --
arch/p
The to_tm() helper function operates on a signed integer for the time,
so it will suffer from overflow in 2038, even on 64-bit kernels.
Rather than fix that function, this replaces its use in the rtas
procfs implementation with the standard rtc_time64_to_tm() helper
that is very similar but is not
On Mon, Apr 23, 2018 at 10:10 AM, Arnd Bergmann wrote:
> @@ -170,7 +170,6 @@ unsigned long __init maple_get_boot_time(void)
> request_resource(&ioport_resource, &rtc_iores);
>
> maple_get_rtc_time(&tm);
> - return mktime(tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
> -
On Mon, Apr 23, 2018 at 10:10 AM, Arnd Bergmann wrote:
> @@ -307,17 +307,17 @@ static ssize_t ppc_rtas_poweron_write(struct file *file,
> const char __user *buf, size_t count, loff_t *ppos)
> {
> struct rtc_time tm;
> - unsigned long nowtime;
> + time64_t nowt
update_persistent_clock() is deprecated because it suffers from overflow
in 2038 on 32-bit architectures. This changes powerpc to use the
update_persistent_clock64() replacement, and to pass down 64-bit
timestamps consistently.
This is now simpler, as we no longer have to worry about the offset
nu
The to_tm() helper function operates on a signed integer for the time,
so it will suffer from overflow in 2038, even on 64-bit kernels.
Rather than fix that function, this replaces its use in the rtas
procfs implementation with the standard rtc_time64_to_tm() helper
that is very similar but is not
Looking through the remaining users of the deprecated mktime()
function, I found the powerpc rtc handlers, which use it in
place of rtc_tm_to_time64().
To clean this up, I'm changing over the read_persistent_clock()
function to the read_persistent_clock64() variant, and change
all the platform spe
In order to use the rtc_tm_to_time64() and rtc_time64_to_tm()
helper functions in later patches, we have to ensure that
CONFIG_RTC_LIB is always built-in.
Note that this symbol only controls a couple of helper functions,
not the actual RTC subsystem, which remains optional and is
enabled with CONF
to_tm() is now completely unused, the only reference being in the
_dump_time() helper that is also unused. This removes both, leaving
the rest of the powerpc RTC code y2038 safe to as far as the hardware
supports.
Signed-off-by: Arnd Bergmann
---
arch/powerpc/include/asm/time.h | 2 --
arch/p
On Mon, Apr 23, 2018 at 4:51 PM, Balbir Singh wrote:
> On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar
> wrote:
>> From: Mahesh Salgaonkar
>>
>> The current code extracts the physical address for UE errors and then
>> hooks it up into memory failure infrastructure. On successful extraction
On 04/16/2018 06:09 AM, David Gibson wrote:
> On Thu, Apr 12, 2018 at 05:02:06PM +1000, Sam Bobroff wrote:
>> It is not currently possible to create the full number of possible
>> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
>> threads per core than it's core stride (or "VSM
On 04/23/2018 12:21 PM, Balbir Singh wrote:
> On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar
> wrote:
>> From: Mahesh Salgaonkar
>>
>> The current code extracts the physical address for UE errors and then
>> hooks it up into memory failure infrastructure. On successful extraction
>> of phys
Christophe,
On Sat, Apr 21, 2018 at 9:16 AM, christophe leroy
wrote:
>
>
> Le 20/04/2018 à 22:08, Mathieu Malaterre a écrit :
>>
>> On Fri, Apr 20, 2018 at 12:41 PM, Nicholas Piggin
>> wrote:
>>>
>>> On Fri, 20 Apr 2018 12:00:49 +0200
>>> Mathieu Malaterre wrote:
>>>
On Fri, Apr 20, 2018 a
On Mon, Apr 23, 2018 at 8:33 PM, Mahesh Jagannath Salgaonkar
wrote:
> On 04/23/2018 12:21 PM, Balbir Singh wrote:
>> On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar
>> wrote:
>>> From: Mahesh Salgaonkar
>>>
>>> The current code extracts the physical address for UE errors and then
>>> hooks
On Friday 20 April 2018 10:34 AM, Mahesh J Salgaonkar wrote:
From: Mahesh Salgaonkar
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
signi
On Mon, 23 Apr 2018 21:14:12 +1000
Balbir Singh wrote:
> On Mon, Apr 23, 2018 at 8:33 PM, Mahesh Jagannath Salgaonkar
> wrote:
> > On 04/23/2018 12:21 PM, Balbir Singh wrote:
> >> On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar
> >> wrote:
> >>> From: Mahesh Salgaonkar
> >>>
> >>> The
On 04/23/2018 04:44 PM, Balbir Singh wrote:
> On Mon, Apr 23, 2018 at 8:33 PM, Mahesh Jagannath Salgaonkar
> wrote:
>> On 04/23/2018 12:21 PM, Balbir Singh wrote:
>>> On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar
>>> wrote:
From: Mahesh Salgaonkar
The current code extracts
Steven Royer had previously attempted to upstream this
driver two years ago, but never got the chance to address
the concerns from Greg Kroah-Hartman.
The thread with the initial upstream is:
https://lkml.org/lkml/2016/2/16/918
I have addressed the following:
- Documentation
- Use of dev_dbg inst
This driver is a logical device which provides an
interface between the hypervisor and a management
partition.
This driver is to be used for the POWER Virtual
Management Channel Virtual Adapter on the PowerVM
platform. It provides both request/response and
async message support through the /dev/ib
On 23/04/2018 07:58, Minchan Kim wrote:
> Hi Laurent,
>
> I guess it's good timing to review. Guess LSF/MM goes so might change
> a lot since then. :) Anyway, I grap a time to review.
Hi,
Thanks a lot for reviewing this series.
> On Tue, Apr 17, 2018 at 04:33:07PM +0200, Laurent Dufour wrote:
>
On 04/23/18 07:46, Bryant G. Ly wrote:
> This driver is a logical device which provides an
> interface between the hypervisor and a management
> partition.
>
> This driver is to be used for the POWER Virtual
> Management Channel Virtual Adapter on the PowerVM
> platform. It provides both request/r
On Sun, Apr 8, 2018 at 10:34 PM, Randy Dunlap wrote:
> On 04/08/2018 12:44 PM, Mathieu Malaterre wrote:
>> In commit 7a22d6321c3d ("powerpc/mm/radix: Update command line parsing for
>> disable_radix") an `if` statement was added for a possible empty body
>> (prom_debug).
>>
>> Fix the following wa
On Mon, Apr 23, 2018 at 9:31 PM, Mathieu Malaterre wrote:
> On Sun, Apr 8, 2018 at 10:34 PM, Randy Dunlap wrote:
>> On 04/08/2018 12:44 PM, Mathieu Malaterre wrote:
>>> In commit 7a22d6321c3d ("powerpc/mm/radix: Update command line parsing for
>>> disable_radix") an `if` statement was added for a
In commit 7a22d6321c3d ("powerpc/mm/radix: Update command line parsing for
disable_radix") an `if` statement was added for a possible empty body
(prom_debug).
Fix the following warning, treated as error with W=1:
arch/powerpc/kernel/prom_init.c:656:46: error: suggest braces around empty
body i
The function hlwd_pic_init can be made static, so do it. Fix the following
warning treated as error (W=1):
../arch/powerpc/platforms/embedded6xx/hlwd-pic.c:158:20: error: no previous
prototype for ‘hlwd_pic_init’ [-Werror=missing-prototypes]
Signed-off-by: Mathieu Malaterre
---
arch/powerpc/pl
On Mon, Apr 23, 2018 at 11:38:18AM -0700, Randy Dunlap wrote:
> On 04/23/18 07:46, Bryant G. Ly wrote:
> > This driver is a logical device which provides an
> > interface between the hypervisor and a management
> > partition.
> >
> > This driver is to be used for the POWER Virtual
> > Management C
On 4/23/18 2:53 PM, Greg KH wrote:
> On Mon, Apr 23, 2018 at 11:38:18AM -0700, Randy Dunlap wrote:
>> On 04/23/18 07:46, Bryant G. Ly wrote:
>>> This driver is a logical device which provides an
>>> interface between the hypervisor and a management
>>> partition.
>>>
>>> This driver is to be used
On 04/23/18 12:36, Mathieu Malaterre wrote:
> In commit 7a22d6321c3d ("powerpc/mm/radix: Update command line parsing for
> disable_radix") an `if` statement was added for a possible empty body
> (prom_debug).
>
> Fix the following warning, treated as error with W=1:
>
> arch/powerpc/kernel/prom
On 04/23/18 12:53, Greg KH wrote:
> On Mon, Apr 23, 2018 at 11:38:18AM -0700, Randy Dunlap wrote:
>> On 04/23/18 07:46, Bryant G. Ly wrote:
>>> This driver is a logical device which provides an
>>> interface between the hypervisor and a management
>>> partition.
>>>
>>> This driver is to be used fo
On Mon, 2018-04-23 at 23:01 +1000, Nicholas Piggin wrote:
> On Mon, 23 Apr 2018 21:14:12 +1000
> Balbir Singh wrote:
>
> > On Mon, Apr 23, 2018 at 8:33 PM, Mahesh Jagannath Salgaonkar
> > wrote:
> > > On 04/23/2018 12:21 PM, Balbir Singh wrote:
> > > > On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J
On Mon, 2018-04-23 at 10:29 +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> The current code extracts the physical address for UE errors and then
> hooks it up into memory failure infrastructure. On successful extraction
> of physical address it wrongly sets "handled = 1" which me
On Mon, Apr 23, 2018 at 11:06:35AM +0200, Cédric Le Goater wrote:
> On 04/16/2018 06:09 AM, David Gibson wrote:
> > On Thu, Apr 12, 2018 at 05:02:06PM +1000, Sam Bobroff wrote:
> >> It is not currently possible to create the full number of possible
> >> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV w
On Fri, 2018-04-06 at 05:24:23 UTC, Balbir Singh wrote:
> This patch adds support for flushing potentially dirty
> cache lines when memory is hot-plugged/hot-un-plugged.
> The support is currently limited to 64 bit systems.
>
> The bug was exposed when mappings for a device were
> actually hot-unp
On Wed, 2018-04-11 at 06:38:54 UTC, Alistair Popple wrote:
> The pnv_npu2_init_context() and pnv_npu2_destroy_context() functions are
> used to allocate/free contexts to allow address translation and shootdown
> by the NPU on a particular GPU. Context initialisation is implicitly safe
> as it is pr
On Tue, 2018-04-17 at 09:11:28 UTC, Alistair Popple wrote:
> The NPU has a limited number of address translation shootdown (ATSD)
> registers and the GPU has limited bandwidth to process ATSDs. This can
> result in contention of ATSD registers leading to soft lockups on some
> threads, particularly
On Tue, Apr 24, 2018 at 01:19:15PM +1000, Sam Bobroff wrote:
> On Mon, Apr 23, 2018 at 11:06:35AM +0200, Cédric Le Goater wrote:
> > On 04/16/2018 06:09 AM, David Gibson wrote:
> > > On Thu, Apr 12, 2018 at 05:02:06PM +1000, Sam Bobroff wrote:
> > >> It is not currently possible to create the full
From: Michal Suchanek
A no-op form of ori (or immediate of 0 into r31 and the result stored
in r31) has been re-tasked as a speculation barrier. The instruction
only acts as a barrier on newer machines with appropriate firmware
support. On older CPUs it remains a harmless no-op.
Implement barrie
From: Michal Suchanek
Based on the RFI patching. This is required to be able to disable the
speculation barrier.
Only one barrier type is supported and it does nothing when the
firmware does not enable it. Also re-patching modules is not supported
So the only meaningful thing that can be done is
From: Michal Suchanek
Note that unlike RFI which is patched only in kernel the nospec state
reflects settings at the time the module was loaded.
Iterating all modules and re-patching every time the settings change
is not implemented.
Based on lwsync patching.
Signed-off-by: Michal Suchanek
Si
From: Michal Suchanek
Check what firmware told us and enable/disable the barrier_nospec as
appropriate.
We err on the side of enabling the barrier, as it's no-op on older
systems, see the comment for more detail.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/setup.h | 1
Based on the x86 commit doing the same.
See commit 304ec1b05031 ("x86/uaccess: Use __uaccess_begin_nospec()
and uaccess_try_nospec") and b3bbfb3fb5d2 ("x86: Introduce
__uaccess_begin_nospec() and uaccess_try_nospec") for more detail.
In all cases we are ordering the load from the potentially
user
Our syscall entry is done in assembly so patch in an explicit
barrier_nospec.
Based on a patch by Michal Suchanek.
Signed-off-by: Michal Suchanek
Signed-off-by: Michael Ellerman
---
mpe: Move the barrier to immediately prior to the vulnerable load,
and add a comment trying to explain why.
gpstate_timer_handler() uses synchronous smp_call to set the pstate
on the requested core. This causes the below hard lockup:
[c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180
(unreliable)
[c03fe566b390] [c01d55e0] smp_call_function_any+0x180/0x250
[c03fe5
Shilpasri G Bhat writes:
> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> on the requested core. This causes the below hard lockup:
>
> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180
> (unreliable)
> [c03fe566b390] [c01d55e0] smp_call
Hi,
On 04/24/2018 10:40 AM, Stewart Smith wrote:
> Shilpasri G Bhat writes:
>> gpstate_timer_handler() uses synchronous smp_call to set the pstate
>> on the requested core. This causes the below hard lockup:
>>
>> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180
>> (unr
Hi Arnd,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.17-rc2 next-20180423]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
On Tue, 24 Apr 2018 14:15:54 +1000
Michael Ellerman wrote:
> From: Michal Suchanek
>
> A no-op form of ori (or immediate of 0 into r31 and the result stored
> in r31) has been re-tasked as a speculation barrier. The instruction
> only acts as a barrier on newer machines with appropriate firmwar
On Tue, 24 Apr 2018 10:11:46 +0530
Shilpasri G Bhat wrote:
> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> on the requested core. This causes the below hard lockup:
>
> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180
> (unreliable)
> [c03fe
54 matches
Mail list logo
