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 conf
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 inline
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 source
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 lost
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 architectures
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
[...] create
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 rec
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 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 u
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 suppor
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 +-
> Documentation/ad
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 arch_remove_
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 K.V
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
names
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 | 6
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 ve
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 to
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 by
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 Ku
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
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
> > Documentation/arm/stm32/
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 'depen
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 tes
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 W
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
> > ---
> >
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
> >
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 +++
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 Y
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 stric
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
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, v4.4.180
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 clock_getr
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 mul
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:
T
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: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 reply
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,
tha
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
in
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.
Signed
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
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:
> H
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, where
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 th
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
wron
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 t
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
filesystems
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 w
https://bugzilla.kernel.org/show_bug.cgi?id=203515
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
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 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: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 Cai
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 a/includ
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 finishes
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:
> https://
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!
--
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
PCI_BAS
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 alloca
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 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.
>
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 f
On Tue, Jun 04, 2019 at 04:33:14PM -0400, Nayna wrote:
>
>
> 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 opti
On 4/6/19 10:12 pm, Masahiro Yamada wrote:
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 header
On 5/6/19 12:17 am, Mauro Carvalho Chehab wrote:
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/stm
64 matches
Mail list logo
