This function allocates IRQ on a specific chip. VAS needs per chip
IRQ allocation and will have IRQ handler per VAS instance.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/xive.h | 9 -
arch/powerpc/sysdev/xive/native.c | 6 +++---
2 files changed, 11 insertions(+), 4 dele
pnv_ocxl_alloc_xive_irq() in ocxl.c allocates IRQ and gets trigger port
address. VAS also needs this function, but based on chip ID. So moved
this common function to xive/native.c.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/xive.h | 2 ++
arch/powerpc/platforms/powernv/ocx
Kernel sets fault address and status in CRB for NX page fault on user
space address after processing page fault. User space gets the signal
and handles the fault mentioned in CRB by bringing the page in to
memory and send NX request again.
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Haren
Alloc IRQ and get trigger port address for each VAS instance. Kernel
register this IRQ per VAS instance and sets this port for each send
window. NX interrupts the kernel when it sees page fault.
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas.c | 34 +
Setup fault window for each VAS instance. When NX gets fault on request
buffer, write fault CRBs in the corresponding fault FIFO and then sends
an interrupt to the OS.
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/
Setup thread IRQ handler per each VAS instance. When NX sees a fault
on CRB, kernel gets an interrupt and vas_fault_handler will be
executed to process fault CRBs. Read all valid CRBs from fault FIFO,
determine the corresponding send window from CRB and process fault
requests.
Signed-off-by: Suk
For each user space send window, register NX with fault window ID
and port value so that NX paste CRBs in this fault FIFO when it
sees fault on the request buffer.
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas-window.c | 15 +
Process close windows after its requests are completed. In multi-thread
applications, child can open a window but release FD will not be called
upon its exit. Parent thread will be closing it later upon its exit.
The parent can also send NX requests with this window and NX can
generate page faul
For each fault CRB, update fault address in CRB (fault_storage_addr)
and translation error status in CSB so that user space can touch the
fault address and resend the request. If the user space passed invalid
CSB address send signal to process with SIGSEGV.
Signed-off-by: Sukadev Bhattiprolu
Si
Dump FIFO entry values if could not find send window and print CRB
for debugging.
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas-fault.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/powerpc/plat
System checkstops if RxFIFO overruns with more requests than the
maximum possible number of CRBs allowed in FIFO at any time. So
max credits value (rxattr.wcreds_max) is set and is passed to
vas_rx_win_open() by the the driver.
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas
NX expects OS to return credit for send window after processing each
fault. Also credit has to be returned even for fault window.
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas-fault.c | 10 ++
arch/powerpc/platforms/powernv/vas-
Process can not close send window until all requests are processed.
Means wait until window state is not busy and send credits are
returned. Display debug message in case taking longer to close the
window.
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas-window.c | 27 +++
NX may be processing requests while trying to close window. Wait until
all credits are returned and then free send window from VAS instance.
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas-window.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/
>>> Really, the interface is flawed and should have never been merged in the
>>> first place. We cannot simply remove it altogether I am afraid so let's
>>> at least remove the bogus code and pretend that the world is a better
>>> place where everything is removable except the reality sucks...
>>
>
On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
> >>> Really, the interface is flawed and should have never been merged in the
> >>> first place. We cannot simply remove it altogether I am afraid so let's
> >>> at least remove the bogus code and pretend that the world is a better
> >>> place whe
On 21.01.2020 21:27, Alexey Budankov wrote:
>
> On 21.01.2020 20:55, Alexei Starovoitov wrote:
>> On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
>> wrote:
>>>
>>>
>>> On 21.01.2020 17:43, Stephen Smalley wrote:
On 1/20/20 6:23 AM, Alexey Budankov wrote:
>
> Introduce CAP_PERFMON c
On 22.01.20 11:42, Michal Hocko wrote:
> On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
> Really, the interface is flawed and should have never been merged in the
> first place. We cannot simply remove it altogether I am afraid so let's
> at least remove the bogus code and pretend t
On 1/20/20 5:00 PM, Alexey Budankov wrote:
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to
On 22.01.20 11:54, David Hildenbrand wrote:
> On 22.01.20 11:42, Michal Hocko wrote:
>> On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
>> Really, the interface is flawed and should have never been merged in the
>> first place. We cannot simply remove it altogether I am afraid so let's
>
NULL addr is a user address. Don't waste time checking it. If
someone tries to access it, it will SIGFAULT the same way as for
address 1, so no need to make it special.
The special case is when not doing a write, in that case we want
to drop the entire function. This is now handled by 'dir' param
At the moment, bad_kuap_fault() reports a fault only if a bad access
to userspace occurred while access to userspace was not granted.
But if a fault occurs for a write outside the allowed userspace
segment(s) that have been unlocked, bad_kuap_fault() fails to
detect it and the kernel loops forever
__builtin_constant_p() always return 0 for pointers, so on RADIX
we always end up opening both direction (by writing 0 in SPR29):
0170 <._copy_to_user>:
...
1b0: 4c 00 01 2c isync
1b4: 39 20 00 00 li r9,0
1b8: 7d 3d 03 a6 mtspr 29,r9
1bc: 4c 00 01 2c
Some architectures grand full access to userspace regardless of the
address/len passed to user_access_begin(), but other architectures
only grand access to the requested area.
For exemple, on 32 bits powerpc (book3s/32), access is granted by
segments of 256 Mbytes.
Modify filldir() and filldir64(
In preparation of implementing user_access_begin and friends
on powerpc, the book3s/32 version of prevent_user_access() need
to be prepared for user_access_end().
user_access_end() doesn't provide the address and size which
were passed to user_access_begin(), required by prevent_user_access()
to k
Today, when a function like strncpy_from_user() is called,
the userspace access protection is de-activated and re-activated
for every word read.
By implementing user_access_begin and friends, the protection
is de-activated at the beginning of the copy and re-activated at the
end.
Implement user_a
Hi!
On Wed, Jan 22, 2020 at 07:57:15AM +0100, Christophe Leroy wrote:
> GCC doc also says:
>
> "if you use it in an inlined function and pass an argument of the
> function as the argument to the built-in, GCC never returns 1 when you
> call the inline function with a string constant"
>
> Does
On Wed, Jan 22, 2020 at 07:52:02AM +0100, Christophe Leroy wrote:
> Le 21/01/2020 à 20:55, Segher Boessenkool a écrit :
> >On Tue, Jan 21, 2020 at 05:22:32PM +, Christophe Leroy wrote:
> >>g1() should return 3, not 5.
> >
> >What makes you say that?
>
> What makes me say that is that NULL is o
On 1/22/20 5:45 AM, Alexey Budankov wrote:
On 21.01.2020 21:27, Alexey Budankov wrote:
On 21.01.2020 20:55, Alexei Starovoitov wrote:
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
On 21.01.2020 17:43, Stephen Smalley wrote:
On 1/20/20 6:23 AM, Alexey Budankov wrote:
Introduce
On 22.01.2020 17:07, Stephen Smalley wrote:
> On 1/22/20 5:45 AM, Alexey Budankov wrote:
>>
>> On 21.01.2020 21:27, Alexey Budankov wrote:
>>>
>>> On 21.01.2020 20:55, Alexei Starovoitov wrote:
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
>
>
> On 21.01.2020 17:43
Le 22/01/2020 à 14:36, Segher Boessenkool a écrit :
On Wed, Jan 22, 2020 at 07:52:02AM +0100, Christophe Leroy wrote:
Le 21/01/2020 à 20:55, Segher Boessenkool a écrit :
On Tue, Jan 21, 2020 at 05:22:32PM +, Christophe Leroy wrote:
g1() should return 3, not 5.
What makes you say that?
On Thu, Jan 16, 2020 at 11:27:58AM +0100, Libor Pechacek wrote:
> In KVM guests drmem structure is only zero initialized. Trying to
> manipulate DLPAR parameters results in a crash in this environment.
>
> $ echo "memory add count 1" > /sys/kernel/dlpar
> Oops: Kernel access of bad area, sig: 11 [
String 'bus_desc.provider_name' allocated inside
papr_scm_nvdimm_init() will leaks in case call to
nvdimm_bus_register() fails or when papr_scm_remove() is called.
This minor patch ensures that 'bus_desc.provider_name' is freed in
error path for nvdimm_bus_register() as well as in papr_scm_remove(
Presently the error code returned via out variable 'cmd_rc' from the
nvdimm-bus controller function is ignored when called from
__nd_ioctl() and never communicated back to user-space code that called
an ioctl on dimm/bus.
This minor patch updates __nd_ioctl() to propagate the value of out
variable
On Wed, Jan 22, 2020 at 5:00 AM Christophe Leroy
wrote:
>
> Modify filldir() and filldir64() to request the real area they need
> to get access to.
Not like this.
This makes the situation for architectures like x86 much worse, since
you now use "put_user()" for the previous dirent filling. Which
On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
> On 22.01.20 11:54, David Hildenbrand wrote:
> > On 22.01.20 11:42, Michal Hocko wrote:
> >> On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
> >> Really, the interface is flawed and should have never been merged in
> >> the
> >> fi
On 1/22/20 9:21 PM, Vaibhav Jain wrote:
String 'bus_desc.provider_name' allocated inside
papr_scm_nvdimm_init() will leaks in case call to
nvdimm_bus_register() fails or when papr_scm_remove() is called.
This minor patch ensures that 'bus_desc.provider_name' is freed in
error path for nvdimm_bus
On Wed, Jan 22, 2020 at 08:13:12AM -0800, Linus Torvalds wrote:
> On Wed, Jan 22, 2020 at 5:00 AM Christophe Leroy
> wrote:
> >
> > Modify filldir() and filldir64() to request the real area they need
> > to get access to.
>
> Not like this.
>
> This makes the situation for architectures like x86
I'm building for a ppc32 (mpc8309) target using Yocto, and I'm hitting a
very hard to debug problem that maybe someone else has encountered. This
doesn't happen always, perhaps 1 in 8 times or something like that.
The issue is that when the build gets to do "${CROSS}objcopy -O binary
... vmlinux",
Some architectures grand full access to userspace regardless of the
address/len passed to user_access_begin(), but other architectures
only grand access to the requested area.
For exemple, on 32 bits powerpc (book3s/32), access is granted by
segments of 256 Mbytes.
Modify filldir() and filldir64(
__builtin_constant_p() always return 0 for pointers, so on RADIX
we always end up opening both direction (by writing 0 in SPR29):
0170 <._copy_to_user>:
...
1b0: 4c 00 01 2c isync
1b4: 39 20 00 00 li r9,0
1b8: 7d 3d 03 a6 mtspr 29,r9
1bc: 4c 00 01 2c
At the moment, bad_kuap_fault() reports a fault only if a bad access
to userspace occurred while access to userspace was not granted.
But if a fault occurs for a write outside the allowed userspace
segment(s) that have been unlocked, bad_kuap_fault() fails to
detect it and the kernel loops forever
NULL addr is a user address. Don't waste time checking it. If
someone tries to access it, it will SIGFAULT the same way as for
address 1, so no need to make it special.
The special case is when not doing a write, in that case we want
to drop the entire function. This is now handled by 'dir' param
In preparation of implementing user_access_begin and friends
on powerpc, the book3s/32 version of prevent_user_access() need
to be prepared for user_access_end().
user_access_end() doesn't provide the address and size which
were passed to user_access_begin(), required by prevent_user_access()
to k
Today, when a function like strncpy_from_user() is called,
the userspace access protection is de-activated and re-activated
for every word read.
By implementing user_access_begin and friends, the protection
is de-activated at the beginning of the copy and re-activated at the
end.
Implement user_a
Le 22/01/2020 à 18:41, Al Viro a écrit :
On Wed, Jan 22, 2020 at 08:13:12AM -0800, Linus Torvalds wrote:
On Wed, Jan 22, 2020 at 5:00 AM Christophe Leroy
wrote:
Modify filldir() and filldir64() to request the real area they need
to get access to.
Not like this.
This makes the situation
On 22.01.20 17:46, Michal Hocko wrote:
> On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
>> On 22.01.20 11:54, David Hildenbrand wrote:
>>> On 22.01.20 11:42, Michal Hocko wrote:
On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
Really, the interface is flawed and should have neve
On Wed 22-01-20 19:15:47, David Hildenbrand wrote:
> On 22.01.20 17:46, Michal Hocko wrote:
> > On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
[...]
> >> Especially interesting for IBM z Systems, whereby memory
> >> onlining/offlining will trigger the actual population of memory in the
> >> hyp
Still doesn't build for me:
> # make
> make --no-builtin-rules ARCH=x86_64 -C ../../../.. headers_install
> make[1]: Entering directory '/home/dave/linux.git'
> INSTALL ./usr/include
> make[1]: Leaving directory '/home/dave/linux.git'
> make: *** No rule to make target
> '/home/dave/linux.git/t
On 22.01.20 19:38, Michal Hocko wrote:
> On Wed 22-01-20 19:15:47, David Hildenbrand wrote:
>> On 22.01.20 17:46, Michal Hocko wrote:
>>> On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
> [...]
Especially interesting for IBM z Systems, whereby memory
onlining/offlining will trigger the
On Wed 22-01-20 19:15:47, David Hildenbrand wrote:
[...]
> c) CC relevant people I identify (lsmem/chmem/powerpc-utils/etc.) on the
> patch to see if we are missing other use cases/users/implications.
>
> Sounds like a plan?
I would start with this step. Thanks!
--
Michal Hocko
SUSE Labs
On Wed 22-01-20 19:46:15, David Hildenbrand wrote:
> On 22.01.20 19:38, Michal Hocko wrote:
[...]
> > How exactly is check + offline more optimal then offline which makes
> > check as its first step? I will get to your later points after this is
> > clarified.
>
> Scanning (almost) lockless is mor
On Wed, Jan 22, 2020 at 10:24 AM Linus Torvalds
wrote:
>
> Patch looks better, but those names are horrid.
Hmm.
A bit more re-organization also allows us to do the unsafe_put_user()
unconditionally.
In particular, if we remove 'previous' as a pointer from the filldir
data structure, and replace
On Wed, Jan 22, 2020 at 12:00 PM Linus Torvalds
wrote:
>
> A bit more re-organization also allows us to do the unsafe_put_user()
> unconditionally.
I meant the "user_access_begin()", of course.
Code was right, explanation was wrong.
That said, with this model, we _could_ make the
unsaf
[ Sorry about HTML crud, on mobile right now ]
On Wed, Jan 22, 2020, 09:52 Christophe Leroy
wrote:
>
> - struct linux_dirent __user * dirent;
> + struct linux_dirent __user * dirent, *dirent0;
Patch looks better, but those names are horrid.
Please just use "prev" for the previous
[ Talking to myself ]
On Wed, Jan 22, 2020 at 12:00 PM Linus Torvalds
wrote:
>
> COMPLETELY UNTESTED! It compiles for me. The generated assembly looks
> ok from a quick look.
Some more testing shows that objtool is unhappy about how we do that
signal_pending(current) inside the user access regio
On Wed, Jan 22, 2020 at 11:09 AM Michal Hocko wrote:
>
> On Wed 22-01-20 19:46:15, David Hildenbrand wrote:
> > On 22.01.20 19:38, Michal Hocko wrote:
> [...]
> > > How exactly is check + offline more optimal then offline which makes
> > > check as its first step? I will get to your later points a
Anyone, ping?
On 10/01/2020 15:18, Alexey Kardashevskiy wrote:
>
>
> On 02/12/2019 12:59, Alexey Kardashevskiy wrote:
>> Here is an attempt to support bigger DMA space for devices
>> supporting DMA masks less than 59 bits (GPUs come into mind
>> first). POWER9 PHBs have an option to map 2 windo
>From 72a7497a8673c93a4b80aa4fc38b88a8e90aa650 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Wed, 22 Jan 2020 18:57:18 -0600
Subject: [PATCH 1/1] powerpc/xmon: Fix compile error in print_insn* functions
Fix couple of compile errors I stumbled upon with CONFIG_XMON=y and
CONFIG_XMON_DIS
On Thu, Jan 23, 2020 at 11:53:32AM +1100, Alexey Kardashevskiy wrote:
> Anyone, ping?
Sorry, I've totally lost track of this one. I think you'll need to
repost.
>
>
> On 10/01/2020 15:18, Alexey Kardashevskiy wrote:
> >
> >
> > On 02/12/2019 12:59, Alexey Kardashevskiy wrote:
> >> Here is a
String 'bus_desc.provider_name' allocated inside
of_pmem_region_probe() will leak in case call to nvdimm_bus_register()
fails or when of_pmem_region_remove() is called.
This minor patch ensures that 'bus_desc.provider_name' is freed in
error path for of_pmem_region_probe() as well as in
of_pmem_re
Le 22/01/2020 à 21:37, Linus Torvalds a écrit :
[ Talking to myself ]
On Wed, Jan 22, 2020 at 12:00 PM Linus Torvalds
wrote:
COMPLETELY UNTESTED! It compiles for me. The generated assembly looks
ok from a quick look.
So here's a slightly updated patch that does exactly that, and avoids
62 matches
Mail list logo
