On Tue, 2019-07-16 at 16:48 +1000, Sam Bobroff wrote:
> On Thu, Jun 20, 2019 at 01:45:24PM +1000, Oliver O'Halloran wrote:
> > On Thu, Jun 20, 2019 at 12:40 PM Alexey Kardashevskiy
> > wrote:
> > > On 19/06/2019 14:27, Sam Bobroff wrote:
> > > > On Tue, Jun 11, 2019 at 03:47:58PM +1000, Alexey Ka
On Tue, Jul 16, 2019 at 3:16 AM Segher Boessenkool
wrote:
>
> On Mon, Jul 15, 2019 at 09:03:46PM +0900, Masahiro Yamada wrote:
> > On Mon, Jul 15, 2019 at 4:30 PM Segher Boessenkool
> > wrote:
> > >
> > > On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> > > > Segher Boessenkool
On 2019-07-14, Al Viro wrote:
> On Sat, Jul 13, 2019 at 03:41:53AM +0100, Al Viro wrote:
> > On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote:
> > > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote:
> > >
> > > > if (flags & LOOKUP_BENEATH) {
> > > > nd->root
> > The cpu variable is still being used in the of_get_property() call
> > after the of_node_put() call, which may result in use-after-free.
> >
> > Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
> > Signed-off-by: Wen Yang
> > Cc: "Rafael J. Wysocki"
> > Cc: Viresh Ku
On Mon, Jul 15, 2019 at 01:10:33PM +0200, David Hildenbrand wrote:
> On 01.07.19 12:27, Michal Hocko wrote:
> > On Mon 01-07-19 11:36:44, Oscar Salvador wrote:
> >> On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
> >>> Yeah, we do not allow to offline multi zone (node) ranges so the c
https://bugzilla.kernel.org/show_bug.cgi?id=203647
Anatoly Pugachev (mator...@gmail.com) changed:
What|Removed |Added
CC||mator...@gmail.com
On 16-07-19, 16:26, wen.yan...@zte.com.cn wrote:
> Okay thank you.
> Now this patch
> (https://lore.kernel.org/lkml/ee8cf5fb4b4a01fdf9199037ff6d835b935cfd13.1562902877.git.viresh.ku...@linaro.org/)
>
> seems to have not been merged into the linux-next.
>
> In order to avoid code conflicts, we wi
This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM device
numa node online. Hence we need to make sure we always use an online node
as ndr_desc.numa_node. Otherwise this result in kernel crashes. The target
node is used by dax/kmem and that will bring up the numa node online corr
On 16/07/2019 18:59, Cédric Le Goater wrote:
On 15/07/2019 09:11, Alexey Kardashevskiy wrote:
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown() is
On 16/07/2019 11:10, Alexey Kardashevskiy wrote:
>
>
> On 16/07/2019 18:59, Cédric Le Goater wrote:
>> On 15/07/2019 09:11, Alexey Kardashevskiy wrote:
>>> There is a race between releasing an irq on one cpu and fetching it
>>> from XIVE on another cpu as there does not seem to be any locking bet
On 15/07/2019 09:11, Alexey Kardashevskiy wrote:
> There is a race between releasing an irq on one cpu and fetching it
> from XIVE on another cpu as there does not seem to be any locking between
> these, probably because xive_irq_chip::irq_shutdown() is supposed to
> remove the irq from all queues
Hello,
Now that cpufreq core supports taking QoS requests for min/max cpu
frequencies, lets migrate rest of the users to using them instead of the
policy notifiers.
The CPUFREQ_NOTIFY and CPUFREQ_ADJUST events of the policy notifiers are
removed as a result, but we have to add CPUFREQ_CREATE_POLI
The cpufreq core now takes the min/max frequency constraints via QoS
requests and the CPUFREQ_ADJUST notifier shall get removed later on.
Switch over to using the QoS request for maximum frequency constraint
for windfarm_cpufreq_clamp driver.
Signed-off-by: Viresh Kumar
---
drivers/macintosh/wi
On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote:
>
> Hello,
>
> Now that cpufreq core supports taking QoS requests for min/max cpu
> frequencies, lets migrate rest of the users to using them instead of the
> policy notifiers.
Technically, this still is linux-next only. :-)
> The CPUFREQ_NOTI
On 16-07-19, 12:06, Rafael J. Wysocki wrote:
> On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote:
> >
> > Hello,
> >
> > Now that cpufreq core supports taking QoS requests for min/max cpu
> > frequencies, lets migrate rest of the users to using them instead of the
> > policy notifiers.
>
> Tech
On Tue, Jul 16, 2019 at 12:14 PM Viresh Kumar wrote:
>
> On 16-07-19, 12:06, Rafael J. Wysocki wrote:
> > On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar
> > wrote:
> > >
> > > Hello,
> > >
> > > Now that cpufreq core supports taking QoS requests for min/max cpu
> > > frequencies, lets migrate res
On 16.07.19 10:46, Oscar Salvador wrote:
> On Mon, Jul 15, 2019 at 01:10:33PM +0200, David Hildenbrand wrote:
>> On 01.07.19 12:27, Michal Hocko wrote:
>>> On Mon 01-07-19 11:36:44, Oscar Salvador wrote:
On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
> Yeah, we do not allow
On 16.07.19 10:46, Oscar Salvador wrote:
> On Mon, Jul 15, 2019 at 01:10:33PM +0200, David Hildenbrand wrote:
>> On 01.07.19 12:27, Michal Hocko wrote:
>>> On Mon 01-07-19 11:36:44, Oscar Salvador wrote:
On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
> Yeah, we do not allow
Firmware-Assisted Dump (FADump) is currently supported only on pSeries
platform. This patch series adds support for PowerNV platform too.
The first few patches refactor the FADump code to make use of common
code across multiple platforms. Then basic FADump support is added for
PowerNV platform. Fo
Though asm/fadump.h is meant to be used by other components dealing
with FADump, it also has macros/definitions internal to FADump code.
Move them to a new header file used within FADump code. This also
makes way for refactoring platform specific FADump code.
Signed-off-by: Hari Bathini
---
arch
Make way for refactoring platform specific FADump code by moving code
that could be referenced from multiple places to fadump-common.c file.
Signed-off-by: Hari Bathini
---
arch/powerpc/kernel/Makefile|2
arch/powerpc/kernel/fadump-common.c | 144 +++
The figures depicting FADump's (Firmware-Assisted Dump) memory layout
are missing some finer details like different memory regions and what
they represent. Improve the documentation by updating those details.
Signed-off-by: Hari Bathini
---
Documentation/powerpc/firmware-assisted-dump.txt | 65
Currently, FADump is only supported on pSeries but that is going to
change soon with FADump support being added on PowerNV platform. So,
move rtas specific definitions to platform code to allow FADump
to have multiple platforms support.
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/fa
Introduce callback functions for platform specific operations like
register, unregister, invalidate & such. Also, define place-holders
for the same on pSeries platform.
Signed-off-by: Hari Bathini
---
arch/powerpc/kernel/fadump-common.h | 33 ++
arch/powerpc/kernel/fadump.c
Make RTAS calls to register and un-register for FADump. Also, update
how fadump_region contents are diplayed to provide more information.
Signed-off-by: Hari Bathini
---
arch/powerpc/kernel/fadump-common.h |2
arch/powerpc/kernel/fadump.c | 164 ++--
fadump is pronounced f-a-dump. Update documentation accordingly. Also,
update how fadump_region contents look like with recent changes.
Signed-off-by: Hari Bathini
---
Documentation/powerpc/firmware-assisted-dump.txt | 71 --
1 file changed, 39 insertions(+), 32 deletions(-
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/opal-api.h| 50 +++-
arch/powerpc/include/asm/opal.h|6 +++
arch/powerpc/platforms/powernv/opal-call.c |3 ++
3 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/
Add basic callback functions for FADump on PowerNV platform.
Signed-off-by: Hari Bathini
---
arch/powerpc/Kconfig |5 +
arch/powerpc/kernel/fadump-common.h | 10 +++
arch/powerpc/kernel/fadump.c |3 +
arch/powerpc/platforms/powernv/Makef
OPAL allows registering address with it in the first kernel and
retrieving it after MPIPL. Setup kernel metadata and register its
address with OPAL to use it for processing the crash dump.
Signed-off-by: Hari Bathini
---
arch/powerpc/kernel/fadump-common.h |4 +
arch/powerpc/kernel/
Make OPAL calls to register and un-register with firmware for MPIPL.
Signed-off-by: Hari Bathini
---
arch/powerpc/platforms/powernv/opal-fadump.c | 71 +-
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c
b/arch
Firmware uses 32-bit field for region size while copying/backing-up
memory during MPIPL. So, the maximum copy size for a region would
be a page less than 4GB (aligned to pagesize) but FADump capture
kernel usually needs more memory than that to be preserved to avoid
running into out of memory error
Add support in the kernel to process the crash'ed kernel's memory
preserved during MPIPL and export it as /proc/vmcore file for the
userland scripts to filter and analyze it later.
Signed-off-by: Hari Bathini
---
arch/powerpc/platforms/powernv/opal-fadump.c | 190 ++
1 f
With FADump support now available on both pseries and OPAL platforms,
update FADump documentation with these details.
Signed-off-by: Hari Bathini
---
Documentation/powerpc/firmware-assisted-dump.txt | 104 +-
1 file changed, 63 insertions(+), 41 deletions(-)
diff --git a/Do
Commit 0962e8004e97 ("powerpc/prom: Scan reserved-ranges node for
memory reservations") enabled support to parse reserved-ranges DT
node and reserve kernel memory falling in these ranges for F/W
purposes. Ensure memory in these ranges is not overlapped with
memory reserved for FADump.
Also, use a
Move code that supports processing the crash'ed kernel's memory
preserved by firmware to platform specific callback functions.
Signed-off-by: Hari Bathini
---
arch/powerpc/kernel/fadump-common.h |6
arch/powerpc/kernel/fadump.c | 340 +-
arc
Commit 0962e8004e97 ("powerpc/prom: Scan reserved-ranges node for
memory reservations") enabled support to parse 'reserved-ranges' DT
node to reserve kernel memory falling in these ranges for firmware
purposes. Along with the preserved area memory, also ensure memory
in reserved ranges is not overl
From: Hari Bathini
Firmware provides architected register state data at the time of crash.
Process this data and build CPU notes to append to ELF core.
Signed-off-by: Hari Bathini
Signed-off-by: Vasant Hegde
---
arch/powerpc/kernel/fadump-common.h |4 +
arch/powerpc/platforms/pow
Add a new kernel config option, CONFIG_PRESERVE_FA_DUMP that ensures
that crash data, from previously crash'ed kernel, is preserved. This
helps in cases where FADump is not enabled but the subsequent memory
preserving kernel boot is likely to process this crash data. One
typical usecase for this co
Kernel config option CONFIG_PRESERVE_FA_DUMP is introduced to ensure
crash data, from previously crash'ed kernel, is preserved. Update
documentation with this details.
Signed-off-by: Hari Bathini
---
Documentation/powerpc/firmware-assisted-dump.txt |9 +
1 file changed, 9 insertions(
From: Hari Bathini
Export /sys/firmware/opal/core file to analyze opal crashes. Since OPAL
core can be generated independent of CONFIG_FA_DUMP support in kernel,
add this support under a new kernel config option CONFIG_OPAL_CORE.
Also, avoid code duplication by moving common code used while expor
If not all kernel boot memory regions are registered for MPIPL before
system crashes, try processing the partial crashdump but warn the user
before proceeding.
Signed-off-by: Hari Bathini
---
arch/powerpc/platforms/powernv/opal-fadump.c | 21 +
1 file changed, 21 insertions
Writing '1' to /sys/kernel/fadump_release_opalcore would release the
memory held by kernel in exporting /sys/firmware/opal/core file.
Signed-off-by: Hari Bathini
---
arch/powerpc/platforms/powernv/opal-core.c | 38
1 file changed, 38 insertions(+)
diff --git a/arc
OPAL loads kernel & initrd at 512MB offset (256MB size), also exported
as ibm,opal/dump/fw-load-area. So, if boot memory size of FADump is
less than 768MB, kernel memory to be exported as '/proc/vmcore' would
be overwritten by f/w while loading kernel & initrd. To avoid such a
scenario, enforce a m
With /sys/firmware/opal/core support available on OPAL based machines
and an option to the release memory used by kernel in exporting this
core file, update FADump documentation with these details.
Signed-off-by: Hari Bathini
---
Documentation/powerpc/firmware-assisted-dump.txt | 19 ++
Cédric Le Goater writes:
> On 16/07/2019 11:10, Alexey Kardashevskiy wrote:
>> On 16/07/2019 18:59, Cédric Le Goater wrote:
>>> On 15/07/2019 09:11, Alexey Kardashevskiy wrote:
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not
Those are the pending documentation patches after my pull request
for this branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
tags/docs/v5.3-1
Patches 1 to 13 were already submitted, but got rebased. Patch 14
is a new fixup one.
Patches 1 and 2 weren't submitted b
Convert docs to ReST and add them to the arch-specific
book.
The conversion here was trivial, as almost every file there
was already using an elegant format close to ReST standard.
The changes were mostly to mark literal blocks and add a few
missing section title identifiers.
One note with regar
Segher Boessenkool writes:
> On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
>> Segher Boessenkool writes:
>> > Yes, that is why I used the environment variable, all binutils work
>> > with that. There was no --target option in GNU ar before 2.22.
>>
>> Yeah, we're not very go
On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
> I think Vasily already has a clone3 patch for s390x with 435.
A quick follow-up on this. Helge and Michael have asked whether there
are any tests for clone3. Yes, there will be and I try to have them
ready by the end of the
On Fri, 12 Jul 2019 at 04:20, Alex Shi wrote:
>
> Since we move 'arm/arm64' docs to Documentation/arch/{arm,arm64} dir,
> redirect the doc pointer to them.
>
> Signed-off-by: Alex Shi
> Cc: Jonathan Corbet
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: linux-...@vger.kernel.org
> Cc: linux-k
Dear everyone,
we are currently developing a kernel upgrade for an older hardware. The
system shall be upgraded from kernel 2.6.24 to the current stable
vanilla kernel (4.19).
With our new kernel we are facing strange and non deterministic kernel
crashes which occur more or less randomly when mod
On Fri, 12 Jul 2019 00:13:57 +0300
Jarkko Sakkinen wrote:
> On Thu, Jul 11, 2019 at 11:28:24PM +0300, Jarkko Sakkinen wrote:
> > On Thu, Jul 11, 2019 at 12:13:35PM -0400, Nayna Jain wrote:
> > > The nr_allocated_banks and allocated banks are initialized as part of
> > > tpm_chip_register. Curre
Hi,
[Adding Helge to CC list]
On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote:
> On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
> > I think Vasily already has a clone3 patch for s390x with 435.
>
> A quick follow-up on this. Helge and Michael have asked
On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote:
> Hi,
>
> [Adding Helge to CC list]
>
> On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote:
> > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
> > > I think Vasily already has a clone3 patch for
Functions `__boot_from_prom` and `start_here_common` are "init code" in
the sense that they are only executed at boot time, nevertheless they
should not be tagged as __init since this will carry them to a different
section located at the very end of kernel text. If the TOC is not set up,
the kernel
On 16.07.19 20:55, Christian Brauner wrote:
On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote:
Hi,
[Adding Helge to CC list]
On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote:
On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
I think Vasily al
man 3p says that fchmodat() takes a flags argument, but the Linux
syscall does not. There doesn't appear to be a good userspace
workaround for this issue but the implementation in the kernel is pretty
straight-forward. The specific use case where the missing flags came up
was WRT a fuse filesyste
The next patch defines a very similar interface, which I copied from
this definition. Since I'm touching it anyway I don't see any reason
not to just go fix this one up.
Signed-off-by: Palmer Dabbelt
---
include/linux/syscalls.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This patch set adds fchmodat4(), a new syscall. The actual
implementation is super simple: essentially it's just the same as
fchmodat(), but LOOKUP_FOLLOW is conditionally set based on the flags.
I've attempted to make this match "man 2 fchmodat" as closely as
possible, which says EINVAL is returne
This registers the new fchmodat4 syscall in most places as nuber 434,
with alpha being the exception where it's 544. I found all these sites
by grepping for fspick, which I assume has found me everything.
Signed-off-by: Palmer Dabbelt
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/
I'm not sure why it's necessary to add this explicitly to tools/ as well
as arch/, but there were a few instances of fspick in here so I blindly
added fchmodat4 in the same fashion.
Signed-off-by: Palmer Dabbelt
---
tools/include/uapi/asm-generic/unistd.h | 4 +++-
tools/perf/arch/x86/
On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote:
> -int do_fchmodat(int dfd, const char __user *filename, umode_t mode)
> +int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int
> flags)
> {
> struct path path;
> int error;
> - unsigned int lookup
On Tue, 16 Jul 2019 18:48:02 PDT (-0700), v...@zeniv.linux.org.uk wrote:
On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote:
-int do_fchmodat(int dfd, const char __user *filename, umode_t mode)
+int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int flags)
{
On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote:
> man 3p says that fchmodat() takes a flags argument, but the Linux
> syscall does not. There doesn't appear to be a good userspace
> workaround for this issue but the implementation in the kernel is pretty
> straight-forward. The sp
On Tue, Jul 16, 2019 at 10:40:46PM -0400, Rich Felker wrote:
> On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote:
> > man 3p says that fchmodat() takes a flags argument, but the Linux
> > syscall does not. There doesn't appear to be a good userspace
> > workaround for this issue but t
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.
Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Michael Ellerman
On 17-07-19, 11:55, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J. Wy
On Wed, 2019-07-17 at 15:00 +1000, Alexey Kardashevskiy wrote:
> There is a race between releasing an irq on one cpu and fetching it
> from XIVE on another cpu as there does not seem to be any locking between
> these, probably because xive_irq_chip::irq_shutdown() is supposed to
> remove the irq fr
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown() is supposed to
remove the irq from all queues in the system which it does not do.
As a result, when su
On 17/07/2019 15:00, Alexey Kardashevskiy wrote:
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown() is supposed to
remove the irq from all queues in
70 matches
Mail list logo
