While booting linux-next [next-20190603] on a POWER9 LPAR following
BUG is encountered and the boot fails.
If I revert the following 2 patches I no longer see this BUG message
07031d37b2f9 ( mm/vmalloc.c: switch to WARN_ON() and move it under unlink_va() )
728e0fbf263e ( mm/vmalloc.c: get rid of
Commit 5318321d367c ("samples: disable CONFIG_SAMPLES for UML") used
a big hammer to fix the build errors under the samples/ directory,
while only some samples actually include uapi headers from usr/include.
Introduce CONFIG_HEADERS_INSTALL since 'depends on HEADERS_INSTALL' is
clearer than
On 06/03/2019 11:50 PM, Daniel Axtens wrote:
Christophe Leroy writes:
Hi,
Ok, can you share your .config ?
Sure! This one is with kasan off as the last build I did was testing to
see if the code reorgisation was the cause of the issues. (it was not)
This was the kasan-enabled config
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from 2617344 to 163584"
The change makes sure the nfpns stored in the superblock is right value.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/label.c | 2 +-
drivers/nvdimm/namespace_devs.c |
We already add the start_pad to the resource->start but fails to section
align the start. This make sure with altmap we compute the right first
pfn when start_pad is zero and we are doing an align down of start address.
vmem_altmap_offset() adjust the section aligned base_pfn offset.
So we need
While booting linux-next [20190603] on a POWER9 LPAR ran into
following warning
[9.002935] WARNING: CPU: 0 PID: 1 at kernel/fork.c:721
__put_task_struct+0x34/0x170
[9.002947] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
[9.002960] CPU: 0 PID: 1 Comm: systemd Not tainted
Em Mon, 3 Jun 2019 09:32:54 +0200
Christophe Leroy escreveu:
> Le 30/05/2019 à 01:23, Mauro Carvalho Chehab a écrit :
> > Sphinx doesn't like orphan documents:
> >
> > Documentation/accelerators/ocxl.rst: WARNING: document isn't included
> > in any toctree
> >
Le 04/06/2019 à 13:16, Masahiro Yamada a écrit :
Linux kernel tolerates C++ style comments these days. Actually, the
SPDX License tags for .c files start with //.
On the other hand, uapi headers are written in more strict C, where
the C++ comment style is forbidden.
Signed-off-by: Masahiro
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: a7f290dad32e [PATCH] powerpc: Merge vdso's and add vdso support
to 32 bits kernel.
The bot has tested the following trees: v5.1.6, v5.0.20, v4.19.47, v4.14.123,
v4.9.180,
This is needed so that we don't wrongly initialize a namespace
which doesn't have enough space reserved for holding struct pages
with the current kernel.
We also increment PFN_MIN_VERSION to make sure that older kernel
won't initialize namespace created with newer kernel.
Signed-off-by: Aneesh
Hi Sachin,
On Tue, 4 Jun 2019 14:45:43 +0530 Sachin Sant
wrote:
>
> While booting linux-next [next-20190603] on a POWER9 LPAR following
> BUG is encountered and the boot fails.
>
> If I revert the following 2 patches I no longer see this BUG message
>
> 07031d37b2f9 ( mm/vmalloc.c: switch to
Em Mon, 3 Jun 2019 09:34:15 +0200
Christophe Leroy escreveu:
> Le 30/05/2019 à 01:23, Mauro Carvalho Chehab a écrit :
> > Mostly due to x86 and acpi conversion, several documentation
> > links are still pointing to the old file. Fix them.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
>
This allows us to make changes in a backward incompatible way. I have
kept the PFN_MIN_VERSION in this patch '0' because we are not introducing
any incompatible changes in this patch. We also may want to backport this
to older kernels.
The error looks like
dax0.1: init failed, superblock min
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled
Em Tue, 4 Jun 2019 06:46:14 -0300
Mauro Carvalho Chehab escreveu:
> Em Mon, 3 Jun 2019 09:34:15 +0200
> Christophe Leroy escreveu:
>
> > [...]
> >
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 8c1c636308c8..e868d2bd48b8 100644
> > > --- a/arch/powerpc/Kconfig
> >
On Tue, Jun 4, 2019 at 8:54 PM Frederic Barrat wrote:
>
>
>
> Le 04/06/2019 à 13:16, Masahiro Yamada a écrit :
> > Linux kernel tolerates C++ style comments these days. Actually, the
> > SPDX License tags for .c files start with //.
> >
> > On the other hand, uapi headers are written in more
Multiple people have suggested to compile-test UAPI headers.
Currently, Kbuild provides simple sanity checks by headers_check
but they are not enough to catch bugs.
The most recent patch I know is David Howells' work:
https://patchwork.kernel.org/patch/10590203/
I agree that we need better
Linux kernel tolerates C++ style comments these days. Actually, the
SPDX License tags for .c files start with //.
On the other hand, uapi headers are written in more strict C, where
the C++ comment style is forbidden.
Signed-off-by: Masahiro Yamada
---
include/uapi/misc/ocxl.h | 14
Hi Vincenzo
Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
Hi Michael,
thank you for your reply.
On 28/05/2019 07:19, Michael Ellerman wrote:
Vincenzo Frascino writes:
The current version of the multiarch vDSO selftest verifies only
gettimeofday.
Extend the vDSO selftest to
Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
Hi Christophe,
On 04/06/2019 14:16, Christophe Leroy wrote:
Hi Vincenzo
Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
Hi Michael,
thank you for your reply.
On 28/05/2019 07:19, Michael Ellerman wrote:
Vincenzo Frascino writes:
Le 04/06/2019 à 15:43, Vincenzo Frascino a écrit :
On 04/06/2019 14:39, Christophe Leroy wrote:
Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
Hi Christophe,
On 04/06/2019 14:16, Christophe Leroy wrote:
Hi Vincenzo
Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
Hi Michael,
This document is used by multiple architectures:
$ echo $(git grep -l pkey_mprotect arch|cut -d'/' -f 2|sort|uniq)
alpha arm arm64 ia64 m68k microblaze mips parisc powerpc s390 sh sparc
x86 xtensa
So, let's move it to the core book and adjust the links to it
accordingly.
Hi Christophe,
On 04/06/2019 14:16, Christophe Leroy wrote:
> Hi Vincenzo
>
> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>> Hi Michael,
>>
>> thank you for your reply.
>>
>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>> Vincenzo Frascino writes:
>>>
The current version of the
On 04/06/2019 14:39, Christophe Leroy wrote:
>
>
> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
>> Hi Christophe,
>>
>> On 04/06/2019 14:16, Christophe Leroy wrote:
>>> Hi Vincenzo
>>>
>>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
Hi Michael,
thank you for your
tch has been fixed in today's linux-next …
Thanks Stephen.
With today’s next (20190604) I no longer see this issue.
Thanks
-Sachin
On 04/06/2019 14:52, Christophe Leroy wrote:
>
>
> Le 04/06/2019 à 15:43, Vincenzo Frascino a écrit :
>> On 04/06/2019 14:39, Christophe Leroy wrote:
>>>
>>>
>>> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
Hi Christophe,
On 04/06/2019 14:16, Christophe Leroy wrote:
>
Hi Sachin,
On Tue, 4 Jun 2019 19:09:26 +0530 Sachin Sant
wrote:
>
> With today’s next (20190604) I no longer see this issue.
Excellent, thanks for verifying.
--
Cheers,
Stephen Rothwell
pgpx9mJt3XhCg.pgp
Description: OpenPGP digital signature
Sphinx doesn't like orphan documents:
Documentation/accelerators/ocxl.rst: WARNING: document isn't included in
any toctree
Documentation/arm/stm32/overview.rst: WARNING: document isn't included in
any toctree
Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't
Paul,
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,
Tyrel Datwyler writes:
> On 05/20/2019 08:01 AM, Nathan Lynch wrote:
>> Kernel implementation details aside, how do you change the cpu-node
>> relationship at runtime without breaking NUMA-aware applications? Is
>> this not a fundamental issue to address before adding code like this?
>>
>
> If
On 04/06/2019 07:56, David Hildenbrand wrote:
On 03.06.19 23:41, Wei Yang wrote:
On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote:
A proper arch_remove_memory() implementation is on its way, which also
cleanly removes page tables in arch_add_memory() in case something goes
On 06/03/2019 03:29 AM, Greg KH wrote:
On Mon, Jun 03, 2019 at 04:04:32PM +1000, Daniel Axtens wrote:
Hi Nayna,
As PowerNV moves towards secure boot, we need a place to put secure
variables. One option that has been canvassed is to make our secure
variables look like EFI variables. This is
On Mon, May 13, 2019 at 6:17 AM Rasmus Villemoes
wrote:
>
> This small series consists of some small cleanups and simplifications
> of the QUICC engine driver, and introduces a new DT binding that makes
> it much easier to support other variants of the QUICC engine IP block
> that appears in the
On 06/03/2019 07:56 PM, Daniel Axtens wrote:
I would just recommend putting this in sysfs. Make a new subsystem
(i.e. class) and away you go.
My hope with fwvarfs is to provide a generic place for firmware
variables so that we don't need to expand the list of firmware-specific
https://bugzilla.kernel.org/show_bug.cgi?id=203515
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 04.06.19 19:36, Robin Murphy wrote:
> On 04/06/2019 07:56, David Hildenbrand wrote:
>> On 03.06.19 23:41, Wei Yang wrote:
>>> On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote:
A proper arch_remove_memory() implementation is on its way, which also
cleanly removes page
On Mon, May 27, 2019 at 01:11:49PM +0200, David Hildenbrand wrote:
>No longer needed, the callers of arch_add_memory() can handle this
>manually.
>
>Cc: Andrew Morton
>Cc: David Hildenbrand
>Cc: Michal Hocko
>Cc: Oscar Salvador
>Cc: Pavel Tatashin
>Cc: Wei Yang
>Cc: Joonsoo Kim
>Cc: Qian
On Tue, Jun 04, 2019 at 12:04:06PM +0530, Anshuman Khandual wrote:
> +++ b/arch/x86/mm/fault.c
> @@ -46,23 +46,6 @@ kmmio_fault(struct pt_regs *regs, unsigned long addr)
> return 0;
> }
>
> -static nokprobe_inline int kprobes_fault(struct pt_regs *regs)
> -{
...
> -}
> diff --git
On Mon, May 27, 2019 at 01:11:48PM +0200, David Hildenbrand wrote:
>Only memory to be added to the buddy and to be onlined/offlined by
>user space using /sys/devices/system/memory/... needs (and should have!)
>memory block devices.
>
>Factor out creation of memory block devices. Create all devices
On Mon, May 27, 2019 at 01:11:50PM +0200, David Hildenbrand wrote:
>Let's factor out removing of memory block devices, which is only
>necessary for memory added via add_memory() and friends that created
>memory block devices. Remove the devices before calling
>arch_remove_memory().
>
>This
On Tue, Jun 4, 2019 at 7:15 PM Masahiro Yamada
wrote:
>
>
> Multiple people have suggested to compile-test UAPI headers.
>
> Currently, Kbuild provides simple sanity checks by headers_check
> but they are not enough to catch bugs.
>
> The most recent patch I know is David Howells' work:
>
Nathan,
> clang warns:
>
> drivers/scsi/ibmvscsi/ibmvscsi.c:2126:7: warning: variable 'rc' is used
> uninitialized whenever switch case is taken [-Wsometimes-uninitialized]
> case IBMVSCSI_HOST_ACTION_NONE:
> ^
Applied to 5.3/scsi-queue, thanks!
--
On Wed, Jun 05, 2019 at 01:38:14PM +1000, Alexey Kardashevskiy wrote:
> When the firmware does PCI BAR resource allocation, it passes the assigned
> addresses and flags (prefetch/64bit/...) via the "reg" property of
> a PCI device device tree node so the kernel does not need to do
> resource
On Wed, Jun 5, 2019 at 1:38 PM Alexey Kardashevskiy wrote:
>
> When the firmware does PCI BAR resource allocation, it passes the assigned
> addresses and flags (prefetch/64bit/...) via the "reg" property of
> a PCI device device tree node so the kernel does not need to do
> resource allocation.
>
When the firmware does PCI BAR resource allocation, it passes the assigned
addresses and flags (prefetch/64bit/...) via the "reg" property of
a PCI device device tree node so the kernel does not need to do
resource allocation.
The flags are stored in resource::flags - the lower byte stores
On Tue, May 7, 2019 at 2:30 PM Sam Bobroff wrote:
>
> Now that EEH support for all devices (on PowerNV and pSeries) is
> provided by the pcibios bus add device hooks, eeh_probe_devices() and
> eeh_addr_cache_build() are redundant and can be removed.
>
> Move the EEH enabled message into it's own
On 06/03/2019 08:23 PM, Stewart Smith wrote:
> On my two socket POWER9 system (powernv) with 842 zwap set up, I
> recently got a crash with the Ubuntu kernel (I haven't tried with
> upstream, and this is the first time the system has died like this, so
> I'm not sure how repeatable it is).
>
> [
On Mon, Jun 03, 2019 at 10:02:10AM -0700, Linus Torvalds wrote:
> On Mon, Jun 3, 2019 at 9:08 AM Linus Torvalds
> wrote:
> >
> > The new code has no test at all for "nr_pages == 0", afaik.
>
> Note that it really is important to check for that, because right now we do
True. The 0 check got
On Mon, Jun 03, 2019 at 09:16:08AM -0600, Khalid Aziz wrote:
> Could you reword above sentence? We are already starting off with
> untagged_addr() not being no-op for arm64 and sparc64. It will expand
> further potentially. So something more along the lines of "Define it as
> noop for
Remove the CONFIG_UEVENT_HELPER_PATH because:
1. It is disabled since commit 1be01d4a5714 ("driver: base: Disable
CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was
made default to 'n',
2. It is not recommended (help message: "This should not be used today
[...]
On Tue, Jun 4, 2019 at 10:01 AM Krzysztof Kozlowski wrote:
> Remove the CONFIG_UEVENT_HELPER_PATH because:
> 1. It is disabled since commit 1be01d4a5714 ("driver: base: Disable
>CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was
>made default to 'n',
> 2. It is not
On 06/04/2019 12:24 PM, Peter Zijlstra wrote:
> On Tue, Jun 04, 2019 at 12:04:06PM +0530, Anshuman Khandual wrote:
>> diff --git a/mm/memory.c b/mm/memory.c
>> index ddf20bd..b6bae8f 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -52,6 +52,7 @@
>> #include
>> #include
>> #include
On 03.06.19 23:41, Wei Yang wrote:
> On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote:
>> A proper arch_remove_memory() implementation is on its way, which also
>> cleanly removes page tables in arch_add_memory() in case something goes
>> wrong.
>
> Would this be better to
On 04.06.19 00:15, Wei Yang wrote:
> Allow arch_remove_pages() or arch_remove_memory()?
Looks like I merged __remove_pages() and arch_remove_memory().
@Andrew, can you fix this up to
"mm/memory_hotplug: Allow arch_remove_memory() without
CONFIG_MEMORY_HOTREMOVE"
? Thanks!
>
> And want to
Is anyone going to pick this series up?
On Mon, May 20, 2019 at 08:00:13AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> 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
Quoting Nathan Chancellor :
When building with -Wsometimes-uninitialized, clang warns:
drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
used uninitialized whenever 'for' loop exits because its condition is
false [-Wsometimes-uninitialized]
for (j = 0; j <
Similar notify_page_fault() definitions are being used by architectures
duplicating much of the same code. This attempts to unify them into a
single implementation, generalize it and then move it to a common place.
kprobes_built_in() can detect CONFIG_KPROBES, hence notify_page_fault()
need not be
On Tue, Jun 04, 2019 at 12:04:06PM +0530, Anshuman Khandual wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index ddf20bd..b6bae8f 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -52,6 +52,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@
On 03.06.19 23:49, Wei Yang wrote:
> On Mon, May 27, 2019 at 01:11:46PM +0200, David Hildenbrand wrote:
>> We'll rework hotplug_memory_register() shortly, so it no longer consumes
>> pass a section.
>>
>> Cc: Greg Kroah-Hartman
>> Cc: "Rafael J. Wysocki"
>> Signed-off-by: David Hildenbrand
>>
Hi Sirs,
Could anyone please comment this patch set or tell me if I have missed
maintainer in mail list? I'd like to let review process move forward.
Thank you.
Regards,
Ran
On Monday, May 20, 2019 17:53 Ran Wang wrote:
>
> Some user might want to go through all registered wakeup
On 04.06.19 10:31, Wei Yang wrote:
> On Tue, Jun 04, 2019 at 08:59:43AM +0200, David Hildenbrand wrote:
>> On 04.06.19 00:15, Wei Yang wrote:
>>> Allow arch_remove_pages() or arch_remove_memory()?
>>
>> Looks like I merged __remove_pages() and arch_remove_memory().
>>
>> @Andrew, can you fix this
Oliver writes:
> On Sun, Jun 2, 2019 at 2:44 PM Aneesh Kumar K.V
> wrote:
>>
>> SCM_READ/WRITE_MEATADATA hcall supports multibyte read/write. This patch
>> updates the metadata read/write to use 1, 2, 4 or 8 byte read/write as
>> mentioned in PAPR document.
>>
>> READ/WRITE_METADATA hcall
On 05/30/2019 04:53 AM, Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/acpi/dsd/leds.txt | 2 +-
>
Two architecture that use arch specific MMAP flags are powerpc and sparc.
We still have few flag values common across them and other architectures.
Consolidate this in mman-common.h.
Also update the comment to indicate where to find HugeTLB specific reserved
values
Signed-off-by: Aneesh Kumar
On Tue, Jun 04, 2019 at 08:59:43AM +0200, David Hildenbrand wrote:
>On 04.06.19 00:15, Wei Yang wrote:
>> Allow arch_remove_pages() or arch_remove_memory()?
>
>Looks like I merged __remove_pages() and arch_remove_memory().
>
>@Andrew, can you fix this up to
>
>"mm/memory_hotplug: Allow
With following patches we add EOPNOTSUPP as return from probe callback to
indicate we were not able to initialize a namespace due to pfn superblock
feature/version mismatch. We want to consider this a probe success so that
we can create new namesapce seed and there by avoid marking the failed
66 matches
Mail list logo
