Mon, Mar 02, 2015 at 06:56:12PM CET, tlfal...@linux.vnet.ibm.com wrote:
Add a function that will enable changing the MAC address
of an ibmveth interface while it is still running.
Signed-off-by: Thomas Falcon tlfal...@linux.vnet.ibm.com
Reviewed-by: Jiri Pirko j...@resnulli.us
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 internally) dmcrypt can be modified of course.
But do not forget we can use another IV (not only sequential number)
I was testing dm-crypt performance with a Freescale P1022 board with
a recent kernel and was getting IO errors while doing testing with LUKS.
Investigation showed that all hardware FIFO slots were filling and
the driver was returning EAGAIN to the block layer, which is not an
expected response
The submission count was off by one.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 89cf4d5..7709805 100644
--- a/drivers/crypto/talitos.c
This is properly defined in the md5 header file.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c49d977..89cf4d5 100644
---
I was running into situations where the hardware FIFO was filling up, and
the code was returning EAGAIN to dm-crypt and just dropping the submitted
crypto request.
This adds support in talitos for a software backlog queue. When requests
can't be queued to the hardware immediately EBUSY is
There were multiple loops in a row, for each separate step of the
initialization of the channels. Simplify to a single loop.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
This is preparatory work for moving to using the crypto async queue
handling code. A talitos_request structure is buried into each
talitos_edesc so that when talitos_submit() is called, everything required
to defer the submission to the hardware is contained within talitos_edesc.
Signed-off-by:
On Thu, Feb 26, 2015 at 05:11:42PM +0100, Christophe Leroy wrote:
On CPM2, the SPI parameter RAM is dynamically allocated in the dualport RAM
whereas in CPM1, it is statically allocated to a default address with
capability to relocate it somewhere else via the use of CPM micropatch.
The
From: Thomas Falcon tlfal...@linux.vnet.ibm.com
Date: Mon, 2 Mar 2015 11:56:12 -0600
Add a function that will enable changing the MAC address
of an ibmveth interface while it is still running.
Signed-off-by: Thomas Falcon tlfal...@linux.vnet.ibm.com
Applied, thanks.
On Mon, Mar 2, 2015 at 11:31 PM, Ingo Molnar mi...@kernel.org wrote:
* Kees Cook keesc...@chromium.org 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,
On Tue, Mar 3, 2015 at 12:30 AM, Ingo Molnar mi...@kernel.org wrote:
* Kees Cook keesc...@chromium.org wrote:
Most architectures don't need to do anything special for the strict
seccomp syscall entries. Remove the redundant headers and reduce the
others.
19 files changed, 27
On 03/02/2015 10:24 PM, Michael Ellerman wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
Traditionally after a migration operation drmgr has coordinated the device
tree
update with the kernel in userspace via the ugly /proc/ppc64/ofdt interface.
This
can be better done
On 03/02/2015 10:15 PM, Michael Ellerman wrote:
On Mon, 2015-03-02 at 13:30 -0800, Tyrel Datwyler wrote:
On 03/01/2015 08:19 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
During suspend/migration operation we must wait for the VASI state reported
by the
The SATA implementation based on two actually different devices, i.e. SATA and
DMA controllers.
For Synopsys DesignWare DMA we have already a generic implementation of the
driver. Thus, the patch 1/2 converts the code to use DMAEngine framework and
dw_dmac driver.
In future it will be better to
On 03/02/2015 10:10 PM, Michael Ellerman wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
This patchset simplifies the usage of rtas_ibm_suspend_me() by removing an
extraneous function parameter, fixes device tree updating on little endian
platforms, and adds a mechanism for
This patch re-uses hsdev-dev which is allocated on heap. Therefore, the
private structure, which is global variable, is reduced by one field.
In one case ap-dev is used and there it seems to be right decision.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
The SATA implementation based on two actually different devices, i.e. SATA and
DMA controllers.
For Synopsys DesignWare DMA we have already a generic implementation of the
driver. Thus, the patch converts the code to use DMAEngine framework and
dw_dmac driver.
In future it will be better to
Hi Scott,
I sent V3 of this patch a few days ago.
Comments are welcome.
Thanks.
-Hongtao
-Original Message-
From: Jia Hongtao [mailto:hongtao@freescale.com]
Sent: Thursday, February 26, 2015 3:23 PM
To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; asolo...@kb.kras.ru
Cc:
On Tue, 3 Mar 2015 08:21:35 -0500
Martin Hicks m...@bork.org wrote:
The submission count was off by one.
Signed-off-by: Martin Hicks m...@bork.org
---
sadly, this directly contradicts:
commit 4b24ea971a93f5d0bec34bf7bfd0939f70cfaae6
Author: Vishnu Suresh vis...@freescale.com
Date: Mon
On 03/03/2015 05:20 PM, Cyril Bur wrote:
On Tue, 2015-03-03 at 15:15 -0800, Tyrel Datwyler wrote:
On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
On 03/01/2015 09:20 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the
On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
On 03/01/2015 09:20 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
On Tue, 2015-03-03 at 15:15 -0800, Tyrel Datwyler wrote:
On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
On 03/01/2015 09:20 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the kernel after resuming
from a suspend
On Tue, 3 Mar 2015 08:21:37 -0500
Martin Hicks m...@bork.org wrote:
@@ -1170,6 +1237,8 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
edesc-dma_len,
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86.
Signed-off-by: Kees Cook keesc...@chromium.org
---
Can mmap ASLR be safely enabled in the legacy mmap case here? Other archs
use mm-mmap_base = TASK_UNMAPPED_BASE +
When we size VF BAR0, VF BAR1, etc., from the SR-IOV Capability of a PF, we
learn the alignment requirement and amount of space consumed by a single
VF. But when VFs are enabled, *each* of the NumVFs consumes that amount of
space, so the total size of the PF resource is VF BAR size * NumVFs.
Add
From: Bjorn Helgaas bhelg...@google.com
If we don't have space for all the bus numbers required to enable VFs,
print the largest bus number required and the range available.
No functional change; improved error message only.
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
Per the SR-IOV spec r1.1, sec 3.3.14, the required alignment of a PF's IOV
BAR is the size of an individual VF BAR, and the size consumed is the
individual VF BAR size times NumVFs.
The PowerNV platform has additional alignment requirements to help support
its Partitionable Endpoint device
When sizing and assigning resources, we divide the resources into two
lists: the requested list and the additional list. We don't consider the
alignment of additional VF(n) BAR space.
This is reasonable because the alignment required for the VF(n) BAR space
is the size of an individual VF BAR,
The PCI config accessors previously relied on device_node. Unfortunately,
VFs don't have a corresponding device_node, so change the accessors to use
pci_dn instead.
[bhelgaas: changelog]
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14
Current iommu_table of a PE is a static field. This will have a problem
when iommu_free_table() is called.
Allocate iommu_table dynamically.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/iommu.h |3 +++
arch/powerpc/platforms/powernv/pci-ioda.c |
In preparation for splitting out ET_DYN ASLR, extract the mmap ASLR
selection into a separate function.
Signed-off-by: Kees Cook keesc...@chromium.org
---
arch/mips/mm/mmap.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/mips/mm/mmap.c
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 keesc...@chromium.org
---
arch/s390/mm/mmap.c | 34 +++---
1 file changed, 23
This fixes the offset2lib weakness in ASLR for arm, arm64, mips,
powerpc, and x86. The problem is that if there is a leak of ASLR from
the executable (ET_DYN), it means a leak of shared library offset as
well (mmap), and vice versa. Further details and a PoC of this attack
is available here:
* Kees Cook keesc...@chromium.org wrote:
On Mon, Mar 2, 2015 at 11:31 PM, Ingo Molnar mi...@kernel.org wrote:
* Kees Cook keesc...@chromium.org wrote:
To address the offset2lib ASLR weakness[1], this separates ET_DYN
ASLR from mmap ASLR, as already done on s390. The architectures
This patchset enables the SRIOV on POWER8.
The gerneral idea is put each VF into one individual PE and allocate required
resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
allocation and adjustment for PF's IOV BAR.
On P8, we use M64BT to cover a PF's IOV BAR, which could make
In preparation for splitting out ET_DYN ASLR, this moves the ASLR calculations
for mmap on ARM into a separate routine, similar to x86. This also removes
the redundant check of personality (PF_RANDOMIZE is already set before calling
arch_pick_mmap_layout).
Signed-off-by: Kees Cook
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm, and extracts the checking of
PF_RANDOMIZE.
Signed-off-by: Kees Cook keesc...@chromium.org
---
arch/x86/mm/mmap.c | 36
1 file changed, 20
When an architecture fully supports randomizing the ELF load location,
a per-arch mmap_rnd() function is used to find a randomized mmap base.
In preparation for randomizing the location of ET_DYN binaries
separately from mmap, this renames and exports these functions as
arch_mmap_rnd().
On Mon, 2015-03-02 at 16:19 -0800, Kees Cook wrote:
This fixes the offset2lib weakness in ASLR for arm, arm64, mips,
powerpc, and x86. The problem is that if there is a leak of ASLR from
the executable (ET_DYN), it means a leak of shared library offset as
well (mmap), and vice versa. Further
The First VF Offset and VF Stride fields depend on the NumVFs setting, so
refresh the cached fields in struct pci_sriov when updating NumVFs. See
the SR-IOV spec r1.1, sec 3.3.9 and 3.3.10.
[bhelgaas: changelog, remove kernel-doc comment marker]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
An SR-IOV device can change its First VF Offset and VF Stride based on the
values of ARI Capable Hierarchy and NumVFs. The number of buses required
for all VFs is determined by NumVFs, First VF Offset, and VF Stride (see
SR-IOV spec r1.1, sec 2.1.2).
Previously pci_iov_bus_range() computed how
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files
When IOV BAR is big, each is covered by 4 M64 windows. This leads to
several VF PE sits in one PE in terms of M64.
Group VF PEs according to the M64 allocation.
[bhelgaas: use dev_printk() when possible]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
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 randomization on s390.
Signed-off-by: Kees Cook
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 forms of arch_mmap_rnd() made available
via the new
On Tue, Feb 24, 2015 at 03:00:37AM -0600, Bjorn Helgaas wrote:
On Tue, Feb 24, 2015 at 02:34:57AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
On PowerNV platform, resource position in M64 implies the PE# the resource
belongs to. In some cases, adjustment of a
On PowerNV, some resource reservation is needed for SR-IOV VFs that don't
exist at the bootup stage. To do the match between resources and VFs, the
code need to get the VF's BDF in advance.
Rename virtfn_bus() and virtfn_devfn() to pci_iov_virtfn_bus() and
pci_iov_virtfn_devfn() and export them.
From: Gavin Shan gws...@linux.vnet.ibm.com
pci_dn is the extension of PCI device node and is created from device node.
Unfortunately, VFs are enabled dynamically by PF's driver and they don't
have corresponding device nodes, and pci_dn. Refactor pci_dn to support
VFs:
* pci_dn is organized
Flag PCI_REASSIGN_ALL_RSRC is used to ignore resources information setup by
firmware, so that kernel would re-assign all resources of pci devices.
On powerpc arch, this happens in a header fixup function
pcibios_fixup_resources(), which will clean up the resources if this flag
is set. This works
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86. This additionally enables
mmap ASLR on legacy mmap layouts, which appeared to be missing on arm64,
and was already supported on arm. Additionally removes a copy/pasted
The arch_randomize_brk() function is used on several architectures,
even those that don't support ET_DYN ASLR. To avoid bulky extern/#define
tricks, consolidate the support under CONFIG_ARCH_HAS_ELF_RANDOMIZE for
the architectures that support it, while still handling CONFIG_COMPAT_BRK.
Hi Linus,
Please pull some powerpc fixes for 4.0:
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-4.0-2
From: Bjorn Helgaas bhelg...@google.com
Most of PCI uses res = dev-resource[i], not res = dev-resource + i.
Use that style in iov.c also.
No functional change.
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c |8
1 file changed, 4 insertions(+), 4
On PowerNV platform, resource position in M64 implies the PE# the resource
belongs to. In some cases, adjustment of a resource is necessary to locate
it to a correct position in M64.
Add pnv_pci_vf_resource_shift() to shift the 'real' PF IOV BAR address
according to an offset.
[bhelgaas: rework
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this
will exceed the limitation and failed to be assigned.
Introduce a different mechanism based on the IOV BAR size:
- if IOV BAR size is smaller than 64MB, expand to total_pe
- if IOV BAR size is bigger than 64MB, roundup
On Mon, 2015-03-02 at 09:42 -0600, Emil Medve wrote:
On 03/02/2015 09:32 AM, Emil Medve wrote:
From: Igal Liberman igal.liber...@freescale.com
Describe the PHY topology for all configurations supported by each board
Based on prior work by Andy Fleming aflem...@gmail.com
Currently we don't store the individual VF BAR size. We calculate it when
needed by dividing the PF's IOV resource size (which contains space for
*all* the VFs) by total_VFs or by reading the BAR in the SR-IOV capability
again.
Keep the individual VF BAR size in struct pci_sriov.barsz[], add
VFs are dynamically created when a driver enables them. On some platforms,
like PowerNV, special resources are necessary to enable VFs.
Add platform hooks for enabling and disabling VFs.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
drivers/pci/iov.c | 19 +++
1 file
Implement pcibios_iov_resource_alignment() on powernv platform.
On PowerNV platform, there are 3 cases for the IOV BAR:
1. initial state, the IOV BAR size is multiple times of VF BAR size
2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
3. sizing stage, the IOV BAR is
On PHB3, PF IOV BAR will be covered by M64 window to have better PE
isolation. The total_pe number is usually different from total_VFs, which
can lead to a conflict between MMIO space and the PE number.
For example, if total_VFs is 128 and total_pe is 256, the second half of
M64 window will be
In order to enable SRIOV on PowerNV platform, the PF's IOV BAR needs to be
adjusted:
1. size expanded
2. aligned to M64BT size
This patch documents this change on the reason and how.
[bhelgaas: reformat, clarify, expand]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
horia.gea...@freescale.com 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 internally) dmcrypt can be modified of
Internally, of_find_node_by_name() calls of_node_put() on its from
parameter, which must not be done on master, as it's still in use, and
will be released manually later. This may cause a zero kref refcount.
Call of_node_get() before to compensate for this.
Signed-off-by: Geert Uytterhoeven
* Kees Cook keesc...@chromium.org wrote:
Most architectures don't need to do anything special for the strict
seccomp syscall entries. Remove the redundant headers and reduce the
others.
19 files changed, 27 insertions(+), 137 deletions(-)
Lovely cleanup factor.
Just to make sure, are you
65 matches
Mail list logo
