Hi
Le 24/05/2019 à 00:23, Aaro Koskinen a écrit :
Hi,
On Thu, May 23, 2019 at 08:58:11PM +0200, Christophe Leroy wrote:
Le 23/05/2019 à 19:27, Aaro Koskinen a écrit :
On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote:
Ok, the Oops confirms that the error is due to executing
The first machines to ship with OPAL firmware all got firmware updates
that have the new call, but just in case someone is foolish enough to
believe the first 4 months of firmware is the best, we keep this code
around.
Comment is updated to not refer to late 2014 as recent or the future.
Xmon should be either fully or partially disabled depending on the
kernel lockdown state.
Put xmon into read-only mode for lockdown=integrity and completely
disable xmon when lockdown=confidentiality. Xmon checks the lockdown
state and takes appropriate action:
(1) during xmon_setup to prevent
Matthias, ping? Any suggestions?
Thanks,
Pingfan
On Thu, May 2, 2019 at 2:22 PM Pingfan Liu wrote:
>
> On Thu, Apr 25, 2019 at 4:20 PM Pingfan Liu wrote:
> >
> > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
> > >
> > >
> > [...]
> > > > @@ -139,6 +141,8 @@ static int __init
Add support for disabling the kernel implemented spectre v2 mitigation
(count cache flush on context switch) via the nospectre_v2 and
mitigations=off cmdline options.
Suggested-by: Michael Ellerman
Signed-off-by: Christopher M. Riedl
Reviewed-by: Andrew Donnellan
---
v4->v5:
Fix
When there are more than one implementation of the NMI watchdog, there may
be situations in which switching from one to another is needed (e.g., if
the time-stamp counter becomes unstable, the HPET-based NMI watchdog can
no longer be used.
The perf-based implementation of the hardlockup detector
The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).
Group and wrap in #ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
The procedure to detect hardlockups is independent of the underlying
mechanism that generates the non-maskable interrupt used to drive the
detector. Thus, it can be put in a separate, generic function. In this
manner, it can be invoked by various implementations of the NMI watchdog.
For this
On Thu, May 23, 2019 at 11:04:03AM +, S.j. Wang wrote:
> > On Thu, May 23, 2019 at 09:53:42AM +, S.j. Wang wrote:
> > > > > + /*
> > > > > + * Add fifo reset here, because the regcache_sync will
> > > > > + * write one more data to ETDR.
> > > > > + * Which will cause
Hi,
On Thu, May 23, 2019 at 08:58:11PM +0200, Christophe Leroy wrote:
> Le 23/05/2019 à 19:27, Aaro Koskinen a écrit :
> >On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote:
> >>Ok, the Oops confirms that the error is due to executing the kexec control
> >>code which is located
From: Dave Hansen
commit 5a28fc94c9143db766d1ba5480cae82d856ad080 upstream.
This is a bit of a mess, to put it mildly. But, it's a bug
that only seems to have showed up in 4.20 but wasn't noticed
until now, because nobody uses MPX.
MPX has the arch_unmap() hook inside of munmap() because MPX
From: Dave Hansen
commit 5a28fc94c9143db766d1ba5480cae82d856ad080 upstream.
This is a bit of a mess, to put it mildly. But, it's a bug
that only seems to have showed up in 4.20 but wasn't noticed
until now, because nobody uses MPX.
MPX has the arch_unmap() hook inside of munmap() because MPX
Le 23/05/2019 à 19:27, Aaro Koskinen a écrit :
Hi,
On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote:
Ok, the Oops confirms that the error is due to executing the kexec control
code which is located outside the kernel text area.
My yesterday's proposed change doesn't work
On 05/23/2019 10:16 AM, Mathieu Malaterre wrote:
On Thu, May 23, 2019 at 11:45 AM Christophe Leroy
wrote:
Le 23/05/2019 à 10:53, Mathieu Malaterre a écrit :
I confirm powerpc/merge does not boot for me (same config). Commit id:
a27eaa62326d (powerpc/merge) Automatic merge of branches
Hi,
On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote:
> Ok, the Oops confirms that the error is due to executing the kexec control
> code which is located outside the kernel text area.
>
> My yesterday's proposed change doesn't work because on book3S/32, NX
> protection is based
On Thu, May 23, 2019 at 06:20:05PM +0200, Oleg Nesterov wrote:
> On 05/23, Christian Brauner wrote:
> >
> > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd)
> > +{
> > + unsigned int cur_max;
> > +
> > + if (fd > max_fd)
> > + return -EINVAL;
> > +
> > +
On Thu, May 23, 2019 at 07:22:17PM +0300, Konstantin Khlebnikov wrote:
> On 22.05.2019 18:52, Christian Brauner wrote:> This adds the close_range()
> syscall. It allows to efficiently close a range
> > of file descriptors up to all file descriptors of a calling task.
> >
> > The syscall came up
From: Konstantin Khlebnikov
> Sent: 23 May 2019 17:22
> > In addition, the syscall will also work for tasks that do not have procfs
> > mounted and on kernels that do not have procfs support compiled in. In such
> > situations the only way to make sure that all file descriptors are closed
On 22.05.2019 18:52, Christian Brauner wrote:> This adds the close_range()
syscall. It allows to efficiently close a range
> of file descriptors up to all file descriptors of a calling task.
>
> The syscall came up in a recent discussion around the new mount API and
> making new file descriptor
On 05/23, Christian Brauner wrote:
>
> So given that we would really need another find_next_open_fd() I think
> sticking to the simple cond_resched() version I sent before is better
> for now until we see real-world performance issues.
OK, agreed.
Oleg.
On 05/23, Christian Brauner wrote:
>
> +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd)
> +{
> + unsigned int cur_max;
> +
> + if (fd > max_fd)
> + return -EINVAL;
> +
> + rcu_read_lock();
> + cur_max = files_fdtable(files)->max_fds;
> +
This adds basic tests for the new close_range() syscall.
- test that no invalid flags can be passed
- test that a range of file descriptors is correctly closed
- test that a range of file descriptors is correctly closed if there there
are already closed file descriptors in the range
- test that
This adds the close_range() syscall. It allows to efficiently close a range
of file descriptors up to all file descriptors of a calling task.
The syscall came up in a recent discussion around the new mount API and
making new file descriptor types cloexec by default. During this
discussion, Al
Hey,
This is v2 of this patchset.
In accordance with some comments There's a cond_resched() added to the
close loop similar to what is done for close_files().
A common helper pick_file() for __close_fd() and __close_range() has
been split out. This allows to only make a cond_resched() call when
ARCH_HAS_ZONE_DEVICE is somewhat meaningless in itself, and combined
with the long-out-of-date comment can lead to the impression than an
architecture may just enable it (since __add_pages() now "comprehends
device memory" for itself) and expect things to work.
In practice, however, ZONE_DEVICE
Le 23/05/2019 à 15:45, Michael Ellerman a écrit :
Frederic Barrat writes:
If the kernel is notified of an HMI caused by the NPU2, it's currently
not being recognized and it logs the default message:
Unknown Malfunction Alert of type 3
The NPU on Power 9 has 3 Fault Isolation
On Thu, May 23, 2019 at 04:32:14PM +0200, Jann Horn wrote:
> On Thu, May 23, 2019 at 1:51 PM Christian Brauner
> wrote:
> [...]
> > I kept it dumb and was about to reply that your solution introduces more
> > code when it seemed we wanted to keep this very simple for now.
> > But then I saw that
On Thu, May 23, 2019 at 04:14:47PM +0200, Christian Brauner wrote:
> On Thu, May 23, 2019 at 01:51:18PM +0200, Christian Brauner wrote:
> > On Wed, May 22, 2019 at 06:57:37PM +0200, Oleg Nesterov wrote:
> > > On 05/22, Christian Brauner wrote:
> > > >
> > > > +static struct file *pick_file(struct
On Thu, May 23, 2019 at 01:51:18PM +0200, Christian Brauner wrote:
> On Wed, May 22, 2019 at 06:57:37PM +0200, Oleg Nesterov wrote:
> > On 05/22, Christian Brauner wrote:
> > >
> > > +static struct file *pick_file(struct files_struct *files, unsigned fd)
> > > {
> > > - struct file *file;
> > > +
The patch
spi: spi-fsl-spi: call spi_finalize_current_message() at the end
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
Frederic Barrat writes:
> If the kernel is notified of an HMI caused by the NPU2, it's currently
> not being recognized and it logs the default message:
>
> Unknown Malfunction Alert of type 3
>
> The NPU on Power 9 has 3 Fault Isolation Registers, so that's a lot of
> possible causes, but
If the kernel is notified of an HMI caused by the NPU2, it's currently
not being recognized and it logs the default message:
Unknown Malfunction Alert of type 3
The NPU on Power 9 has 3 Fault Isolation Registers, so that's a lot of
possible causes, but we should at least log that it's an NPU
Le 23/05/2019 à 13:47, Mathieu Malaterre a écrit :
The declaration for pfn_is_nosave is only available in
kernel/power/power.h. Since this function can be override in arch,
expose it globally. Having a prototype will make sure to avoid warning
(sometime treated as error with W=1) such as:
On Wed, May 22, 2019 at 06:57:37PM +0200, Oleg Nesterov wrote:
> On 05/22, Christian Brauner wrote:
> >
> > +static struct file *pick_file(struct files_struct *files, unsigned fd)
> > {
> > - struct file *file;
> > + struct file *file = NULL;
> > struct fdtable *fdt;
> >
> >
ping ?
On Tue, Mar 12, 2019 at 10:23 PM Mathieu Malaterre wrote:
>
> Fix warnings treated as errors with W=1:
>
> arch/powerpc/lib/sstep.c:1172:31: error: variable 'rc' set but not used
> [-Werror=unused-but-set-variable]
>
> Suggested-by: Christophe Leroy
> Signed-off-by: Mathieu Malaterre
The declaration for pfn_is_nosave is only available in
kernel/power/power.h. Since this function can be override in arch,
expose it globally. Having a prototype will make sure to avoid warning
(sometime treated as error with W=1) such as:
arch/powerpc/kernel/suspend.c:18:5: error: no previous
This is a note to let you know that I've just added the patch titled
x86/mpx, mm/core: Fix recursive munmap() corruption
to the 5.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
x86/mpx, mm/core: Fix recursive munmap() corruption
to the 5.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
The current version of the multiarch vDSO selftest verifies only
gettimeofday.
Extend the vDSO selftest to clock_getres, to verify that the
syscall and the vDSO library function return the same information.
The extension has been used to verify the hrtimer_resoltion fix.
Cc: Shuah Khan
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile
Hi
> On Thu, May 23, 2019 at 09:53:42AM +, S.j. Wang wrote:
> > > > + /*
> > > > + * Add fifo reset here, because the regcache_sync will
> > > > + * write one more data to ETDR.
> > > > + * Which will cause channel shift.
> > >
> > > Sounds like a bug to me...should fix it
In commit eab00a208eb6 ("powerpc: Move `path` variable inside
DEBUG_PROM") DEBUG_PROM sentinels were added to silence a warning
(treated as error with W=1):
arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not
used [-Werror=unused-but-set-variable]
Rework the original
On 05/23/2019 10:05 AM, Christophe Leroy wrote:
On 05/23/2019 09:59 AM, Christophe Leroy wrote:
On 05/23/2019 09:45 AM, Christophe Leroy wrote:
Le 23/05/2019 à 10:53, Mathieu Malaterre a écrit :
Commit id is:
e93c9c99a629 (tag: v5.1) Linux 5.1
Did you try latest powerpc/merge
On Thu, May 23, 2019 at 11:45 AM Christophe Leroy
wrote:
>
>
>
> Le 23/05/2019 à 10:53, Mathieu Malaterre a écrit :
> > On Thu, May 23, 2019 at 10:29 AM Mathieu Malaterre wrote:
> >>
> >> On Thu, May 23, 2019 at 8:39 AM Christophe Leroy
> >> wrote:
> >>>
> >>> Salut Mathieu,
> >>>
> >>> Le
Hello Shengjiu,
On Thu, May 23, 2019 at 09:53:42AM +, S.j. Wang wrote:
> > > + /*
> > > + * Add fifo reset here, because the regcache_sync will
> > > + * write one more data to ETDR.
> > > + * Which will cause channel shift.
> >
> > Sounds like a bug to me...should fix it
On 05/23/2019 09:59 AM, Christophe Leroy wrote:
On 05/23/2019 09:45 AM, Christophe Leroy wrote:
Le 23/05/2019 à 10:53, Mathieu Malaterre a écrit :
Commit id is:
e93c9c99a629 (tag: v5.1) Linux 5.1
Did you try latest powerpc/merge branch ?
Will try that next.
I confirm
On 05/23/2019 09:45 AM, Christophe Leroy wrote:
Le 23/05/2019 à 10:53, Mathieu Malaterre a écrit :
Commit id is:
e93c9c99a629 (tag: v5.1) Linux 5.1
Did you try latest powerpc/merge branch ?
Will try that next.
I confirm powerpc/merge does not boot for me (same config). Commit id:
Hi
> > + /*
> > + * Add fifo reset here, because the regcache_sync will
> > + * write one more data to ETDR.
> > + * Which will cause channel shift.
>
> Sounds like a bug to me...should fix it first by marking the data registers as
> volatile.
>
The ETDR is a writable
Le 23/05/2019 à 10:53, Mathieu Malaterre a écrit :
On Thu, May 23, 2019 at 10:29 AM Mathieu Malaterre wrote:
On Thu, May 23, 2019 at 8:39 AM Christophe Leroy
wrote:
Salut Mathieu,
Le 23/05/2019 à 08:24, Mathieu Malaterre a écrit :
Salut Christophe,
On Wed, May 22, 2019 at 2:20 PM
On Thu, May 23, 2019 at 10:29 AM Mathieu Malaterre wrote:
>
> On Thu, May 23, 2019 at 8:39 AM Christophe Leroy
> wrote:
> >
> > Salut Mathieu,
> >
> > Le 23/05/2019 à 08:24, Mathieu Malaterre a écrit :
> > > Salut Christophe,
> > >
> > > On Wed, May 22, 2019 at 2:20 PM Christophe Leroy
> > >
On Thu, May 23, 2019 at 10:29 AM Mathieu Malaterre wrote:
>
> On Thu, May 23, 2019 at 8:39 AM Christophe Leroy
> wrote:
> >
> > Salut Mathieu,
> >
> > Le 23/05/2019 à 08:24, Mathieu Malaterre a écrit :
> > > Salut Christophe,
> > >
> > > On Wed, May 22, 2019 at 2:20 PM Christophe Leroy
> > >
Build failure was introduced by the commit identified below,
due to missed macro expension leading to wrong called function's name.
arch/powerpc/kernel/head_fsl_booke.o: In function `SystemCall':
arch/powerpc/kernel/head_fsl_booke.S:416: undefined reference to
Hi there,
Is there a way to dump more context (somewhere in of tree
flattening?). I cannot make sense of the following:
kmemleak: 1157 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
Where:
# head -40 /sys/kernel/debug/kmemleak
unreferenced object 0xdf44d180 (size 8):
comm
On Thu, May 23, 2019 at 8:39 AM Christophe Leroy
wrote:
>
> Salut Mathieu,
>
> Le 23/05/2019 à 08:24, Mathieu Malaterre a écrit :
> > Salut Christophe,
> >
> > On Wed, May 22, 2019 at 2:20 PM Christophe Leroy
> > wrote:
> >>
> >>
> >>
> >> Le 22/05/2019 à 14:15, Mathieu Malaterre a écrit :
> >>>
Le 23/05/2019 à 09:00, Christophe Leroy a écrit :
[...]
arch/powerpc/kernel/head_fsl_booke.o: In function `SystemCall':
arch/powerpc/kernel/head_fsl_booke.S:416: undefined reference to
`kvmppc_handler_BOOKE_INTERRUPT_SYSCALL_SPRN_SRR1'
Makefile:1052: recipe for target 'vmlinux' failed
On Mon, May 06, 2019 at 10:46:11AM +0200, Frederic Barrat wrote:
> Hi,
>
> The PCI p2p and tunnel code is used by the Mellanox CX5 driver, at least
> their latest, out of tree version, which is used for CORAL. My
> understanding is that they'll upstream it at some point, though I don't
> know
ppc85xx_basic_defconfig doesn't not select CONFIG_PPC_85xx.
Is that expected ?
Christophe
These two function have never been used since they were added to the
kernel.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/vas.h | 10 --
arch/powerpc/platforms/powernv/vas-window.c | 19 ---
arch/powerpc/platforms/powernv/vas.h| 20
None of these routines were ever used since they were added to the
kernel.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/book3s/64/mmu.h | 2 -
arch/powerpc/include/asm/powernv.h | 22 -
arch/powerpc/mm/book3s64/mmu_context.c | 1 -
Hi all,
the powerpc powernv port has a fairly large chunk of code that never
had any upstream user. We generally strive to not keep dead code
around, and this was affirmed at least years Maintainer summit.
Changes since v1:
- rebased to v5.2-rc1
- remove even more dead code
These have been unused ever since they've been added to the kernel.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/pnv-pci.h| 4 --
arch/powerpc/platforms/powernv/pci-ioda.c | 4 +-
arch/powerpc/platforms/powernv/pci.c | 71 ---
This function has never been used since it has been added to the tree.
We also now have proper PCIe P2P APIs in the core kernel, and any new
P2P support should be using those.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/opal-api.h| 6 --
On Thu, May 23, 2019 at 09:26:53AM +0200, Christophe Leroy wrote:
> You are not fixing the problem, you are just hiding it.
>
> If the result of __get_user() is unneeded, it means __get_user() is not the
> good function to use.
>
> Should use fault_in_pages_readable() instead.
Also it is not
Le 23/05/2019 à 04:31, Qian Cai a écrit :
The commit 58629c0dc349 ("powerpc/powernv/npu: Fault user page into the
hypervisor's pagetable") introduced a variable "c" to be used in
__get_user() and __get_user_nocheck() which need to stay as macros for
performance reasons, and "c" is not
On Wed, May 15, 2019 at 12:29:03PM +, Christophe Leroy wrote:
> Selftests report the following:
>
> [2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong
> output IV) on test vector 0, cfg="in-place"
> [2.995377] : 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f
Le 23/05/2019 à 08:14, Paul Mackerras a écrit :
On Tue, Apr 30, 2019 at 12:39:03PM +, Christophe Leroy wrote:
This patch implements a fast entry for syscalls.
Syscalls don't have to preserve non volatile registers except LR.
This patch then implement a fast entry for syscalls, where
Christophe Leroy writes:
> Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
>> Not all arches have a specific space carved out for modules -
>> some, such as powerpc, just use regular vmalloc space. Therefore,
>> globals in these modules cannot be backed by real shadow memory.
>
> Can you explain
Le 23/05/2019 à 08:49, Mathieu Malaterre a écrit :
In commit 2edb16efc899 ("powerpc/32: Add KASAN support") support for
KASAN has been added. However building it as module leads to (warning
treated as error with W=1):
arch/powerpc/mm/kasan/kasan_init_32.c:135:7: error: no previous
In commit 2edb16efc899 ("powerpc/32: Add KASAN support") support for
KASAN has been added. However building it as module leads to (warning
treated as error with W=1):
arch/powerpc/mm/kasan/kasan_init_32.c:135:7: error: no previous prototype for
'module_alloc' [-Werror=missing-prototypes]
Make
Salut Mathieu,
Le 23/05/2019 à 08:24, Mathieu Malaterre a écrit :
Salut Christophe,
On Wed, May 22, 2019 at 2:20 PM Christophe Leroy
wrote:
Le 22/05/2019 à 14:15, Mathieu Malaterre a écrit :
Hi all,
I have not boot my G4 in a while, today using master here is what I see:
done
Setting
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
Not all arches have a specific space carved out for modules -
some, such as powerpc, just use regular vmalloc space. Therefore,
globals in these modules cannot be backed by real shadow memory.
Can you explain in more details the reason why ?
Salut Christophe,
On Wed, May 22, 2019 at 2:20 PM Christophe Leroy
wrote:
>
>
>
> Le 22/05/2019 à 14:15, Mathieu Malaterre a écrit :
> > Hi all,
> >
> > I have not boot my G4 in a while, today using master here is what I see:
> >
> > done
> > Setting btext !
> > W=640 H=488 LB=768
Christophe Leroy writes:
> Hi Daniel,
>
> Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
>> Building on the work of Christophe, Aneesh and Balbir, I've ported
>> KASAN to Book3S radix.
>>
>> It builds on top Christophe's work on 32bit, and includes my work for
>> 64-bit Book3E (3S doesn't
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 to 0x8000 0600 .
To do this we require that vmemmap be disabled. (This is the default
in the kernel
On Tue, Apr 30, 2019 at 12:39:03PM +, Christophe Leroy wrote:
> This patch implements a fast entry for syscalls.
>
> Syscalls don't have to preserve non volatile registers except LR.
>
> This patch then implement a fast entry for syscalls, where
> volatile registers get clobbered.
>
> As
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initialised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time,
Hi Daniel,
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to Book3S radix.
It builds on top Christophe's work on 32bit, and includes my work for
64-bit Book3E (3S doesn't really depend on 3E, but it was handy to
have
79 matches
Mail list logo
