Le 07/11/2017 à 23:56, Guenter Roeck a écrit :
On Tue, Nov 07, 2017 at 05:23:56PM +0100, Christophe Leroy wrote:
The watchdog core includes a worker function which pings the
watchdog until user app starts pinging it and which also
pings it if the HW require more frequent pings.
Use that functio
On 11/08/2017 07:08 AM, Michael Ellerman wrote:
"Kirill A. Shutemov" writes:
On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote:
On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote:
On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote:
On 11/07/2017 12:15 PM, Kirill A. Sh
"Kirill A. Shutemov" writes:
> On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote:
>> On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote:
>> > On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote:
>> > > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote:
>> > >
>> > > > > Firs
"Aneesh Kumar K.V" writes:
>>
>> If it is decided to keep these kind of heuristics, can we get just a
>> small but reasonably precise description of each change to the
>> interface and ways for using the new functionality, such that would be
>> suitable for the man page? I couldn't fix powerpc b
Add support for user space receive window (for the Fast thread-wakeup
coprocessor type)
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v3]
- [Nick Piggin] Drop CP_ABORT since set_thread_uses_vas() does
that now (in earlier patch) and add a check for return value.
---
arch/pow
Define an interface that the NX drivers can use to find the physical
paste address of a send window. This interface is expected to be used
with the mmap() operation of the NX driver's device. i.e the user space
process can use driver's mmap() operation to map the send window's paste
address into th
Define an interface to return a system-wide unique id for a given VAS
window.
The vas_win_id() will be used in a follow-on patch to generate an unique
handle for a user space receive window. Applications can use this handle
to pair send and receive windows for fast thread-wakeup.
The hardware ref
From: Michael Neuling
On POWER9 DD2.1 and below there are issues when the paste instruction
generates an error. If an error occurs when thread reconfiguration
happens (ie another thread in the core goes into/out of powersave) the
core may hang.
To avoid this a special sequence is required which
A CP_ABORT instruction is required in processes that have mapped a VAS
"paste address" with the intention of using COPY/PASTE instructions.
But since CP_ABORT is expensive, we want to restrict it to only processes
that use/intend to use COPY/PASTE.
Define an interface, set_thread_uses_vas(), that
We need the SPRN_TIDR to be set for use with fast thread-wakeup (core-
to-core wakeup) and also with CAPI.
Each thread in a process needs to have a unique id within the process.
But as explained below, for now, we assign globally unique thread ids
to all threads in the system.
Signed-off-by: Suka
Have the COPY/PASTE instructions depend on CONFIG_BOOK3S_64 rather than
CONFIG_PPC_STD_MMU_64.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/kernel/process.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process
Export the VAS Window context information to debugfs.
We need to hold a mutex when closing the window to prevent a race
with the debugfs read(). Rather than introduce a per-instance mutex,
we use the global vas_mutex for now, since it is not heavily contended.
The window->cop field is only releva
Define a helper, chip_to_vas_id() to map a given chip id to corresponding
vas id.
Normally, callers of vas_rx_win_open() and vas_tx_win_open() want the VAS
window to be on the same chip where the calling thread is executing. These
callers can pass in -1 for the VAS id.
This interface will be usef
Create a cpu to vasid mapping so callers can specify -1 instead of
trying to find a VAS id.
Changelog[v2]
[Michael Ellerman] Use per-cpu variables to simplify code.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas.c | 14 +-
1 file changed, 13 insert
Normally, the NX driver waits for the CRBs to be processed before closing
the window. But it is better to ensure that the credits are returned before
the window gets reassigned later.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-window.c | 45
Save the configured max window credits for a window in the vas_window
structure. We will need this when polling for return of window credits.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-window.c | 6 --
arch/powerpc/platforms/powernv/vas.h| 1 +
2 files
A VAS window is normally in "busy" state for only a short duration.
Reduce the time we wait for the window to go to "not-busy" state to
speed-up vas_win_close() a bit.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-window.c | 10 ++
1 file changed, 6 insertions
Polling for window cast out is listed in the spec, but turns out that
it is not strictly necessary and slows down window close. Making it a
stub for now.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-window.c | 34 ++---
1 file changed, 17 inse
Use a helper to have the hardware unpin and mark a window closed.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-window.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/vas-window.c
b/arch/pow
Clean up vas.h and the debug code around ifdef vas_debug.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v3]
- Minor tweak to a debug message
---
arch/powerpc/platforms/powernv/vas-window.c | 8 +++--
arch/powerpc/platforms/powernv/vas.h| 54 ++---
2 f
NX-842, the only user of VAS, sets the window credits to default values
but VAS should check the credits against the possible max values.
The VAS_WCREDS_MIN is not needed and can be dropped.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-window.c | 6 ++
arch/powe
Initialize a few missing window context fields from the window attributes
specified by the caller. These fields are currently set to their default
values by the caller (NX-842), but would be good to apply them anyway.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-wind
The first 10 patches in this set sanitize cpu/chip id to VAS id mapping,
improve vas_win_close() performance, add a check for return of credits
and cleans up some code.
Patch 11 adds debugfs support for the VAS window contexts.
Patches 12-18 add support for user space aka Fast thread-wakeup windo
On Tue, Nov 07, 2017 at 02:47:10PM -0800, Dave Hansen wrote:
> On 11/07/2017 02:39 PM, Ram Pai wrote:
> >
> > As per the current semantics of sys_pkey_free(); the way I understand it,
> > the calling thread is saying disassociate me from this key.
>
> No. It is saying: "this *process* no longer
On Sun, 2017-11-05 at 12:33:55 UTC, Nicholas Piggin wrote:
> If the host takes a system reset interrupt while a guest is running,
> the CPU must exit the guest before processing the host exception
> handler.
>
> After this patch, taking a sysrq+x with a CPU running in a guest
> gives a trace like
On Sat, 2017-11-04 at 21:26:52 UTC, Arnd Bergmann wrote:
> This interface is inefficient and deprecated because of the y2038
> overflow.
>
> ktime_get_seconds() is an appropriate replacement here, since it
> has sufficient granularity but is more efficient and uses monotonic
> time.
>
> Signed-of
On Fri, 2017-11-03 at 04:13:19 UTC, Nicholas Piggin wrote:
> Cc: Michael Neuling
> Signed-off-by: Nicholas Piggin
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b6b3755e9bec9c686a34ec81eacced
cheers
On Tue, 2017-10-24 at 15:48:49 UTC, Michael Ellerman wrote:
> Currently if the hardware supports the radix MMU we will use
> it, *unless* "disable_radix" is passed on the kernel command line.
>
> However some users would like the reverse semantics. ie. The kernel
> uses the hash MMU by default, un
On Fri, 2017-11-03 at 02:41:37 UTC, Cyril Bur wrote:
> BUG_ON() should be reserved in situations where we can not longer
> guarantee the integrity of the system. In the case where
> powernv_flash_async_op() receives an impossible op, we can still
> guarantee the integrity of the system.
>
> Signed
On Thu, 2017-11-02 at 03:09:03 UTC, Cyril Bur wrote:
> Lazy save and restore of FP/Altivec means that a userspace process can
> be sent to userspace with FP or Altivec disabled and loaded only as
> required (by way of an FP/Altivec unavailable exception). Transactional
> Memory complicates this sit
On Tue, 2017-10-24 at 13:06:54 UTC, Nicholas Piggin wrote:
> According to the architecture, the process table entry cache must be
> flushed with tlbie RIC=2.
>
> Currently the process table entry is set to invalid right before the
> PID is returned to the allocator, with no invalidation. This work
On Thu, 2017-10-19 at 04:08:43 UTC, Michael Ellerman wrote:
> CONFIG_PPC_STD_MMU_64 indicates support for the "standard" powerpc MMU
> on 64-bit CPUs. The "standard" MMU refers to the hash page table MMU
> found in "server" processors, from IBM mainly.
>
> Currently CONFIG_PPC_STD_MMU_64 is == CON
On Tue, 2017-10-24 at 13:06:53 UTC, Nicholas Piggin wrote:
> Preempt should be consistently disabled for mm_is_thread_local tests,
> so bring the rest of these under preempt_disable().
>
> Preempt does not need to be disabled for the mm->context.id tests,
> which allows simplification and removal
On Sat, 2017-10-21 at 07:56:06 UTC, Nicholas Piggin wrote:
> When returning from an exception to a soft-enabled context, pending
> IRQs are replayed but IRQ tracing is not reset, so a number of them
> can get chained together into the same IRQ-disabled trace.
>
> Fix this by having __check_irq_rep
On Mon, 2017-10-23 at 07:08:13 UTC, Nicholas Piggin wrote:
> Signed-off-by: Nicholas Piggin
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f848ea7f5960ec2684c3bd1c0692e6
cheers
On Thu, 2017-10-19 at 04:08:19 UTC, Michael Ellerman wrote:
> The last user of CPU_FTR_ICSWX was removed in commit
> 6ff4d3e96652 ("powerpc: Remove old unused icswx based coprocessor
> support"), so free the bit up for future use.
>
> Signed-off-by: Michael Ellerman
Applied to powerpc next.
htt
On Wed, 2017-10-18 at 09:16:47 UTC, Christophe Leroy wrote:
> IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
> which is the mask register.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6b148a7ce72a7f87c81cbcde48af01
On Thu, 2017-10-12 at 04:45:25 UTC, Michael Ellerman wrote:
> Currently when we take a TM Bad Thing program check exception, we
> search the bug table to see if the program check was generated by a
> WARN/WARN_ON etc.
>
> That makes no sense, the WARN macros use trap instructions, which
> should n
On Mon, 2017-10-16 at 07:01:40 UTC, "Aneesh Kumar K.V" wrote:
> Make the printks look a bit nicer by adding a prefix.
>
> Radix config now do
> radix-mmu: Page sizes from device-tree:
> radix-mmu: Page size shift = 12 AP=0x0
> radix-mmu: Page size shift = 16 AP=0x5
> radix-mmu: Page size shift
On Wed, 2017-10-11 at 12:30:20 UTC, Vaibhav Jain wrote:
> Presently the PSL9 specific cxl_stop_trace_psl9() only stops the RX0
> traces on the CXL adapter when a PSL error irq is triggered. The patch
> updates the function to stop all the traces arrays and move them to
> the FIN state. The implemen
On Fri, 2017-09-29 at 00:19:20 UTC, Tyrel Datwyler wrote:
> When a vdevice is DLPAR removed from the system the vio subsystem doesn't
> bother unmapping the virq from the irq_domain. As a result we have a virq
> mapped to a hardware irq that is no longer valid for the irq_domain. A side
> effect is
On Wed, 2017-09-27 at 06:52:31 UTC, Alexey Kardashevskiy wrote:
> In order to make generic IOV code work, the physical function IOV BAR
> should start from offset of the first VF. Since M64 segments share
> PE number space across PHB, and some PEs may be in use at the time
> when IOV is enabled, th
On Fri, 2017-09-22 at 23:58:00 UTC, "William A. Kennington III" wrote:
> The current code checks the completion map to look for the first token
> that is complete. In some cases, a completion can come in but the token
> can still be on lease to the caller processing the completion. If this
> comple
On Fri, 2017-09-01 at 18:53:01 UTC, Sandipan Das wrote:
> Take advantage of stack_depth tracking, originally introduced for
> x64, in powerpc JIT as well. Round up allocated stack by 16 bytes
> to make sure it stays aligned for functions called from JITed bpf
> program.
>
> Signed-off-by: Sandipan
On Tue, Nov 07, 2017 at 05:23:56PM +0100, Christophe Leroy wrote:
> The watchdog core includes a worker function which pings the
> watchdog until user app starts pinging it and which also
> pings it if the HW require more frequent pings.
> Use that function instead of the dedicated timer.
> In the
On 11/07/2017 02:39 PM, Ram Pai wrote:
>
> As per the current semantics of sys_pkey_free(); the way I understand it,
> the calling thread is saying disassociate me from this key.
No. It is saying: "this *process* no longer has any uses of this key,
it can be reused".
On Tue, Nov 07, 2017 at 08:32:16AM +0100, Florian Weimer wrote:
> * Ram Pai:
>
> > On Mon, Nov 06, 2017 at 10:28:41PM +0100, Florian Weimer wrote:
> >> * Ram Pai:
> >>
> >> > Testing:
> >> > ---
> >> > This patch series has passed all the protection key
> >> > tests available in the selftest
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/powerpc/mm/tlb-radix.c
between commit:
26e53d5ebe2e ("powerpc/64s/radix: Fix preempt imbalance in TLB flush")
from Linus' tree and commit:
dffe8449c5dd ("powerpc/64s/radix: Improve preempt handling in TLB code"
The watchdog core includes a worker function which pings the
watchdog until user app starts pinging it and which also
pings it if the HW require more frequent pings.
Use that function instead of the dedicated timer.
In the mean time, we can allow the user to change the timeout.
Then change the tim
On Tue, Nov 07, 2017 at 12:31:05PM +0100, Torsten Duwe wrote:
> On Tue, Nov 07, 2017 at 07:34:29PM +1100, Michael Ellerman wrote:
> > > So, just brainstorming a bit, here are the possible solutions I can
> > > think of:
> > >
> > > a) Create a special klp stub for such calls (as in Kamalesh's patch
Dan's static analysis says:
drivers/video/fbdev/controlfb.c:560 control_setup()
error: buffer overflow 'control_mac_modes' 20 <= 21
Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22,
which may lead to an out of bounds read when parsing vmode commandline
options.
The
On Tue, Nov 07, 2017 at 07:15:58PM +0530, Aneesh Kumar K.V wrote:
>
> >
> > If it is decided to keep these kind of heuristics, can we get just a
> > small but reasonably precise description of each change to the
> > interface and ways for using the new functionality, such that would be
> > suitab
If it is decided to keep these kind of heuristics, can we get just a
small but reasonably precise description of each change to the
interface and ways for using the new functionality, such that would be
suitable for the man page? I couldn't fix powerpc because nothing
matches and even Aneesh an
On Tue, 7 Nov 2017 15:28:25 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Nov 07, 2017 at 10:56:36PM +1100, Nicholas Piggin wrote:
> > > No, it won't. You will hit stack first.
> >
> > I guess so. Florian's bug didn't crash there for some reason, okay
> > but I suppose my point about brk is not
On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote:
> On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote:
> > On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote:
> > > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote:
> > >
> > > > > First of all, using addr and MAP_FIXED to
On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote:
On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote:
On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote:
First of all, using addr and MAP_FIXED to develop our heuristic can
never really give unchanged ABI. It's an in-band signal. brk()
On Tue, 2017-10-31 at 20:40 +0200, Andy Shevchenko wrote:
> On Tue, 2017-10-31 at 13:33 -0500, Bjorn Helgaas wrote:
> > On Tue, Oct 31, 2017 at 10:12 AM, Andy Shevchenko
> > wrote:
> > > On Fri, 2017-10-13 at 19:52 +0300, Andy Shevchenko wrote:
> > > > ...which makes code slightly cleaner.
> > >
On Tue, Nov 07, 2017 at 10:56:36PM +1100, Nicholas Piggin wrote:
> > No, it won't. You will hit stack first.
>
> I guess so. Florian's bug didn't crash there for some reason, okay
> but I suppose my point about brk is not exactly where the standard
> heap is, but the pattern of allocations. An all
Sukadev Bhattiprolu writes:
> diff --git a/arch/powerpc/platforms/powernv/vas-window.c
> b/arch/powerpc/platforms/powernv/vas-window.c
> index 23c13a7..088ce56 100644
> --- a/arch/powerpc/platforms/powernv/vas-window.c
> +++ b/arch/powerpc/platforms/powernv/vas-window.c
> @@ -145,24 +145,42 @@ s
Hi mpe,
On Wednesday 01 November 2017 06:20 AM, Michael Ellerman wrote:
Anju T Sudhakar writes:
Add ldbar spr to sysfs. The spr will hold thread level In-Memory Collection
(IMC)
counter configuration data.
This is missing any justification for why we would want to expose this,
and in parti
On Tue, 7 Nov 2017 14:15:43 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Nov 07, 2017 at 04:07:05PM +1100, Nicholas Piggin wrote:
> > C'ing everyone who was on the x86 56-bit user virtual address patch.
> >
> > I think we need more time to discuss this behaviour, in light of the
> > regression Fl
On Tue 07-11-17 11:28:54, Michal Hocko wrote:
> On Tue 07-11-17 15:20:29, Abdul Haleem wrote:
> > Hi,
> >
> > Today's next kernel fails to boot on Power 7 Machine with below errors
> > in boot log messages.
> >
> > 'Uhuuh, elf segement at 1004 requested but the memory is
> > mapped al
On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote:
> On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote:
>
> > > First of all, using addr and MAP_FIXED to develop our heuristic can
> > > never really give unchanged ABI. It's an in-band signal. brk() is a
> > > good example that steadily
On Tue, Nov 07, 2017 at 07:34:29PM +1100, Michael Ellerman wrote:
> Josh Poimboeuf writes:
>
> > On Tue, Oct 31, 2017 at 07:39:59PM +0100, Torsten Duwe wrote:
> >> On Tue, Oct 31, 2017 at 09:53:16PM +0530, Naveen N . Rao wrote:
> >> > On 2017/10/31 03:30PM, Torsten Duwe wrote:
> >> > >
> >> > >
On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote:
First of all, using addr and MAP_FIXED to develop our heuristic can
never really give unchanged ABI. It's an in-band signal. brk() is a
good example that steadily keeps incrementing address, so depending
on malloc usage and address space randomiz
On Tue, Nov 07, 2017 at 09:15:21AM +0100, Florian Weimer wrote:
> MAP_FIXED is near-impossible to use correctly. I hope you don't expect
> applications to do that. If you want address-based opt in, it should work
> without MAP_FIXED. Sure, in obscure cases, applications might still see
> out-of-
On Tue, Nov 07, 2017 at 04:07:05PM +1100, Nicholas Piggin wrote:
> C'ing everyone who was on the x86 56-bit user virtual address patch.
>
> I think we need more time to discuss this behaviour, in light of the
> regression Florian uncovered. I would propose we turn off the 56-bit
> user virtual add
On Tue 07-11-17 15:20:29, Abdul Haleem wrote:
> Hi,
>
> Today's next kernel fails to boot on Power 7 Machine with below errors
> in boot log messages.
>
> 'Uhuuh, elf segement at 1004 requested but the memory is
> mapped already'
>
> It was introduced with commit:
>
> 0692229e : fs/
On Tue, 7 Nov 2017 09:15:21 +0100
Florian Weimer wrote:
> On 11/07/2017 06:07 AM, Nicholas Piggin wrote:
>
> > First of all, using addr and MAP_FIXED to develop our heuristic can
> > never really give unchanged ABI. It's an in-band signal. brk() is a
> > good example that steadily keeps incremen
Josh Poimboeuf writes:
> On Tue, Oct 31, 2017 at 07:39:59PM +0100, Torsten Duwe wrote:
>> On Tue, Oct 31, 2017 at 09:53:16PM +0530, Naveen N . Rao wrote:
>> > On 2017/10/31 03:30PM, Torsten Duwe wrote:
>> > >
>> > > Maybe I failed to express my views properly; I find the whole approach
>> [...]
On 11/07/2017 06:07 AM, Nicholas Piggin wrote:
First of all, using addr and MAP_FIXED to develop our heuristic can
never really give unchanged ABI. It's an in-band signal. brk() is a
good example that steadily keeps incrementing address, so depending
on malloc usage and address space randomizati
Unmaps that free page tables always flush the entire PID, which is
sub-optimal. Provide TLB range flushing with an additional PWC flush
that can be use for va range invalidations with PWC flush.
Time to munmap N pages of memory including last level page table
teardown (after mmap, touch)
The single page flush ceiling is the cut-off point at which we switch
from invalidating individual pages, to invalidating the entire process
address space in response to a range flush.
Introduce a local variant of this heuristic because local and global
tlbie have significantly different propertie
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page s
Move the barriers and range iteration down into the _tlbie* level,
which improves readability.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/tlb-radix.c | 71 ++---
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/mm/tlb-ra
Short range flushes issue a sequences of tlbie(l) instructions for
individual effective addresses. These do not all require individual
barrier sequences, only one covering all tlbie(l) instructions.
Commit f7327e0ba3 ("powerpc/mm/radix: Remove unnecessary ptesync")
made a similar optimization for
76 matches
Mail list logo
