* Re: [PATCH] PCI/AER: Add a null check before eeh_ops->notify_resume callback.
From: Vaibhav Jain @ 2018-02-22 12:31 UTC (permalink / raw)
To: Russell Currey, Michael Ellerman
Cc: Frederic Barrat, linuxppc-dev, Benjamin Herrenschmidt,
Bryant G . Ly
In-Reply-To: <20180222115803.21738-1-vaibhav@linux.vnet.ibm.com>
There is already a patch for this issue applied to ppc-next viz commit
521ca5a9859a870e354d1a6b84a6ff ("powerpc/eeh: Add conditional check on
notify_resume"). So please ignore the patch.
--
Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Horia Geantă @ 2018-02-22 12:29 UTC (permalink / raw)
To: Herbert Xu, Christophe LEROY
Cc: David S. Miller, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20180222114741.GA27631@gondor.apana.org.au>
On 2/22/2018 1:47 PM, Herbert Xu wrote:=0A=
> On Tue, Feb 20, 2018 at 11:32:25AM +0000, Horia Geant=E3 wrote:=0A=
>>=0A=
>> If final/finup is optional, how is the final hash supposed to be retriev=
ed?=0A=
> =0A=
> Sometimes the computation ends with a partial hash, that's what=0A=
> export is for. Also it is completely legal to abandon the hash=0A=
> state entirely.=0A=
> =0A=
Thanks for the explanation.=0A=
It's unintuitive to call .init() -> .update() and then not to call any of=
=0A=
.final(), .finup(), .export().=0A=
=0A=
Christophe,=0A=
=0A=
IIUC this means that there is no room for improvement.=0A=
This patch needs to be reverted, to restore previous behaviour when the=0A=
hw_context was mapped / unmapped for every request.=0A=
=0A=
Thanks,=0A=
Horia=0A=
^ permalink raw reply
* [PATCH 5/5] powerpc/mm/32: Remove the reserved memory hack
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Aneesh Kumar K.V,
Balbir Singh, Guenter Roeck
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
This hack, introduced in commit c5df7f775148 ("powerpc: allow ioremap
within reserved memory regions") is now unnecessary.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/init_32.c | 5 -----
arch/powerpc/mm/mmu_decl.h | 1 -
arch/powerpc/mm/pgtable_32.c | 3 +--
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 6419b33ca309..326240177fa6 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -88,11 +88,6 @@ void MMU_init(void);
int __map_without_bats;
int __map_without_ltlbs;
-/*
- * This tells the system to allow ioremapping memory marked as reserved.
- */
-int __allow_ioremap_reserved;
-
/* max amount of low RAM to map in */
unsigned long __max_low_memory = MAX_LOW_MEM;
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 57fbc554c785..c4c0a09a7775 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -98,7 +98,6 @@ extern void setbat(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, pgprot_t prot);
extern int __map_without_bats;
-extern int __allow_ioremap_reserved;
extern unsigned int rtas_data, rtas_size;
struct hash_pte;
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d54e1a9c1c99..a89eb3b898cd 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -146,8 +146,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
/*
* Don't allow anybody to remap normal RAM that we're using.
*/
- if (page_is_ram(__phys_to_pfn(p)) &&
- !(__allow_ioremap_reserved && memblock_is_region_reserved(p, size))) {
+ if (page_is_ram(__phys_to_pfn(p))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
return NULL;
--
2.16.1
^ permalink raw reply related
* [PATCH 3/5] powerpc/mm/32: Use page_is_ram to check for RAM
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Balbir Singh,
Guenter Roeck
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/pgtable_32.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d35d9ad3c1cd..d54e1a9c1c99 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -145,9 +145,8 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
#ifndef CONFIG_CRASH_DUMP
/*
* Don't allow anybody to remap normal RAM that we're using.
- * mem_init() sets high_memory so only do the check after that.
*/
- if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
+ if (page_is_ram(__phys_to_pfn(p)) &&
!(__allow_ioremap_reserved && memblock_is_region_reserved(p, size))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
--
2.16.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] ocxl: Document the OCXL_IOCTL_GET_METADATA IOCTL
From: Frederic Barrat @ 2018-02-22 12:16 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: arnd, frederic.barrat, gregkh, andrew.donnellan,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-3-alastair@au1.ibm.com>
Le 22/02/2018 à 05:17, Alastair D'Silva a écrit :
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Documentation/accelerators/ocxl.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst
> index 4f7af841d935..ddcc58d01cfb 100644
> --- a/Documentation/accelerators/ocxl.rst
> +++ b/Documentation/accelerators/ocxl.rst
> @@ -152,6 +152,11 @@ OCXL_IOCTL_IRQ_SET_FD:
> Associate an event fd to an AFU interrupt so that the user process
> can be notified when the AFU sends an interrupt.
>
> +OCXL_IOCTL_GET_METADATA:
> +
> + Obtains configuration information from the card, such at the size of
> + MMIO areas, the AFU version, and the PASID for the current context.
> +
>
> mmap
> ----
>
^ permalink raw reply
* Re: [PATCH v3 1/2] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Frederic Barrat @ 2018-02-22 12:16 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: arnd, frederic.barrat, gregkh, andrew.donnellan,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-2-alastair@au1.ibm.com>
Le 22/02/2018 à 05:17, Alastair D'Silva a écrit :
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
Thanks!
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> drivers/misc/ocxl/file.c | 27 +++++++++++++++++++++++++++
> include/uapi/misc/ocxl.h | 17 +++++++++++++++++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index d9aa407db06a..90df1be5ef3f 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx,
> return rc;
> }
>
> +static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
> + struct ocxl_ioctl_metadata __user *uarg)
> +{
> + struct ocxl_ioctl_metadata arg;
> +
> + memset(&arg, 0, sizeof(arg));
> +
> + arg.version = 0;
> +
> + arg.afu_version_major = ctx->afu->config.version_major;
> + arg.afu_version_minor = ctx->afu->config.version_minor;
> + arg.pasid = ctx->pasid;
> + arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
> + arg.global_mmio_size = ctx->afu->config.global_mmio_size;
> +
> + if (copy_to_user(uarg, &arg, sizeof(arg)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" : \
> x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \
> x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
> x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
> + x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
> "UNKNOWN")
>
> static long afu_ioctl(struct file *file, unsigned int cmd,
> @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
> irq_fd.eventfd);
> break;
>
> + case OCXL_IOCTL_GET_METADATA:
> + rc = afu_ioctl_get_metadata(ctx,
> + (struct ocxl_ioctl_metadata __user *) args);
> + break;
> +
> default:
> rc = -EINVAL;
> }
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 4b0b0b756f3e..0af83d80fb3e 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -32,6 +32,22 @@ struct ocxl_ioctl_attach {
> __u64 reserved3;
> };
>
> +struct ocxl_ioctl_metadata {
> + __u16 version; // struct version, always backwards compatible
> +
> + // Version 0 fields
> + __u8 afu_version_major;
> + __u8 afu_version_minor;
> + __u32 pasid; // PASID assigned to the current context
> +
> + __u64 pp_mmio_size; // Per PASID MMIO size
> + __u64 global_mmio_size;
> +
> + // End version 0 fields
> +
> + __u64 reserved[13]; // Total of 16*u64
> +};
> +
> struct ocxl_ioctl_irq_fd {
> __u64 irq_offset;
> __s32 eventfd;
> @@ -45,5 +61,6 @@ struct ocxl_ioctl_irq_fd {
> #define OCXL_IOCTL_IRQ_ALLOC _IOR(OCXL_MAGIC, 0x11, __u64)
> #define OCXL_IOCTL_IRQ_FREE _IOW(OCXL_MAGIC, 0x12, __u64)
> #define OCXL_IOCTL_IRQ_SET_FD _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
> +#define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct ocxl_ioctl_metadata)
>
> #endif /* _UAPI_MISC_OCXL_H */
>
^ permalink raw reply
* [PATCH 4/5] powerpc: wii: Don't rely on the reserved memory hack
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/platforms/embedded6xx/wii.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c
index 4682327f76a9..fc00d82691e1 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -81,21 +81,9 @@ void __init wii_memory_fixups(void)
BUG_ON(memblock.memory.cnt != 2);
BUG_ON(!page_aligned(p[0].base) || !page_aligned(p[1].base));
- /* trim unaligned tail */
- memblock_remove(ALIGN(p[1].base + p[1].size, PAGE_SIZE),
- (phys_addr_t)ULLONG_MAX);
-
- /* determine hole, add & reserve them */
+ /* determine hole */
wii_hole_start = ALIGN(p[0].base + p[0].size, PAGE_SIZE);
wii_hole_size = p[1].base - wii_hole_start;
- memblock_add(wii_hole_start, wii_hole_size);
- memblock_reserve(wii_hole_start, wii_hole_size);
-
- BUG_ON(memblock.memory.cnt != 1);
- __memblock_dump_all();
-
- /* allow ioremapping the address space in the hole */
- __allow_ioremap_reserved = 1;
}
unsigned long __init wii_mmu_mapin_mem2(unsigned long top)
--
2.16.1
^ permalink raw reply related
* [PATCH 2/5] powerpc: mm: Use memblock API for PPC32 page_is_ram
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Vlastimil Babka,
Michal Hocko, Andrew Morton, Balbir Singh, Oliver O'Halloran,
Joe Perches
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
To support accurate checking for different blocks of memory on PPC32,
use the same memblock-based approach that's already used on PPC64 also
on PPC32.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/mem.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index da4e1555d61d..a42b86e2a34c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -82,11 +82,7 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
int page_is_ram(unsigned long pfn)
{
-#ifndef CONFIG_PPC64 /* XXX for now */
- return pfn < max_pfn;
-#else
return memblock_is_memory(__pfn_to_phys(pfn));
-#endif
}
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
--
2.16.1
^ permalink raw reply related
* [PATCH 1/5] powerpc: mm: Simplify page_is_ram by using memblock_is_memory
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Vlastimil Babka,
Michal Hocko, Andrew Morton, Balbir Singh, Joe Perches,
Oliver O'Halloran
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
Instead of open-coding the search in page_is_ram, call memblock_is_memory.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/mem.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index fe8c61149fb8..da4e1555d61d 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -85,13 +85,7 @@ int page_is_ram(unsigned long pfn)
#ifndef CONFIG_PPC64 /* XXX for now */
return pfn < max_pfn;
#else
- unsigned long paddr = (pfn << PAGE_SHIFT);
- struct memblock_region *reg;
-
- for_each_memblock(memory, reg)
- if (paddr >= reg->base && paddr < (reg->base + reg->size))
- return 1;
- return 0;
+ return memblock_is_memory(__pfn_to_phys(pfn));
#endif
}
--
2.16.1
^ permalink raw reply related
* [PATCH 0/5] PPC32/ioremap: Use memblock API to check for RAM
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer
This patchset solves the same problem as my previous one[1] but follows
a rather different approach. Instead of implementing DISCONTIGMEM for
PowerPC32, I simply switched the "is this RAM" check in __ioremap_caller
to the existing page_is_ram function, and unified page_is_ram to search
memblock.memory on PPC64 and PPC32.
The intended result is, as before, that my Wii can allocate the MMIO
range of its GPIO controller, which was previously not possible, because
the reserved memory hack (__allow_ioremap_reserved) didn't affect the
API in kernel/resource.c.
Thanks to Christophe Leroy for reviewing the previous patchset.
[1]: https://www.spinics.net/lists/kernel/msg2726786.html
Jonathan Neuschäfer (5):
powerpc: mm: Simplify page_is_ram by using memblock_is_memory
powerpc: mm: Use memblock API for PPC32 page_is_ram
powerpc/mm/32: Use page_is_ram to check for RAM
powerpc: wii: Don't rely on the reserved memory hack
powerpc/mm/32: Remove the reserved memory hack
arch/powerpc/mm/init_32.c | 5 -----
arch/powerpc/mm/mem.c | 12 +-----------
arch/powerpc/mm/mmu_decl.h | 1 -
arch/powerpc/mm/pgtable_32.c | 4 +---
arch/powerpc/platforms/embedded6xx/wii.c | 14 +-------------
5 files changed, 3 insertions(+), 33 deletions(-)
--
2.16.1
^ permalink raw reply
* Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls
From: Michael Holzheu @ 2018-02-22 12:10 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Michael Holzheu, Naveen N. Rao, ast, Daniel Borkmann,
Sandipan Das, Michael Ellerman, linuxppc-dev, netdev
In-Reply-To: <20180222130640.0043c8d3@TP-holzheu>
Am Thu, 22 Feb 2018 13:06:40 +0100
schrieb Michael Holzheu <holzheu@linux.vnet.ibm.com>:
> Am Fri, 16 Feb 2018 21:20:09 +0530
> schrieb "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>:
>
> > Daniel Borkmann wrote:
> > > On 02/15/2018 05:25 PM, Daniel Borkmann wrote:
> > >> On 02/13/2018 05:05 AM, Sandipan Das wrote:
> > >>> The imm field of a bpf_insn is a signed 32-bit integer. For
> > >>> JIT-ed bpf-to-bpf function calls, it stores the offset from
> > >>> __bpf_call_base to the start of the callee function.
> > >>>
> > >>> For some architectures, such as powerpc64, it was found that
> > >>> this offset may be as large as 64 bits because of which this
> > >>> cannot be accomodated in the imm field without truncation.
> > >>>
> > >>> To resolve this, we additionally make aux->func within each
> > >>> bpf_prog associated with the functions to point to the list
> > >>> of all function addresses determined by the verifier.
> > >>>
> > >>> We keep the value assigned to the off field of the bpf_insn
> > >>> as a way to index into aux->func and also set aux->func_cnt
> > >>> so that this can be used for performing basic upper bound
> > >>> checks for the off field.
> > >>>
> > >>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
> > >>> ---
> > >>> v2: Make aux->func point to the list of functions determined
> > >>> by the verifier rather than allocating a separate callee
> > >>> list for each function.
> > >>
> > >> Approach looks good to me; do you know whether s390x JIT would
> > >> have similar requirement? I think one limitation that would still
> > >> need to be addressed later with such approach would be regarding the
> > >> xlated prog dump in bpftool, see 'BPF calls via JIT' in 7105e828c087
> > >> ("bpf: allow for correlation of maps and helpers in dump"). Any
> > >> ideas for this (potentially if we could use off + imm for calls,
> > >> we'd get to 48 bits, but that seems still not be enough as you say)?
> >
> > All good points. I'm not really sure how s390x works, so I can't comment
> > on that, but I'm copying Michael Holzheu for his consideration.
> >
> > With the existing scheme, 48 bits won't be enough, so we rejected that
> > approach. I can also see how this will be a problem with bpftool, but I
> > haven't looked into it in detail. I wonder if we can annotate the output
> > to indicate the function being referred to?
> >
> > >
> > > One other random thought, although I'm not sure how feasible this
> > > is for ppc64 JIT to realize ... but idea would be to have something
> > > like the below:
> > >
> > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > > index 29ca920..daa7258 100644
> > > --- a/kernel/bpf/core.c
> > > +++ b/kernel/bpf/core.c
> > > @@ -512,6 +512,11 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> > > return ret;
> > > }
> > >
> > > +void * __weak bpf_jit_image_alloc(unsigned long size)
> > > +{
> > > + return module_alloc(size);
> > > +}
> > > +
> > > struct bpf_binary_header *
> > > bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > > unsigned int alignment,
> > > @@ -525,7 +530,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > > * random section of illegal instructions.
> > > */
> > > size = round_up(proglen + sizeof(*hdr) + 128, PAGE_SIZE);
> > > - hdr = module_alloc(size);
> > > + hdr = bpf_jit_image_alloc(size);
> > > if (hdr == NULL)
> > > return NULL;
> > >
> > > And ppc64 JIT could override bpf_jit_image_alloc() in a similar way
> > > like some archs would override the module_alloc() helper through a
> > > custom implementation, usually via __vmalloc_node_range(), so we
> > > could perhaps fit the range for BPF JITed images in a way that they
> > > could use the 32bit imm in the end? There are not that many progs
> > > loaded typically, so the range could be a bit narrower in such case
> > > anyway. (Not sure if this would work out though, but I thought to
> > > bring it up.)
> >
> > That'd be a good option to consider. I don't think we want to allocate
> > anything from the linear memory range since users could load
> > unprivileged BPF programs and consume a lot of memory that way. I doubt
> > if we can map vmalloc'ed memory into the 0xc0 address range, but I'm not
> > entirely sure.
> >
> > Michael,
> > Is the above possible? The question is if we can have BPF programs be
> > allocated within 4GB of __bpf_call_base (which is a kernel symbol), so
> > that calls to those programs can be encoded in a 32-bit immediate field
> > in a BPF instruction. As an extension, we may be able to extend it to
> > 48-bits by combining with another BPF instruction field (offset). In
> > either case, the vmalloc'ed address range won't work.
> >
> > The alternative is to pass the full 64-bit address of the BPF program in
> > an auxiliary field (as proposed in this patch set) but we need to fix it
> > up for 'bpftool' as well.
> Hi Naveen,
>
> Our s390 kernel maintainer Martin Schwidefsky took over
> eBPF responsibility for s390 from me.
>
> @Martin: Can you answer Navee's question?
>
> Michael
Damn, I forgot adding Martin to cc.
Time for vacation ;-)
Michael
^ permalink raw reply
* Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls
From: Michael Holzheu @ 2018-02-22 12:06 UTC (permalink / raw)
To: Naveen N. Rao
Cc: ast, Daniel Borkmann, Sandipan Das, Michael Ellerman,
linuxppc-dev, netdev
In-Reply-To: <1518791626.5484j97if6.naveen@linux.ibm.com>
Am Fri, 16 Feb 2018 21:20:09 +0530
schrieb "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>:
> Daniel Borkmann wrote:
> > On 02/15/2018 05:25 PM, Daniel Borkmann wrote:
> >> On 02/13/2018 05:05 AM, Sandipan Das wrote:
> >>> The imm field of a bpf_insn is a signed 32-bit integer. For
> >>> JIT-ed bpf-to-bpf function calls, it stores the offset from
> >>> __bpf_call_base to the start of the callee function.
> >>>
> >>> For some architectures, such as powerpc64, it was found that
> >>> this offset may be as large as 64 bits because of which this
> >>> cannot be accomodated in the imm field without truncation.
> >>>
> >>> To resolve this, we additionally make aux->func within each
> >>> bpf_prog associated with the functions to point to the list
> >>> of all function addresses determined by the verifier.
> >>>
> >>> We keep the value assigned to the off field of the bpf_insn
> >>> as a way to index into aux->func and also set aux->func_cnt
> >>> so that this can be used for performing basic upper bound
> >>> checks for the off field.
> >>>
> >>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
> >>> ---
> >>> v2: Make aux->func point to the list of functions determined
> >>> by the verifier rather than allocating a separate callee
> >>> list for each function.
> >>
> >> Approach looks good to me; do you know whether s390x JIT would
> >> have similar requirement? I think one limitation that would still
> >> need to be addressed later with such approach would be regarding the
> >> xlated prog dump in bpftool, see 'BPF calls via JIT' in 7105e828c087
> >> ("bpf: allow for correlation of maps and helpers in dump"). Any
> >> ideas for this (potentially if we could use off + imm for calls,
> >> we'd get to 48 bits, but that seems still not be enough as you say)?
>
> All good points. I'm not really sure how s390x works, so I can't comment
> on that, but I'm copying Michael Holzheu for his consideration.
>
> With the existing scheme, 48 bits won't be enough, so we rejected that
> approach. I can also see how this will be a problem with bpftool, but I
> haven't looked into it in detail. I wonder if we can annotate the output
> to indicate the function being referred to?
>
> >
> > One other random thought, although I'm not sure how feasible this
> > is for ppc64 JIT to realize ... but idea would be to have something
> > like the below:
> >
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 29ca920..daa7258 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -512,6 +512,11 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> > return ret;
> > }
> >
> > +void * __weak bpf_jit_image_alloc(unsigned long size)
> > +{
> > + return module_alloc(size);
> > +}
> > +
> > struct bpf_binary_header *
> > bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > unsigned int alignment,
> > @@ -525,7 +530,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > * random section of illegal instructions.
> > */
> > size = round_up(proglen + sizeof(*hdr) + 128, PAGE_SIZE);
> > - hdr = module_alloc(size);
> > + hdr = bpf_jit_image_alloc(size);
> > if (hdr == NULL)
> > return NULL;
> >
> > And ppc64 JIT could override bpf_jit_image_alloc() in a similar way
> > like some archs would override the module_alloc() helper through a
> > custom implementation, usually via __vmalloc_node_range(), so we
> > could perhaps fit the range for BPF JITed images in a way that they
> > could use the 32bit imm in the end? There are not that many progs
> > loaded typically, so the range could be a bit narrower in such case
> > anyway. (Not sure if this would work out though, but I thought to
> > bring it up.)
>
> That'd be a good option to consider. I don't think we want to allocate
> anything from the linear memory range since users could load
> unprivileged BPF programs and consume a lot of memory that way. I doubt
> if we can map vmalloc'ed memory into the 0xc0 address range, but I'm not
> entirely sure.
>
> Michael,
> Is the above possible? The question is if we can have BPF programs be
> allocated within 4GB of __bpf_call_base (which is a kernel symbol), so
> that calls to those programs can be encoded in a 32-bit immediate field
> in a BPF instruction. As an extension, we may be able to extend it to
> 48-bits by combining with another BPF instruction field (offset). In
> either case, the vmalloc'ed address range won't work.
>
> The alternative is to pass the full 64-bit address of the BPF program in
> an auxiliary field (as proposed in this patch set) but we need to fix it
> up for 'bpftool' as well.
Hi Naveen,
Our s390 kernel maintainer Martin Schwidefsky took over
eBPF responsibility for s390 from me.
@Martin: Can you answer Navee's question?
Michael
^ permalink raw reply
* Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Frederic Barrat @ 2018-02-22 12:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKTCnzkjbNVxBVTKmffbxsyqMb83y2tXN1Xv4Zm3VT+sxePdpg@mail.gmail.com>
>>> Yeah, I think metadata will evolve for a while till it settle's down.
>>> Since ocxl_ioctl_get_metadata is exposed via uapi, a newer program
>>> calling an older kernel will never work, since the size of that
>>> struct
>>> will always be larger than what the OS supports and our
>>> copy_to_user()
>>> will fail. The other option is for the user program to try all
>>> possible versions till one succeeds, that is bad as well. I think
>>> there are a few ways around it, if we care about this combination.
>>>
>>> Balbir Singh.
>>>
>>
>> We have a number of reserved members at the end of the struct which can
>> be re-purposed for future information (with a corresponding bump of the
>> version number).
>
> Good point, agreed
I initially had reservations about using an ioctl command for various
AFU/context parameters because extensibility is going to be a pain. With
the current reserved fields and versioning, we're ok for some time
(version handling will remain a bit of a pain but that's life). I agree
it helps the library by making things more light weight compared to
sysfs. But if we need to add parameters in the future, we should keep
sysfs as an option, especially if it's for rarely used parameters, i.e.
not something we'll need immediately after an open().
Fred
^ permalink raw reply
* [PATCH] PCI/AER: Add a null check before eeh_ops->notify_resume callback.
From: Vaibhav Jain @ 2018-02-22 11:58 UTC (permalink / raw)
To: Russell Currey, Michael Ellerman
Cc: Vaibhav Jain, Frederic Barrat, linuxppc-dev,
Benjamin Herrenschmidt, Bryant G . Ly
This patch puts a NULL check before branching to the address pointed
to by eeh_ops->notify_resume in eeh_report_resume(). The callback
is used to notify the arch EEH code that a pci device is back
online.
For PPC64 presently, only an implementation for pseries platform is
available and not for powernv. Hence without this patch EEH recovery
on all non-virtualized hosts is causing a kernel panic when
CONFIG_PCI_IOV is set. The panic is usually is of the form:
EEH: Notify device driver to resume
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
LR eeh_report_resume+0x218/0x220
Call Trace:
eeh_report_resume+0x1f0/0x220 (unreliable)
eeh_pe_dev_traverse+0x98/0x170
eeh_handle_normal_event+0x3f4/0x650
eeh_handle_event+0x188/0x380
eeh_event_handler+0x208/0x210
kthread+0x168/0x1b0
ret_from_kernel_thread+0x5c/0xb4
Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Fixes: 856e1eb9bdd4("PCI/AER: Add uevents in AER and EEH error/resume")
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh_driver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index beea2182d754..932858a293ea 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -384,7 +384,8 @@ static void *eeh_report_resume(void *data, void *userdata)
eeh_pcid_put(dev);
pci_uevent_ers(dev, PCI_ERS_RESULT_RECOVERED);
#ifdef CONFIG_PCI_IOV
- eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
+ if (eeh_ops->notify_resume)
+ eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
#endif
return NULL;
}
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Herbert Xu @ 2018-02-22 11:47 UTC (permalink / raw)
To: Horia Geantă
Cc: Christophe LEROY, David S. Miller, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR0402MB3342B99A1BEA5622F29F79EF98CF0@VI1PR0402MB3342.eurprd04.prod.outlook.com>
On Tue, Feb 20, 2018 at 11:32:25AM +0000, Horia Geantă wrote:
>
> If final/finup is optional, how is the final hash supposed to be retrieved?
Sometimes the computation ends with a partial hash, that's what
export is for. Also it is completely legal to abandon the hash
state entirely.
> According to documentation, these are the accepted flows (with the option to
> export/import a partial hash b/w update and final/finup):
>
> .init() -> .update() -> .final()
> ^ | |
> '----' '---> HASH
>
> .init() -> .update() -> .finup()
> ^ | |
> '----' '---> HASH
>
> .digest()
> |
> '---------------> HASH
The documentation is simply incomplete in this regard.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file
From: Christophe LEROY @ 2018-02-22 10:17 UTC (permalink / raw)
To: Horia Geantă, Greg Kroah-Hartman
Cc: Herbert Xu, linuxppc-dev@lists.ozlabs.org,
linux-crypto@vger.kernel.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AM0PR0402MB3329F7DB21610C75674BA7AD98CD0@AM0PR0402MB3329.eurprd04.prod.outlook.com>
Le 22/02/2018 à 09:30, Horia Geantă a écrit :
> On 2/22/2018 9:08 AM, Christophe Leroy wrote:
>> Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721
>>
>> Performing the hash of an empty file leads to a kernel Oops
>>
>> [ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c
>> [ 44.512819] Faulting instruction address: 0xc02d2be8
>> [ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 44.529171] BE PREEMPT CMPC885
>> [ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
>> [ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000
>> [ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea)
>> [ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000
>> [ 44.560855] DAR: 0000000c DSISR: c0000000
>> [ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
>> [ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
>> [ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
>> [ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
>> [ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
>> [ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
>> [ 44.608868] Call Trace:
>> [ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
>> [ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
>> [ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
>> [ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
>> [ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
>> [ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
>> [ 44.645530] Instruction dump:
>> [ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
>> [ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
>>
>> This patch fixes that Oops by checking if src is NULL.
>>
>> Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Isn't this needed also in 4.15.y?
It is already in 4.15, see
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/crypto/talitos.c?h=v4.15.4&id=e76a4b126d1e7fbd0124cb885331a45e9a24f32b
Christophe
>
> Thanks,
> Horia
>
^ permalink raw reply
* Re: [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file
From: Horia Geantă @ 2018-02-22 8:30 UTC (permalink / raw)
To: Christophe Leroy, Greg Kroah-Hartman
Cc: Herbert Xu, linuxppc-dev@lists.ozlabs.org,
linux-crypto@vger.kernel.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180222070616.A15E36CBD4@po15720vm.idsi0.si.c-s.fr>
On 2/22/2018 9:08 AM, Christophe Leroy wrote:=0A=
> Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721=0A=
> =0A=
> Performing the hash of an empty file leads to a kernel Oops=0A=
> =0A=
> [ 44.504600] Unable to handle kernel paging request for data at address=
0x0000000c=0A=
> [ 44.512819] Faulting instruction address: 0xc02d2be8=0A=
> [ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]=0A=
> [ 44.529171] BE PREEMPT CMPC885=0A=
> [ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-=
g3a968610b6ea #81=0A=
> [ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000=0A=
> [ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211=
-g3a968610b6ea)=0A=
> [ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 200000=
00=0A=
> [ 44.560855] DAR: 0000000c DSISR: c0000000=0A=
> [ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 000000=
01 00000001 00000000=0A=
> [ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280=
d4 00000000 10020008=0A=
> [ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 000000=
00 c646f9f0 c6179a10=0A=
> [ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a=
30 c62f0000 c646f9c0=0A=
> [ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700=0A=
> [ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700=0A=
> [ 44.608868] Call Trace:=0A=
> [ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unrel=
iable)=0A=
> [ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210=0A=
> [ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138=0A=
> [ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84=0A=
> [ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4=0A=
> [ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38=0A=
> [ 44.645530] Instruction dump:=0A=
> [ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff=
0190 2f870000=0A=
> [ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d=
29c214 913e003c=0A=
> =0A=
> This patch fixes that Oops by checking if src is NULL.=0A=
> =0A=
> Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more gene=
ric")=0A=
> Cc: <stable@vger.kernel.org>=0A=
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>=0A=
=0A=
Isn't this needed also in 4.15.y?=0A=
=0A=
Thanks,=0A=
Horia=0A=
^ permalink raw reply
* [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file
From: Christophe Leroy @ 2018-02-22 7:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-crypto, linux-kernel, linuxppc-dev, Herbert Xu, stable
Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721
Performing the hash of an empty file leads to a kernel Oops
[ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c
[ 44.512819] Faulting instruction address: 0xc02d2be8
[ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
[ 44.529171] BE PREEMPT CMPC885
[ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
[ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000
[ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea)
[ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000
[ 44.560855] DAR: 0000000c DSISR: c0000000
[ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
[ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
[ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
[ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
[ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
[ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
[ 44.608868] Call Trace:
[ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
[ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
[ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
[ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
[ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
[ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
[ 44.645530] Instruction dump:
[ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
[ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
This patch fixes that Oops by checking if src is NULL.
Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
Cc: <stable@vger.kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
drivers/crypto/talitos.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dff88838dce7..42913116620a 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1124,6 +1124,11 @@ int talitos_sg_map(struct device *dev, struct scatterlist *src,
struct talitos_private *priv = dev_get_drvdata(dev);
bool is_sec1 = has_ftr_sec1(priv);
+ if (!src) {
+ *ptr = zero_entry;
+ return 1;
+ }
+
to_talitos_ptr_len(ptr, len, is_sec1);
to_talitos_ptr_ext_set(ptr, 0, is_sec1);
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v12 01/22] selftests/x86: Move protecton key selftest to arch neutral directory
From: Ingo Molnar @ 2018-02-22 5:51 UTC (permalink / raw)
To: Ram Pai
Cc: shuahkh, linux-kselftest, mpe, linuxppc-dev, linux-mm, x86,
linux-arch, linux-doc, linux-kernel, mingo, akpm, dave.hansen,
benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu, mhocko,
bauerman, ebiederm, arnd
In-Reply-To: <1519264541-7621-2-git-send-email-linuxram@us.ibm.com>
* Ram Pai <linuxram@us.ibm.com> wrote:
> cc: Dave Hansen <dave.hansen@intel.com>
> cc: Florian Weimer <fweimer@redhat.com>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> ---
> tools/testing/selftests/vm/Makefile | 1 +
> tools/testing/selftests/vm/pkey-helpers.h | 223 ++++
> tools/testing/selftests/vm/protection_keys.c | 1407 +++++++++++++++++++++++++
> tools/testing/selftests/x86/Makefile | 2 +-
> tools/testing/selftests/x86/pkey-helpers.h | 223 ----
> tools/testing/selftests/x86/protection_keys.c | 1407 -------------------------
> 6 files changed, 1632 insertions(+), 1631 deletions(-)
> create mode 100644 tools/testing/selftests/vm/pkey-helpers.h
> create mode 100644 tools/testing/selftests/vm/protection_keys.c
> delete mode 100644 tools/testing/selftests/x86/pkey-helpers.h
> delete mode 100644 tools/testing/selftests/x86/protection_keys.c
Acked-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Balbir Singh @ 2018-02-22 5:32 UTC (permalink / raw)
To: Alastair D'Silva
Cc: Frederic Barrat, Arnd Bergmann, frederic.barrat, Greg KH,
linux-kernel@vger.kernel.org, linuxppc-dev, Andrew Donnellan
In-Reply-To: <1519271512.2867.14.camel@au1.ibm.com>
On Thu, Feb 22, 2018 at 2:51 PM, Alastair D'Silva <alastair@au1.ibm.com> wrote:
> On Thu, 2018-02-22 at 14:46 +1100, Balbir Singh wrote:
> <snip>
>> lpc_size could be added. It's currently useless to the library, but
>> > doesn't
>> > hurt. The one which was giving me troubles on a previous version of
>> > this
>> > patch was the lpc numa node ID, since that was experimental code
>> > and felt
>> > out of place considering what's been upstreamed in skiboot and
>> > linux so far.
>> >
>>
>> Yeah, I think metadata will evolve for a while till it settle's down.
>> Since ocxl_ioctl_get_metadata is exposed via uapi, a newer program
>> calling an older kernel will never work, since the size of that
>> struct
>> will always be larger than what the OS supports and our
>> copy_to_user()
>> will fail. The other option is for the user program to try all
>> possible versions till one succeeds, that is bad as well. I think
>> there are a few ways around it, if we care about this combination.
>>
>> Balbir Singh.
>>
>
> We have a number of reserved members at the end of the struct which can
> be re-purposed for future information (with a corresponding bump of the
> version number).
Good point, agreed
Balbir Singh.
^ permalink raw reply
* Re: [PATCH v3 2/2] ocxl: Document the OCXL_IOCTL_GET_METADATA IOCTL
From: Andrew Donnellan @ 2018-02-22 5:21 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: frederic.barrat, arnd, gregkh, Alastair D'Silva
In-Reply-To: <20180222041739.27899-3-alastair@au1.ibm.com>
On 22/02/18 15:17, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v3 1/2] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Andrew Donnellan @ 2018-02-22 5:21 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: frederic.barrat, arnd, gregkh, Alastair D'Silva
In-Reply-To: <20180222041739.27899-2-alastair@au1.ibm.com>
On 22/02/18 15:17, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 21/23] gcc-plugins: move GCC version check for PowerPC to Kconfig
From: Andrew Donnellan @ 2018-02-22 5:04 UTC (permalink / raw)
To: Masahiro Yamada, linux-kbuild, Linus Torvalds
Cc: Michal Marek, Ulf Magnusson, Kees Cook, Arnd Bergmann,
kernel-hardening, Greg Kroah-Hartman, Randy Dunlap, linux-kernel,
Emese Revfy, Paul Mackerras, linuxppc-dev, Sam Ravnborg
In-Reply-To: <1518806331-7101-22-git-send-email-yamada.masahiro@socionext.com>
On 17/02/18 05:38, Masahiro Yamada wrote:
> For PowerPC, GCC 5.2 is the requirement for GCC plugins. Move the
> version check to Kconfig, and remove the ugly checker.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The old checker was as non-ugly as I could make it. :)
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v3 1/2] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Alastair D'Silva @ 2018-02-22 4:17 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
Cc: frederic.barrat, andrew.donnellan, arnd, gregkh, alastair,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
Some required information is not exposed to userspace currently (eg. the
PASID), pass this information back, along with other information which
is currently communicated via sysfs, which saves some parsing effort in
userspace.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
drivers/misc/ocxl/file.c | 27 +++++++++++++++++++++++++++
include/uapi/misc/ocxl.h | 17 +++++++++++++++++
2 files changed, 44 insertions(+)
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index d9aa407db06a..90df1be5ef3f 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx,
return rc;
}
+static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
+ struct ocxl_ioctl_metadata __user *uarg)
+{
+ struct ocxl_ioctl_metadata arg;
+
+ memset(&arg, 0, sizeof(arg));
+
+ arg.version = 0;
+
+ arg.afu_version_major = ctx->afu->config.version_major;
+ arg.afu_version_minor = ctx->afu->config.version_minor;
+ arg.pasid = ctx->pasid;
+ arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
+ arg.global_mmio_size = ctx->afu->config.global_mmio_size;
+
+ if (copy_to_user(uarg, &arg, sizeof(arg)))
+ return -EFAULT;
+
+ return 0;
+}
+
#define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" : \
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
+ x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
"UNKNOWN")
static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
irq_fd.eventfd);
break;
+ case OCXL_IOCTL_GET_METADATA:
+ rc = afu_ioctl_get_metadata(ctx,
+ (struct ocxl_ioctl_metadata __user *) args);
+ break;
+
default:
rc = -EINVAL;
}
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 4b0b0b756f3e..0af83d80fb3e 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -32,6 +32,22 @@ struct ocxl_ioctl_attach {
__u64 reserved3;
};
+struct ocxl_ioctl_metadata {
+ __u16 version; // struct version, always backwards compatible
+
+ // Version 0 fields
+ __u8 afu_version_major;
+ __u8 afu_version_minor;
+ __u32 pasid; // PASID assigned to the current context
+
+ __u64 pp_mmio_size; // Per PASID MMIO size
+ __u64 global_mmio_size;
+
+ // End version 0 fields
+
+ __u64 reserved[13]; // Total of 16*u64
+};
+
struct ocxl_ioctl_irq_fd {
__u64 irq_offset;
__s32 eventfd;
@@ -45,5 +61,6 @@ struct ocxl_ioctl_irq_fd {
#define OCXL_IOCTL_IRQ_ALLOC _IOR(OCXL_MAGIC, 0x11, __u64)
#define OCXL_IOCTL_IRQ_FREE _IOW(OCXL_MAGIC, 0x12, __u64)
#define OCXL_IOCTL_IRQ_SET_FD _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
+#define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct ocxl_ioctl_metadata)
#endif /* _UAPI_MISC_OCXL_H */
--
2.14.3
^ permalink raw reply related
* [PATCH v3 2/2] ocxl: Document the OCXL_IOCTL_GET_METADATA IOCTL
From: Alastair D'Silva @ 2018-02-22 4:17 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
Cc: frederic.barrat, andrew.donnellan, arnd, gregkh, alastair,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
Documentation/accelerators/ocxl.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst
index 4f7af841d935..ddcc58d01cfb 100644
--- a/Documentation/accelerators/ocxl.rst
+++ b/Documentation/accelerators/ocxl.rst
@@ -152,6 +152,11 @@ OCXL_IOCTL_IRQ_SET_FD:
Associate an event fd to an AFU interrupt so that the user process
can be notified when the AFU sends an interrupt.
+OCXL_IOCTL_GET_METADATA:
+
+ Obtains configuration information from the card, such at the size of
+ MMIO areas, the AFU version, and the PASID for the current context.
+
mmap
----
--
2.14.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox