Hi Greg, Ben,
On Wed, May 15, 2019 at 1:12 PM Greg Kroah-Hartman
wrote:
> From: Josh Poimboeuf
>
> commit 98af8452945c55652de68536afdde3b520fec429 upstream.
>
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users. It's getting mor
Hi Nicholas,
On Thu, May 16, 2019 at 04:13:17PM +1000, Nicholas Piggin wrote:
>
> > The motivation behind this patch was a HPC customer issue where they
> > were observing some CPUs in the core getting stuck at stop0_lite
> > state, thereby lowering the performance on the other CPUs of the core
From: Alexey Kardashevskiy
[ Upstream commit 345077c8e172c255ea0707214303ccd099e5656b ]
Guest physical to user address translation uses KVM memslots and reading
these requires holding the kvm->srcu lock. However recently introduced
kvmppc_tce_validate() broke the rule (see the lockdep warning be
From: Suraj Jitindar Singh
[ Upstream commit 7cb9eb106d7a4efab6bcf30ec9503f1d703c77f5 ]
There is a hardware bug in some POWER9 processors where a treclaim in
fake suspend mode can cause an inconsistency in the XER[SO] bit across
the threads of a core, the workaround being to force the core into
Different parts of the code do the limit check by ignoring the top nibble
of EA. ie. we do checks like
if ((ea & EA_MASK) >= H_PGTABLE_RANGE)
error
This patch makes sure we don't insert SLB entries for addresses whose top nibble
doesn't match the ignored bits.
With an ad
On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote:
> On Wed, May 15, 2019 at 3:04 AM Christian Brauner
> wrote:
> >
> > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> > pr
Hi
El mié., 15 may. 2019 5:17, Christophe Leroy
escribió:
> Hi,
>
> Le 15/05/2019 à 12:09, Christian Zigotzky a écrit :
> > Hi All,
> >
> > I got the following error messages with the latest Git kernel today:
> >
> > GEN .version
> >CHK include/generated/compile.h
> >LD vmli
Le 16/05/2019 à 04:30, Eric Biggers a écrit :
On Wed, May 15, 2019 at 08:49:48PM +0200, Christophe Leroy wrote:
Le 15/05/2019 à 16:05, Horia Geanta a écrit :
On 5/15/2019 3:29 PM, Christophe Leroy wrote:
Selftests report the following:
[2.984845] alg: skcipher: cbc-aes-talitos encryp
On 5/16/19 10:34 AM, Nicholas Piggin wrote:
Aneesh Kumar K.V's on May 14, 2019 4:02 pm:
Avoids confusion when printing Oops message like below
Faulting instruction address: 0xc008bdb4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=204
https://bugzilla.kernel.org/show_bug.cgi?id=203609
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.kernel.org/show_bug.cgi?id=203609
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
process that is created via traditional fork()/clone() calls that is only
referenced by a PID:
int pidfd = pidfd_open(1234, 0);
ret = pidfd_send_si
On Thu, May 16, 2019 at 04:03:27PM +0200, Jann Horn wrote:
> On Thu, May 16, 2019 at 3:08 PM Christian Brauner
> wrote:
> > On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote:
> > > On Wed, May 15, 2019 at 3:04 AM Christian Brauner
> > > wrote:
> > > >
> > > > This adds the pidfd
This adds testing for the new pidfd_open() syscalls. Specifically, we test:
- that no invalid flags can be passed to pidfd_open()
- that no invalid pid can be passed to pidfd_open()
- that a pidfd can be retrieved with pidfd_open()
- that the retrieved pidfd references the correct pid
Signed-off-b
Hello,
On power9 host, performing memory hotunplug from ppc64le guest results
in kernel oops.
Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
ppc64le_defconfig for host and ppc64le_guest_defconfig for guest.
Recreation steps:
1. Boot a guest with below mem configurati
On 05/16, Christian Brauner wrote:
>
> With the introduction of pidfds through CLONE_PIDFD it is possible to
> created pidfds at process creation time.
Now I am wondering why do we need CLONE_PIDFD, you can just do
pid = fork();
pidfd_open(pid);
> +SYSCALL_DEFINE2(pidfd_open, pid
"Aneesh Kumar K.V" writes:
> This makes sure we don't enable HugeTLB if the cache is not configured.
> I am still not sure about this. IMHO hugetlb support should be a hardware
> support derivative and any cache allocation failure should be handled as I did
> in the earlier patch. But then if we w
Hi Christian, David,
On Thu, May 16, 2019 at 4:00 PM Christian Brauner wrote:
> This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> process that is created via traditional fork()/clone() calls t
On 2019-05-16, Christian Brauner wrote:
> On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote:
> > On Wed, May 15, 2019 at 3:04 AM Christian Brauner
> > wrote:
> > > + if (pid <= 0)
> > > + return -EINVAL;
> >
> > WDYT of defining pid == 0 to mean "open myself"
On 2019-05-16, Oleg Nesterov wrote:
> On 05/16, Christian Brauner wrote:
> >
> > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > created pidfds at process creation time.
>
> Now I am wondering why do we need CLONE_PIDFD, you can just do
>
> pid = fork();
> p
On Thu, May 16, 2019 at 04:27:00PM +0200, Oleg Nesterov wrote:
> On 05/16, Christian Brauner wrote:
> >
> > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > created pidfds at process creation time.
>
> Now I am wondering why do we need CLONE_PIDFD, you can just do
>
>
On Thu, May 16, 2019 at 04:56:08PM +0200, Geert Uytterhoeven wrote:
> Hi Christian, David,
>
> On Thu, May 16, 2019 at 4:00 PM Christian Brauner
> wrote:
> > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> > pidfds for a process which did not get created via CLONE_P
On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov wrote:
> > On 05/16, Christian Brauner wrote:
> > >
> > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > created pidfds at process creation time.
> >
> > Now I am wondering why do we need CLONE_PIDFD, you c
On 2019-05-16, Oleg Nesterov wrote:
> On 05/17, Aleksa Sarai wrote:
> > On 2019-05-16, Oleg Nesterov wrote:
> > > On 05/16, Christian Brauner wrote:
> > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > created pidfds at process creation time.
> > >
> > > Now I am
On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at
On Thu, May 16, 2019 at 05:22:53PM +0200, Oleg Nesterov wrote:
> On 05/17, Aleksa Sarai wrote:
> >
> > On 2019-05-16, Oleg Nesterov wrote:
> > > On 05/17, Aleksa Sarai wrote:
> > > > On 2019-05-16, Oleg Nesterov wrote:
> > > > > On 05/16, Christian Brauner wrote:
> > > > > > With the introduction
VMX ghash was using a fallback that did not support interleaving simd
and nosimd operations, leading to failures in the extended test suite.
If I understood correctly, Eric's suggestion was to use the same
data format that the generic code uses, allowing us to call into it
with the same contexts.
On Thu, 16 May 2019 at 17:40, Daniel Axtens wrote:
>
> VMX ghash was using a fallback that did not support interleaving simd
> and nosimd operations, leading to failures in the extended test suite.
>
> If I understood correctly, Eric's suggestion was to use the same
> data format that the generic
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Josh Poimboeuf
commit d68be4c4d31295ff6ae34a8ddfaa4c1a8ff42812 upstream.
Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'mitigations=' cmdline option. This affec
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Anton Blanchard
commit 55dd0df781e58ec23d218376ea4a676e7362a98c upstream.
Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
Since these are kernel only headers, we don't need #ifd
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Josh Poimboeuf
commit 98af8452945c55652de68536afdde3b520fec429 upstream.
Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users. It
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Anton Blanchard
commit c0ccf6f99e3a43b87980c9df7da48427885206d0 upstream.
To use jump labels in assembly we need the HAVE_JUMP_LABEL
define, so we select a fallback version if the toolchain do
The patch
ASoC: fsl_asrc: Fix the issue about unsupported rate
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hour
The patch
ASoC: fsl_asrc: replace the process_option table with function
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the ne
Nicholas Piggin wrote:
Naveen N. Rao's on May 14, 2019 6:32 pm:
Michael Ellerman wrote:
"Naveen N. Rao" writes:
Michael Ellerman wrote:
Nicholas Piggin writes:
The new mprofile-kernel mcount sequence is
mflr r0
bl_mcount
Dynamic ftrace patches the branch instruction with a noop,
Tyrel Datwyler writes:
> The current dlpar_cpu_readd() takes in a cpu_id and uses that to look up
> the cpus device_node so that we can get at the ibm,my-drc-index
> property. The only user of cpu readd is an OF notifier call back. This
> call back already has a reference to the device_node and th
On 4/22/19 8:49 PM, Masahiro Yamada wrote:
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for s390, the following error is reported:
In file included from arch/s390/crypto/des_s390.c:19:
./arch/s390/i
Daniel Axtens writes:
> VMX ghash was using a fallback that did not support interleaving simd
> and nosimd operations, leading to failures in the extended test suite.
>
> If I understood correctly, Eric's suggestion was to use the same
> data format that the generic code uses, allowing us to call
Michael Ellerman writes:
> Daniel Axtens writes:
>> VMX ghash was using a fallback that did not support interleaving simd
>> and nosimd operations, leading to failures in the extended test suite.
>>
>> If I understood correctly, Eric's suggestion was to use the same
>> data format that the gener
On 05/15/2019 06:24 AM, Daniel Axtens wrote:
The kernel self-tests picked up an issue with CTR mode:
alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3,
cfg="uneven misaligned splits, may sleep"
Test vector 3 has an IV of FFFD, so
aft
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
Signed-
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. And is user's responsibility to identify if this
wakeup source he is inter
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are Little
Endian. So add this optional property to help identify them.
Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.
There is chip errata ERR008000, the reference doc is
(https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf),
The issue is "While using ESAI transmit or receive and
an underrun/overrun happens, channel swap may occur.
The only recovery mechanism is to reset the ESAI."
In this commit add a tasklet to ha
Hello,
Nicholas Piggin writes:
> Christophe Leroy's on May 16, 2019 2:47 pm:
>>
>>
>> Le 16/05/2019 à 04:04, Nicholas Piggin a écrit:
>>> Radix boot looks like this:
>>>
>>> -
>>> phys_mem_size = 0x2
>>> dcache_bsize
Hi Arnd,
-Original Message-
From: Arnd Bergmann
Sent: 2019年5月15日 16:05
To: Xiaowei Bao
Cc: Bjorn Helgaas ; Rob Herring ; Mark
Rutland ; Shawn Guo ; Leo Li
; Kishon ; Lorenzo Pieralisi
; gregkh ; M.h. Lian
; Mingkai Hu ; Roy Zang
; Kate Stewart ; Philippe
Ombredanne ; Shawn Lin ;
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are Little
Endian. So add this optional property to help identify them.
Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. And is user's responsibility to identify if this
wakeup source he is inter
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
Signed-
On 5/16/19 8:17 PM, Michael Ellerman wrote:
"Aneesh Kumar K.V" writes:
This makes sure we don't enable HugeTLB if the cache is not configured.
I am still not sure about this. IMHO hugetlb support should be a hardware
support derivative and any cache allocation failure should be handled as I did
Hi Laura,
On Fri, May 17, 2019 at 7:55 AM Laura Abbott wrote:
> What gcc version was this tested with?
I use kernel.org toolchains
https://mirrors.edge.kernel.org/pub/tools/crosstool/
It is GCC 8.1
> We're still seeing errors on
> Fedora rawhide with gcc 9.1.1 on a version
> (8c05f3b965da1
On Fri, May 17, 2019 at 8:01 AM Laura Abbott wrote:
>
> On 4/22/19 8:49 PM, Masahiro Yamada wrote:
> > This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
> > place. We need to eliminate potential issues beforehand.
> >
> > If it is enabled for s390, the following error is reported
On Fri, May 17, 2019 at 10:32:12AM +1000, Daniel Axtens wrote:
>
> Yes, I think that's the right fixes tag. Not quite sure how I managed to
> miss that! Herbert, I assume this will go via your tree: do you want me
> to send a v2 with the tag or are you OK to just add that in when you
> merge it?
I
On Fri, May 17, 2019 at 01:40:02AM +1000, Daniel Axtens wrote:
> VMX ghash was using a fallback that did not support interleaving simd
> and nosimd operations, leading to failures in the extended test suite.
>
> If I understood correctly, Eric's suggestion was to use the same
> data format that th
On Wed, May 15, 2019 at 08:24:50PM +1000, Daniel Axtens wrote:
> The kernel self-tests picked up an issue with CTR mode:
> alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test
> vector 3, cfg="uneven misaligned splits, may sleep"
>
> Test vector 3 has an IV of F
55 matches
Mail list logo
