On Fri, Mar 06, 2015 at 12:38:59PM -0600, Bjorn Helgaas wrote:
>On Fri, Feb 20, 2015 at 04:53:08PM +1100, Gavin Shan wrote:
>> On Thu, Feb 19, 2015 at 04:57:47PM -0200, casca...@linux.vnet.ibm.com wrote:
>> >On Tue, Feb 17, 2015 at 09:36:47AM +1100, Gavin Shan wrote:
>> >> On Mon, Feb 16, 2015 at 1
On Mon, Mar 09, 2015 at 09:52:18AM -0700, Linus Torvalds wrote:
> On Mon, Mar 9, 2015 at 4:29 AM, Dave Chinner wrote:
> >
> >> Also, is there some sane way for me to actually see this behavior on a
> >> regular machine with just a single socket? Dave is apparently running
> >> in some fake-numa se
On 3/9/2015 8:30 PM, Michael Ellerman wrote:
On Sat, 2015-03-07 at 12:10 -0400, Julian Margetson wrote:
With the latest commits
[ 29.960572] Unable to handle kernel paging request for data at address
0x0008
[ 29.974350] Faulting instruction address: 0xc04a4f44
[ 32.012918] Oops: Kern
On Mon, Mar 9, 2015 at 5:28 PM, Michael Ellerman wrote:
> On Sat, 2015-03-07 at 15:02 +1100, Benjamin Herrenschmidt wrote:
>> On Fri, 2015-03-06 at 15:50 -0800, Olof Johansson wrote:
>> > On Fri, Mar 6, 2015 at 2:56 PM, Benjamin Herrenschmidt
>> > wrote:
>> > > On Fri, 2015-03-06 at 10:00 -0500,
On Sat, 2015-03-07 at 12:10 -0400, Julian Margetson wrote:
> With the latest commits
>
> [ 29.960572] Unable to handle kernel paging request for data at address
> 0x0008
> [ 29.974350] Faulting instruction address: 0xc04a4f44
> [ 32.012918] Oops: Kernel access of bad area, sig: 11 [#1]
On Sat, 2015-03-07 at 15:02 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2015-03-06 at 15:50 -0800, Olof Johansson wrote:
> > On Fri, Mar 6, 2015 at 2:56 PM, Benjamin Herrenschmidt
> > wrote:
> > > On Fri, 2015-03-06 at 10:00 -0500, Steven Rostedt wrote:
> > >> On Fri, 06 Mar 2015 15:18:42 +1100
On Fri, 6 Mar 2015 17:42:26 +0100
Christophe Leroy wrote:
> This patch adds talitos1.c and talitos1.h with all specificities needed
> to handle the SEC1 security engine found in MPC885 and MPC8272.
>
> The SEC1 has several differences with its younger brother SEC2:
> * Several bits in registers
On Mon, 2015-03-09 at 17:53 +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2015-03-07 at 19:19 +0800, Kevin Hao wrote:
> > It makes no sense to use a variant lock token on a platform which
> > doesn't support for shared-processor logical partitions. Actually we
> > can eliminate a memory load by us
On Thu, 2015-03-05 at 21:27 -0800, Nishanth Aravamudan wrote:
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 0257a7d659ef..0c1716cd271f 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -958,6 +958,13 @@ void __init initmem_init(void)
>
> memb
On Sun, Mar 08, 2015 at 08:40:25PM +, Mel Gorman wrote:
> > Because if the answer is 'yes', then we can safely say: 'we regressed
> > performance because correctness [not dropping dirty bits] comes before
> > performance'.
> >
> > If the answer is 'no', then we still have a mystery (and a re
On Sat, 2015-03-07 at 13:03 +0100, Yannick Guerrini wrote:
> Change 'prosessor' to 'processor'
> Change 'set_inteval' to 'set_interval'
>
> Signed-off-by: Yannick Guerrini
> ---
> drivers/ps3/ps3-lpm.c | 4 ++--
Looks good. Thanks for the fixes.
Acked-by: Geoff Levand
___
On Mon, Mar 9, 2015 at 9:19 AM, Russell King - ARM Linux
wrote:
> On Tue, Mar 03, 2015 at 06:10:15PM -0800, Kees Cook wrote:
>> To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
>> ASLR from mmap ASLR, as already done on s390. The architectures
>> that are already randomizing mma
On Wed, 4 Mar 2015 13:10:52 -0800
Kees Cook wrote:
> In preparation for moving ET_DYN randomization into the ELF loader (which
> requires a static ELF_ET_DYN_BASE), this redefines s390's existing ET_DYN
> randomization in a call to arch_mmap_rnd(). This refactoring results in
> the same ET_DYN r
On Wed, 4 Mar 2015 13:10:50 -0800
Kees Cook wrote:
> In preparation for splitting out ET_DYN ASLR, this refactors the use of
> mmap_rnd() to be used similarly to arm and x86, and extracts the checking
> of PF_RANDOMIZE.
>
> Signed-off-by: Kees Cook
> ---
> arch/s390/mm/mmap.c | 34 +++
On Mon, Mar 9, 2015 at 4:29 AM, Dave Chinner wrote:
>
>> Also, is there some sane way for me to actually see this behavior on a
>> regular machine with just a single socket? Dave is apparently running
>> in some fake-numa setup, I'm wondering if this is easy enough to
>> reproduce that I could see
On Tue, Mar 03, 2015 at 06:10:15PM -0800, Kees Cook wrote:
> To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
> ASLR from mmap ASLR, as already done on s390. The architectures
> that are already randomizing mmap (arm, arm64, mips, powerpc, s390,
> and x86), have their various for
Hi Wolfram,
On Sun, Mar 08, 2015 at 09:28:45AM +0100, Wolfram Sang wrote:
> On Wed, Feb 25, 2015 at 05:01:54PM +0100, Wolfram Sang wrote:
> > From: Wolfram Sang
> >
> > Signed-off-by: Wolfram Sang
>
> Hi Ludovic,
>
> if you have a few minutes, could you please test this series? I'd like to
>
On Mon, Mar 02, 2015 at 04:19:43PM -0800, Kees Cook wrote:
> To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
> ASLR from mmap ASLR, as already done on s390. The architectures
> that are already randomizing mmap (arm, arm64, mips, powerpc, s390,
> and x86), have their various for
On Mon, Mar 02, 2015 at 04:19:47PM -0800, Kees Cook wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 248d99cabaa8..e2f0ef9c6ee3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1,7 +1,6 @@
> config ARM
> bool
> default y
> - select ARCH_BINFMT_ELF_RAN
On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă wrote:
> On 3/3/2015 7:44 PM, Martin Hicks wrote:
>> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
>> wrote:
>>>
>>> For talitos, there are two cases:
>>>
>>> 1. request data size is <= data unit / sector size
>>> talitos can handle any IV / tweak sche
On Mon, Mar 02, 2015 at 04:19:45PM -0800, Kees Cook wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9f1f09a2bc9b..248d99cabaa8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -3,6 +3,7 @@ config ARM
> default y
> select ARCH_BINFMT_ELF_RANDOMIZE_PIE
>
On Mon, Mar 02, 2015 at 04:19:48PM -0800, Kees Cook wrote:
> diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
> index afb9cafd3786..c1ff8ab12914 100644
> --- a/arch/arm/include/asm/elf.h
> +++ b/arch/arm/include/asm/elf.h
> @@ -125,10 +125,6 @@ int dump_task_regs(struct task_str
On Mon, Mar 02, 2015 at 04:19:44PM -0800, Kees Cook wrote:
> In preparation for exporting per-arch mmap randomization functions,
> this moves the ASLR calculations for mmap on ARM into a separate routine.
>
> Signed-off-by: Kees Cook
Looks fine, thanks.
Acked-by: Russell King
> ---
> arch/ar
From: Geoff Thorpe
Signed-off-by: Geoff Thorpe
---
drivers/soc/fsl/Kconfig | 26 +-
drivers/soc/fsl/Makefile | 4 +
drivers/soc/fsl/bman_test.c | 2 +-
drivers/soc/fsl/{bman_test.c => qman_test.c} | 15 +-
drivers/soc/fsl/{bman_tes
From: Geoff Thorpe
Signed-off-by: Geoff Thorpe
---
drivers/soc/fsl/Kconfig|7 +
drivers/soc/fsl/Makefile |1 +
drivers/soc/fsl/qman_api.c | 58 ++
drivers/soc/fsl/qman_debugfs.c | 1325
drivers/soc/fsl/qman_priv.h|8 +
From: Geoff Thorpe
Signed-off-by: Geoff Thorpe
---
drivers/soc/fsl/Kconfig| 7 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/bman_api.c | 19 +++
drivers/soc/fsl/bman_debugfs.c | 118 +
drivers/soc/fsl/dpaa_sys.h | 1
From: Hai-Ying Wang
Signed-off-by: Hai-Ying Wang
---
drivers/soc/fsl/bman_portal.c | 45 ++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/bman_portal.c b/drivers/soc/fsl/bman_portal.c
index b06339a..60c966e 100644
--- a/dr
From: Hai-Ying Wang
Signed-off-by: Hai-Ying Wang
---
drivers/soc/fsl/qman_portal.c | 45 +++
1 file changed, 45 insertions(+)
diff --git a/drivers/soc/fsl/qman_portal.c b/drivers/soc/fsl/qman_portal.c
index c4b96cc..27372d4 100644
--- a/drivers/soc/fsl/q
From: Geoff Thorpe
Signed-off-by: Geoff Thorpe
---
drivers/soc/fsl/Kconfig| 26 +
drivers/soc/fsl/Makefile | 4 +
drivers/soc/fsl/bman_test.c| 55 +++
drivers/soc/fsl/bman_test.h| 43
drivers/soc/fsl/bman_test_api.c| 180 ++
v3: Addressed feedback from Kumar and Scott (partially, more in the next
round)
Moved public headers into include/soc/fsl and code into drivers/soc/fsl
Various clean-up
v2: Moved out of staging into soc/freescale
To do: Add a maintainer(s) entry
Add module(s) sup
From: Geoff Thorpe
Signed-off-by: Geoff Thorpe
---
arch/powerpc/Kconfig | 33 +++
arch/powerpc/configs/mpc85xx_defconfig| 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig| 1 +
arch/powerpc/platforms/85xx/Kconfig | 11 +
From: Geoff Thorpe
Signed-off-by: Geoff Thorpe
---
arch/powerpc/platforms/85xx/corenet_generic.c | 8 +++-
arch/powerpc/platforms/85xx/p1023_rdb.c | 8 +++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerp
On Monday 09 March 2015 11:56:22 Geert Uytterhoeven wrote:
> On Mon, Mar 9, 2015 at 11:50 AM, Geert Uytterhoeven
> wrote:
> > JFYI, when comparing v4.0-rc3[1] to v4.0-rc2[3], the summaries are:
> > - build errors: +18/-7
>
> + /home/kisskb/slave/src/arch/arm/mach-pxa/idp.c: error:
> 'SMC91X_N
Hi Arnd,
On Mon, Mar 9, 2015 at 3:10 PM, Arnd Bergmann wrote:
>> smc91x fallout. The lpd270_defconfig failure looks like not covered by
>> "ARM: fix typos in smc91x platform data" yet?
>
> It's not?
>
> This should be part of that patch:
>
> --- a/arch/arm/mach-pxa/lpd270.c
> +++ b/arch/arm/mach-
At the moment writing new TCE value to the IOMMU table fails with EBUSY
if there is a valid entry already. However PAPR specification allows
the guest to write new TCE value without clearing it first.
Another problem this patch is addressing is the use of pool locks for
external IOMMU users such a
At the moment only one group per container is supported.
POWER8 CPUs have more flexible design and allows naving 2 TCE tables per
IOMMU group so we can relax this limitation and support multiple groups
per container.
This adds TCE table descriptors to a container and uses iommu_table_group_ops
to
Before the IOMMU user would take control over the IOMMU table belonging to
a specific IOMMU group. This approach did not allow sharing tables between
IOMMU groups attached to the same container.
This introduces a new IOMMU ownership flavour when the user can not
just control the existing IOMMU tab
This changes few functions to receive a iommu_table_group pointer
rather than PE as they are going to be a part of upcoming
iommu_table_group_ops callback set.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 13 -
1 file changed, 8 insertions(+), 5
This adds a iommu_table_ops struct and puts pointer to it into
the iommu_table struct. This moves tce_build/tce_free/tce_get/tce_flush
callbacks from ppc_md to the new struct where they really belong to.
This adds the requirement for @it_ops to be initialized before calling
iommu_init_table() to m
This is a part of moving DMA window programming to an iommu_ops
callback.
This is a mechanical patch.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 85 ---
1 file changed, 56 insertions(+), 29 deletions(-)
diff --git a/arch/powe
The iommu_free_table helper release memory it is using (the TCE table and
@it_map) and release the iommu_table struct as well. We might not want
the very last step as we store iommu_table in parent structures.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/
The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
supposed to be called on IODA1/2 and not called on p5ioc2. It receives
start and end host addresses of TCE table. This approach makes it possible
to get pnv_pci_ioda_tce_invalidate() unintentionally called on p5ioc2.
Another issu
The existing implementation accounts the whole DMA window in
the locked_vm counter which is going to be even worse with multiple
containers and huge DMA windows.
This introduces 2 ioctls to register/unregister DMA memory which
receive user space address and size of a memory region which
needs to b
This replaces iommu_take_ownership()/iommu_release_ownership() calls
with the callback calls and it is up to the platform code to call
iommu_take_ownership()/iommu_release_ownership() if needed.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h| 4 +--
arch/powerpc/ke
This extends iommu_table_group_ops by a set of callbacks to support dynamic
DMA windows management.
query() returns IOMMU capabilities such as default DMA window address and
supported number of DMA windows and TCE table levels.
create_table() creates a TCE table with specific parameters.
it recei
This is a part of moving TCE table allocation into an iommu_ops
callback to support multiple IOMMU groups per one VFIO container.
This enforce window size to be a power of two.
This is a pretty mechanical patch.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c
Normally a bitmap from the iommu_table is used to track what TCE entry
is in use. Since we are going to use iommu_table without its locks and
do xchg() instead, it becomes essential not to put bits which are not
implied in the direction flag.
This adds iommu_direction_to_tce_perm() (its counterpar
This is a pretty mechanical patch to make next patches simpler.
New tce_iommu_unuse_page() helper does put_page() now but it might skip
that after the memory registering patch applied.
As we are here, this removes unnecessary checks for a value returned
by pfn_to_page() as it cannot possibly retu
This moves page pinning (get_user_pages_fast()/put_page()) code out of
the platform IOMMU code and puts it to VFIO IOMMU driver where it belongs
to as the platform code does not deal with page pinning.
This makes iommu_take_ownership()/iommu_release_ownership() deal with
the IOMMU table bitmap onl
This is to make extended ownership and multiple groups support patches
simpler for review.
This is a mechanical patch.
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/vfio_iommu_spapr_tce.c | 38 ++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
for TCE tables. Right now just one table is supported.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h| 18 +++--
arch
The existing IOMMU code takes/releases ownership over the existing IOMMU
tables created by the platform code, i.e. the tables remain in memory
all the time. Also, the existing IOMMU requires VFIO_IOMMU_ENABLE call to
start working as that's where we check the rlimit for locked pages.
New IOMMU wil
This replaces multiple calls of kzalloc_node() with a new
iommu_table_alloc() helper. Right now it calls kzalloc_node() but
later it will be modified to allocate a iommu_table_group struct with
a single iommu_table in it.
Later the helper will allocate a iommu_table_group struct which embeds
the i
At the moment the iommu_table struct has a set_bypass() which enables/
disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
which calls this callback when external IOMMU users such as VFIO are
about to get over a PHB.
The set_bypass() callback is not really an iommu_table functi
TCE tables might get too big in case of 4K IOMMU pages and DDW enabled
on huge guests (hundreds of GB of RAM) so the kernel might be unable to
allocate contiguous chunk of physical memory to store the TCE table.
To address this, POWER8 CPU (actually, IODA2) supports multi-level TCE tables,
up to 5
This adds create/remove window ioctls to create and remove DMA windows.
sPAPR defines a Dynamic DMA windows capability which allows
para-virtualized guests to create additional DMA windows on a PCI bus.
The existing linux kernels use this new window to map the entire guest
memory and switch to the
This adds missing locks in iommu_take_ownership()/
iommu_release_ownership().
This marks all pages busy in iommu_table::it_map in order to catch
errors if there is an attempt to use this table while ownership over it
is taken.
This only clears TCE content if there is no page marked busy in it_map
This moves iommu_table creation to the beginning. This is a mechanical
patch.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-
At the moment DMA map/unmap requests are handled irrespective to
the container's state. This allows the user space to pin memory which
it might not be allowed to pin.
This adds checks to MAP/UNMAP that the container is enabled, otherwise
-EPERM is returned.
Signed-off-by: Alexey Kardashevskiy
--
There moves locked pages accounting to helpers.
Later they will be reused for Dynamic DMA windows (DDW).
This reworks debug messages to show the current value and the limit.
This stores the locked pages number in the container so when unlocking
the iommu table pointer won't be needed. This does n
This makes use of the it_page_size from the iommu_table struct
as page size can differ.
This replaces missing IOMMU_PAGE_SHIFT macro in commented debug code
as recently introduced IOMMU_PAGE_XXX macros do not include
IOMMU_PAGE_SHIFT.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
This clears the TCE table when a container is being closed as this is
a good thing to leave the table clean before passing the ownership
back to the host kernel.
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/vfio_iommu_spapr_tce.c | 14 +++---
1 file changed, 11 insertions(+), 3 d
This checks that the TCE table page size is not bigger that the size of
a page we just pinned and going to put its physical address to the table.
Otherwise the hardware gets unwanted access to physical memory between
the end of the actual page and the end of the aligned up TCE page.
Since compoun
This enables sPAPR defined feature called Dynamic DMA windows (DDW).
Each Partitionable Endpoint (IOMMU group) has an address range on a PCI bus
where devices are allowed to do DMA. These ranges are called DMA windows.
By default, there is a single DMA window, 1 or 2GB big, mapped at zero
on a PC
On 3/6/2015 6:48 AM, Herbert Xu wrote:
> On Thu, Mar 05, 2015 at 11:35:23AM +0200, Horia Geantă wrote:
>>
>>> Only potential problem is getting the crypto API to set the GFP_DMA
>>> flag in the allocation request, but presumably a
>>> CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
>>
>> Ri
On Sun, Mar 08, 2015 at 11:35:59AM -0700, Linus Torvalds wrote:
> On Sun, Mar 8, 2015 at 3:02 AM, Ingo Molnar wrote:
> But:
>
> > As a second hack (not to be applied), could we change:
> >
> > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL
> >
> > to:
> >
> > #define _PAGE_BIT_PROTNONE (
On Mon, Mar 9, 2015 at 11:50 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.0-rc3[1] to v4.0-rc2[3], the summaries are:
> - build errors: +18/-7
+ /home/kisskb/slave/src/arch/arm/mach-pxa/idp.c: error:
'SMC91X_NOWAIT' undeclared here (not in a function): => 85:47
+ /home/kisskb/sl
On Fri, Mar 06, 2015 at 06:46:21PM -0600, Kim Phillips wrote:
> The current cryptodev-2.6 tree commits:
>
> d9850fc529ef ("crypto: powerpc/sha1 - kernel config")
> 50ba29aaa7b0 ("crypto: powerpc/sha1 - glue")
>
> failed to properly place files under arch/powerpc/crypto, which
> leads to build err
On 3/3/2015 7:44 PM, Martin Hicks wrote:
> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
> wrote:
>> On 3/3/2015 12:09 AM, Martin Hicks wrote:
>>>
>>> On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:
If crypto API allows to encrypt more sectors in one run
(handling IV int
On 3/7/2015 3:16 AM, Kim Phillips wrote:
> On Fri, 6 Mar 2015 11:49:43 -0500
> Martin Hicks wrote:
>
>> On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips
>> wrote:
>>> On Fri, 20 Feb 2015 12:00:10 -0500
>>> Martin Hicks wrote:
>>>
The newer talitos hardware has support for AES in XTS mode.
>>>
On 27.02.2015 22:54, Benjamin Herrenschmidt wrote:
On Fri, 2015-02-27 at 09:28 +0200, Purcareata Bogdan wrote:
Ping?
What is the ping for ?
Ben.
Making sure the patches are not lost on the mailing lists :) Didn't
receive any feedback on v4 and just wanted to check if there's anything
more
On Mon, 2015-03-09 at 09:13 +0800, Kevin Hao wrote:
> On Sun, Mar 08, 2015 at 08:13:26PM +1100, Benjamin Herrenschmidt wrote:
> > On Sat, 2015-03-07 at 19:14 +0800, Kevin Hao wrote:
> > > All the cache line size of the current book3e 64bit SoCs are 64 bytes.
> > > So we should use this size to alig
72 matches
Mail list logo
