Moves struct talitos_edesc into talitos.h so that it can be used
from any place in talitos.c
It will be required for next patch ("crypto: talitos - fix hash
on SEC1")
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
drivers/crypto/talitos.c | 30 --
dri
icv_ool is not used anymore, drop it.
Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/tali
All mapping iterator logic is based on the assumption that sg->offset
is always lower than PAGE_SIZE.
But there are situations where sg->offset is such that the SG item
is on the second page. In that case sg_copy_to_buffer() fails
properly copying the data into the buffer. One of the reason is
tha
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[3.385197] bus: 'platform': really_probe: probing driver talitos with
device ff02.crypto
[3
On SEC1, hash provides wrong result when performing hashing in several
steps with input data SG list has more than one element. This was
detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector
6, cfg="random: may_sleep use_f
On Mon, 24 Jun 2019, Christoph Hellwig wrote:
>
> asm-generic/ptrace.h is a little weird in that it doesn't actually
> implement any functionality, but it provided multiple layers of macros
> that just implement trivial inline functions. We implement those
> directly in the few architectures and
On Mon, 24 Jun 2019, Christoph Hellwig wrote:
> Doing the indirection through macros for the regs accessors just
> makes them harder to read, so implement the helpers directly.
>
> Note that only the helpers actually used are implemented now.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Ing
Nicholas Piggin writes:
> Segher Boessenkool's on June 23, 2019 10:03 pm:
>> On Sun, Jun 23, 2019 at 08:41:51PM +1000, Nicholas Piggin wrote:
>>> This makes it clear to the caller that it can only be used on POWER9
>>> and later CPUs.
>>
>>> -#define PPC_INVALIDATE_ERATPPC_SLBIA(7)
>>> +#
Michael Neuling writes:
> When emulating tsr, treclaim and trechkpt, we incorrectly set CR0. The
> code currently sets:
> CR0 <- 00 || MSR[TS]
> but according to the ISA it should be:
> CR0 <- 0 || MSR[TS] || 0
Seems bad, what's the worst case impact?
Do we have a test case for this?
>
Latest -next fails to boot on POWER9 PowerVM LPAR due to RCU stalls.
This problem was introduced with next-20190620 (dc636f5d78).
next-20190619 was last good kernel.
Reverting following commit allows the kernel to boot.
2fd4aeea6b603 : mm/memory_hotplug: move and simplify walk_memory_blocks()
[
If an ocxl device is unbound through sysfs at the same time its AFU is
being opened by a user process, the open code may dereference freed
stuctures, which can lead to kernel oops messages. You'd have to hit a
tiny time window, but it's possible. It's fairly easy to test by
making the time window b
On 24.06.19 16:09, Sachin Sant wrote:
> Latest -next fails to boot on POWER9 PowerVM LPAR due to RCU stalls.
>
> This problem was introduced with next-20190620 (dc636f5d78).
> next-20190619 was last good kernel.
>
> Reverting following commit allows the kernel to boot.
> 2fd4aeea6b603 : mm/memory
The Linux kernel for powerpc since 4.17 has a bug where unrelated processes may
be able to read/write to each other's virtual memory under certain conditions.
This bug only affects machines using 64-bit CPUs with the hash page table MMU,
see below for more detail on affected CPUs.
To trigger the
The new hcall named H_SCM_UNBIND_ALL has been introduce that can
unbind all the memory drc memory-blocks assigned to an lpar. This is
more efficient than using H_SCM_UNBIND_MEM as currently we don't
support partial unbind of drc memory-blocks.
Hence this patch proposes following changes to drc_pme
Presently an error is returned in response to hcall H_SCM_BIND_MEM when a
new kernel boots on lpar via kexec. This prevents papr_scm from registering
drc memory regions with nvdimm. The error reported is of the form below:
"papr_scm ibm,persistent-memory:ibm,pmemory@4412: bind err: -68"
On in
In some cases initial bind of scm memory for an lpar can fail if
previously it wasn't released using a scm-unbind hcall. This situation
can arise due to panic of the previous kernel or forced lpar reset. In
such cases the H_SCM_BIND_MEM return a H_OVERLAP error.
To mitigate such cases the patch up
Le 24/06/2019 à 17:24, Greg Kurz a écrit :
On Mon, 24 Jun 2019 16:41:48 +0200
Frederic Barrat wrote:
If an ocxl device is unbound through sysfs at the same time its AFU is
being opened by a user process, the open code may dereference freed
stuctures, which can lead to kernel oops messages.
On Mon, 24 Jun 2019 17:39:26 +0200
Frederic Barrat wrote:
> Le 24/06/2019 à 17:24, Greg Kurz a écrit :
> > On Mon, 24 Jun 2019 16:41:48 +0200
> > Frederic Barrat wrote:
> >
> >> If an ocxl device is unbound through sysfs at the same time its AFU is
> >> being opened by a user process, the ope
On Mon, 24 Jun 2019 16:41:48 +0200
Frederic Barrat wrote:
> If an ocxl device is unbound through sysfs at the same time its AFU is
> being opened by a user process, the open code may dereference freed
> stuctures, which can lead to kernel oops messages. You'd have to hit a
> tiny time window, but
On 2019-06-21 00:05, Nathan Lynch wrote:
The protocol for suspending or migrating an LPAR requires all present
processor threads to enter H_JOIN. So if we have threads offline, we
have to temporarily bring them up. This can race with administrator
actions such as SMT state changes. As of dfd718a2
> On 24-Jun-2019, at 8:12 PM, David Hildenbrand wrote:
>
> On 24.06.19 16:09, Sachin Sant wrote:
>> Latest -next fails to boot on POWER9 PowerVM LPAR due to RCU stalls.
>>
>> This problem was introduced with next-20190620 (dc636f5d78).
>> next-20190619 was last good kernel.
>>
>> Reverting f
Hi Mingming,
mmc writes:
> On 2019-06-21 00:05, Nathan Lynch wrote:
>> So return -EAGAIN instead of -EBUSY when this race is
>> encountered. Additionally: logging this event is still appropriate but
>> use pr_info instead of pr_err; and remove use of unlikely() while here
>> as this is not a hot
Hello Jessica,
AFAIK Mimi is happy with this patch set, but I still need acks from
maintainers of other subsystems that my changes touch before she can
accept it.
Is this patch OK from your PoV?
--
Thiago Jung Bauermann
IBM Linux Technology Center
Thiago Jung Bauermann writes:
> IMA will u
Hello David,
AFAIK Mimi is happy with this patch set, but I still need acks from
maintainers of other subsystems that my changes touch before she can
accept it.
Are this patch and the next one ("PKCS#7: Introduce pkcs7_get_digest()")
OK from your PoV?
--
Thiago Jung Bauermann
IBM Linux Technol
On Mon, Jun 24, 2019 at 07:47:28AM +0200, Christoph Hellwig wrote:
> No one is using this header anymore.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Arnd Bergmann
> Acked-by: Oleg Nesterov
> ---
> MAINTAINERS| 1 -
> arch/mips/include/asm/ptrace.h | 5 ---
> include
Hi,
On Thu, Jun 20, 2019 at 02:02:21PM +0800, Herbert Xu wrote:
> On Mon, Jun 17, 2019 at 09:15:02PM +, Christophe Leroy wrote:
> > All mapping iterator logic is based on the assumption that sg->offset
> > is always lower than PAGE_SIZE.
> >
> > But there are situations where sg->offset is su
>From 1bd2bf7146876e099eafb292668f9a12dc22f526 Mon Sep 17 00:00:00 2001
From: Juliet Kim
Date: Mon, 24 Jun 2019 17:17:46 -0400
Subject: [PATCH 1/1] powerpc/rtas: Fix hang in race against concurrent cpu
offline
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8b
Anshuman Khandual's on June 24, 2019 4:52 pm:
>
>
> On 06/23/2019 03:14 PM, Nicholas Piggin wrote:
>> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
>> Whether or not a vmap is huge depends on the architecture details,
>> alignments, boot options, etc., which the caller can
On Tue, Jun 25, 2019 at 1:03 AM Vaibhav Jain wrote:
>
> The new hcall named H_SCM_UNBIND_ALL has been introduce that can
> unbind all the memory drc memory-blocks assigned to an lpar. This is
> more efficient than using H_SCM_UNBIND_MEM as currently we don't
> support partial unbind of drc memory-
There's some concern this could retry forever, resulting in live lock.
Another approach would be to abandon the attempt and fail the LPM
request.
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-June/192531.html
On 6/24/19 12:23 PM, Nathan Lynch wrote:
Hi Mingming,
mmc writes:
On 2019
On Mon, Jun 24, 2019 at 08:35:33PM +0300, Imre Deak wrote:
> Hi,
>
> On Thu, Jun 20, 2019 at 02:02:21PM +0800, Herbert Xu wrote:
> > On Mon, Jun 17, 2019 at 09:15:02PM +, Christophe Leroy wrote:
> > > All mapping iterator logic is based on the assumption that sg->offset
> > > is always lower t
On Tue, Jun 25, 2019 at 12:59 AM Vaibhav Jain wrote:
>
> In some cases initial bind of scm memory for an lpar can fail if
> previously it wasn't released using a scm-unbind hcall. This situation
> can arise due to panic of the previous kernel or forced lpar reset. In
> such cases the H_SCM_BIND_ME
Michael Neuling writes:
> commit 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE
> interrupt controller") added an option to turn off Linux native XIVE
> usage via the xive=off kernel command line option.
>
> This documents this option.
>
> Signed-off-by: Michael Neuling
Acked-by: S
On Mon, 2019-06-24 at 21:48 +1000, Michael Ellerman wrote:
> Michael Neuling writes:
> > When emulating tsr, treclaim and trechkpt, we incorrectly set CR0. The
> > code currently sets:
> > CR0 <- 00 || MSR[TS]
> > but according to the ISA it should be:
> > CR0 <- 0 || MSR[TS] || 0
>
> Se
On 5/6/19 9:15 pm, Frederic Barrat wrote:
From: Alastair D'Silva
The OpenCAPI discovery and configuration specification has been
updated and introduces version 1.1 of the AFU descriptor template,
with new fields to better define the memory layout of an OpenCAPI
adapter.
The ocxl driver doesn't
35 matches
Mail list logo
