32-bit powerpc, aty128fb: vmap allocation for size 135168 failed

I was trying 4.13.0-rc5-00075-gac9a40905a61 on my PowerMac G4 with 1G RAM and after some time of sddm respawning and X trying to restart, dmesg is full of messages about vmap allocation failures. Maybe the aty128fb is leaking ROM allocations or something like that? sddm has been crashing

Re: [RFC v7 25/25] powerpc: Enable pkey subsystem

Ram Pai writes: > On Thu, Aug 17, 2017 at 05:30:27PM -0300, Thiago Jung Bauermann wrote: >> Ram Pai writes: >> > On Thu, Aug 10, 2017 at 06:27:34PM -0300, Thiago Jung Bauermann wrote: >> >> Ram Pai writes: >> >> > @@ -227,6 +229,24

Re: [RFC v7 24/25] powerpc: Deliver SEGV signal on pkey violation

Ram Pai writes: > On Fri, Aug 11, 2017 at 08:26:30PM +1000, Michael Ellerman wrote: >> Thiago Jung Bauermann writes: >> >> > Ram Pai writes: >> > >> >> The value of the AMR register at the time of exception >> >> is made

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

On Thu, 2017-08-17 at 14:18 -0500, Brian King wrote: > On 08/17/2017 10:32 AM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote: > >> On 08/16/2017 01:15 PM, Bart Van Assche wrote: > >>> On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote: > Linux-next booted

[PATCH 2/2] kvm/xive: Add missing barriers and document them

This adds missing memory barriers to order updates/tests of the virtual CPPR and MFRR, thus fixing a lost IPI problem. While at it also document all barriers in this file This fixes a bug causing guest IPIs to occasionally get lost. Signed-off-by: Benjamin Herrenschmidt

[PATCH 1/2] kvm/xive: Workaround P9 DD1.0 bug with IPB bit loss

Thankfully it only happens when manually manipulating CPPR which is rather quite rare. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kvm/book3s_xive_template.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git

Re: [RFC v7 26/25] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On Fri, Aug 11, 2017 at 02:34:43PM -0300, Thiago Jung Bauermann wrote: > Expose useful information for programs using memory protection keys. > Provide implementation for powerpc and x86. > > On a powerpc system with pkeys support, here is what is shown: > > $ head

Re: [RFC v7 25/25] powerpc: Enable pkey subsystem

On Thu, Aug 17, 2017 at 05:30:27PM -0300, Thiago Jung Bauermann wrote: > > Ram Pai writes: > > > On Thu, Aug 10, 2017 at 06:27:34PM -0300, Thiago Jung Bauermann wrote: > >> > >> Ram Pai writes: > >> > --- a/arch/powerpc/include/asm/cputable.h > >> >

Re: [RFC v6 21/62] powerpc: introduce execute-only pkey

On Thu, Aug 17, 2017 at 04:35:55PM -0700, Ram Pai wrote: > On Wed, Aug 02, 2017 at 07:40:46PM +1000, Michael Ellerman wrote: > > Thiago Jung Bauermann writes: > > > > > Michael Ellerman writes: > > > > > >> Thiago Jung Bauermann

Re: [RFT PATCH] tpm: ibmvtpm: simplify crq initialization and document crq format

ping? On Fri, 24 Feb 2017 20:35:16 +0100 Michal Suchanek wrote: > The crq is passed in registers and is the same on BE and LE hosts. > However, current implementation allocates a structure on-stack to > represent the crq, initializes the members swapping them to BE, and >

[PATCH v2 20/20] powerpc/mm: Add speculative page fault

This patch enable the speculative page fault on the PowerPC architecture. This will try a speculative page fault without holding the mmap_sem, if it returns with WM_FAULT_RETRY, the mmap_sem is acquired and the traditional page fault processing is done. Support is only provide for BOOK3S_64

[PATCH v2 19/20] x86/mm: Add speculative pagefault handling

From: Peter Zijlstra Try a speculative fault before acquiring mmap_sem, if it returns with VM_FAULT_RETRY continue with the mmap_sem acquisition and do the traditional fault. Signed-off-by: Peter Zijlstra (Intel) [Clearing of FAULT_FLAG_ALLOW_RETRY

[PATCH v2 18/20] perf tools: Add support for the SPF perf event

Add support for the new speculative faults event. Signed-off-by: Laurent Dufour --- tools/include/uapi/linux/perf_event.h | 1 + tools/perf/util/evsel.c | 1 + tools/perf/util/parse-events.c| 4 tools/perf/util/parse-events.l| 1 +

[PATCH v2 17/20] perf: Add a speculative page fault sw event

Add a new software event to count succeeded speculative page faults. Signed-off-by: Laurent Dufour --- include/uapi/linux/perf_event.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h index

[PATCH v2 16/20] mm: Adding speculative page fault failure trace events

This patch a set of new trace events to collect the speculative page fault event failures. Signed-off-by: Laurent Dufour --- include/trace/events/pagefault.h | 87 mm/memory.c | 68

[PATCH v2 15/20] mm: Try spin lock in speculative path

There is a deadlock when a CPU is doing a speculative page fault and another one is calling do_unmap(). The deadlock occurred because the speculative path try to spinlock the pte while the interrupt are disabled. When the other CPU in the unmap's path has locked the pte then is waiting for all

[PATCH v2 14/20] mm: Provide speculative fault infrastructure

From: Peter Zijlstra Provide infrastructure to do a speculative fault (not holding mmap_sem). The not holding of mmap_sem means we can race against VMA change/removal and page-table destruction. We use the SRCU VMA freeing to keep the VMA around. We use the VMA seqcount to

[PATCH v2 13/20] mm: Introduce __page_add_new_anon_rmap()

When dealing with speculative page fault handler, we may race with VMA being split or merged. In this case the vma->vm_start and vm->vm_end fields may not match the address the page fault is occurring. This can only happens when the VMA is split but in that case, the anon_vma pointer of the new

[PATCH v2 12/20] mm: Introduce __vm_normal_page()

When dealing with the speculative fault path we should use the VMA's field cached value stored in the vm_fault structure. Currently vm_normal_page() is using the pointer to the VMA to fetch the vm_flags value. This patch provides a new __vm_normal_page() which is receiving the vm_flags flags

[PATCH v2 11/20] mm: Introduce __maybe_mkwrite()

The current maybe_mkwrite() is getting passed the pointer to the vma structure to fetch the vm_flags field. When dealing with the speculative page fault handler, it will be better to rely on the cached vm_flags value stored in the vm_fault structure. This patch introduce a __maybe_mkwrite()

[PATCH v2 10/20] mm: Introduce __lru_cache_add_active_or_unevictable

The speculative page fault handler which is run without holding the mmap_sem is calling lru_cache_add_active_or_unevictable() but the vm_flags is not guaranteed to remain constant. Introducing __lru_cache_add_active_or_unevictable() which has the vma flags value parameter instead of the vma

[PATCH v2 09/20] mm/migrate: Pass vm_fault pointer to migrate_misplaced_page()

migrate_misplaced_page() is only called during the page fault handling so it's better to pass the pointer to the struct vm_fault instead of the vma. This way during the speculative page fault path the saved vma->vm_flags could be used. Signed-off-by: Laurent Dufour

[PATCH v2 08/20] mm: Protect SPF handler against anon_vma changes

The speculative page fault handler must be protected against anon_vma changes. This is because page_add_new_anon_rmap() is called during the speculative path. In addition, don't try speculative page fault if the VMA don't have an anon_vma structure allocated because its allocation should be

[PATCH v2 07/20] mm: Cache some VMA fields in the vm_fault structure

When handling speculative page fault, the vma->vm_flags and vma->vm_page_prot fields are read once the page table lock is released. So there is no more guarantee that these fields would not change in our back. They will be saved in the vm_fault structure before the VMA is checked for changes.

[PATCH v2 06/20] mm: RCU free VMAs

From: Peter Zijlstra Manage the VMAs with SRCU such that we can do a lockless VMA lookup. We put the fput(vma->vm_file) in the SRCU callback, this keeps files valid during speculative faults, this is possible due to the delayed fput work by Al Viro -- do we need

Re: [PATCH kernel] PCI: Disable IOV before pcibios_sriov_disable()

On 11/08/17 18:19, Alexey Kardashevskiy wrote: > From: Gavin Shan > > The PowerNV platform is the only user of pcibios_sriov_disable(). > The IOV BAR could be shifted by pci_iov_update_resource(). The > warning message in the function is printed if the IOV capability >

[PATCH v2 05/20] mm: Protect VMA modifications using VMA sequence count

The VMA sequence count has been introduced to allow fast detection of VMA modification when running a page fault handler without holding the mmap_sem. This patch provides protection against the VMA modification done in : - madvise() - mremap() - mpol_rebind_policy()

[PATCH v2 04/20] mm: VMA sequence count

From: Peter Zijlstra Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence counts such that we can easily test if a VMA is changed. The unmap_page_range() one allows us to make assumptions about page-tables; when we find the seqcount hasn't changed we can

[PATCH v2 03/20] mm: Introduce pte_spinlock for FAULT_FLAG_SPECULATIVE

When handling page fault without holding the mmap_sem the fetch of the pte lock pointer and the locking will have to be done while ensuring that the VMA is not touched in our back. So move the fetch and locking operations in a dedicated function. Signed-off-by: Laurent Dufour

[PATCH v2 02/20] mm: Prepare for FAULT_FLAG_SPECULATIVE

From: Peter Zijlstra When speculating faults (without holding mmap_sem) we need to validate that the vma against which we loaded pages is still valid when we're ready to install the new PTE. Therefore, replace the pte_offset_map_lock() calls that (re)take the PTL with

[PATCH v2 01/20] mm: Dont assume page-table invariance during faults

From: Peter Zijlstra One of the side effects of speculating on faults (without holding mmap_sem) is that we can race with free_pgtables() and therefore we cannot assume the page-tables will stick around. Remove the reliance on the pte pointer. Signed-off-by: Peter

[PATCH v2 00/20] Speculative page faults

This is a port on kernel 4.13 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore [1]. The idea is to try to handle user space page faults without holding the mmap_sem. This should allow better concurrency for massively threaded process since the page fault

Re: [PATCH v7 3/4] lib/cmdline.c Remove quotes symmetrically.

On Thu, 17 Aug 2017 22:14:30 +0200 Michal Suchanek wrote: > Remove quotes from argument value only if there is qoute on both > sides. > > Signed-off-by: Michal Suchanek > --- > arch/powerpc/kernel/fadump.c | 6 ++ > lib/cmdline.c| 7

Re: [RFC v7 02/25] powerpc: track allocation status of all pkeys

Ram Pai writes: > On Thu, Aug 10, 2017 at 05:25:39PM -0300, Thiago Jung Bauermann wrote: >> >> Ram Pai writes: >> > static inline void pkey_initialize(void) >> > { >> > + int os_reserved, i; >> > + >> >/* disable the pkey system till everything

Re: [RFC v7 25/25] powerpc: Enable pkey subsystem

Ram Pai writes: > On Thu, Aug 10, 2017 at 06:27:34PM -0300, Thiago Jung Bauermann wrote: >> >> Ram Pai writes: >> > --- a/arch/powerpc/include/asm/cputable.h >> > +++ b/arch/powerpc/include/asm/cputable.h >> > @@ -214,6 +214,7 @@ enum { >> > #define

[PATCH v7 4/4] boot/param: add pointer to next argument to unknown parameter callback

The fadump parameter processing re-does the logic of next_arg quote stripping to determine where the argument ends. Pass pointer to the next argument instead to make this more robust. Signed-off-by: Michal Suchanek --- arch/powerpc/kernel/fadump.c | 13 +

[PATCH v7 3/4] lib/cmdline.c Remove quotes symmetrically.

Remove quotes from argument value only if there is qoute on both sides. Signed-off-by: Michal Suchanek --- arch/powerpc/kernel/fadump.c | 6 ++ lib/cmdline.c| 7 ++- 2 files changed, 4 insertions(+), 9 deletions(-) diff --git

[PATCH v7 2/4] powerpc/fadump: update documentation about 'fadump_extra_args=' parameter

From: Hari Bathini With the introduction of 'fadump_extra_args=' parameter to pass additional parameters to fadump (capture) kernel, update documentation about it. Signed-off-by: Hari Bathini Signed-off-by: Michal Suchanek

[PATCH v7 1/4] powerpc/fadump: reduce memory consumption for capture kernel

From: Hari Bathini With fadump (dump capture) kernel booting like a regular kernel, it needs almost the same amount of memory to boot as the production kernel, which is unwarranted for a dump capture kernel. But with no option to disable some of the unnecessary

Re: [PATCH] tpm: vtpm: constify vio_device_id

On Thu, Aug 17, 2017 at 11:04:21PM +0530, Arvind Yadav wrote: > vio_device_id are not supposed to change at runtime. All functions > working with vio_device_id provided by work with > const vio_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [RFC Part1 PATCH v3 12/17] x86/mm: DMA support for SEV memory encryption

On 8/6/2017 10:48 PM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:52PM -0500, Brijesh Singh wrote: From: Tom Lendacky DMA access to memory mapped as encrypted while SEV is active can not be encrypted during device write or decrypted during device read.

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Thu, 17 Aug 2017 10:56:35 + David Laight wrote: > From: Alex Williamson > > Sent: 16 August 2017 17:56 > ... > > Firmware pissing match... Processors running with 8k or less page size > > fall within the recommendations of the PCI spec for register alignment >

Re: [RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

On 8/1/2017 11:02 PM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:51PM -0500, Brijesh Singh wrote: From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

On 08/17/2017 10:32 AM, Bart Van Assche wrote: > On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote: >> On 08/16/2017 01:15 PM, Bart Van Assche wrote: >>> On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote: Linux-next booted with the below warnings on powerpc [ ... ]

Re: [RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

On 8/17/2017 1:55 PM, Tom Lendacky wrote: On 7/28/2017 10:23 AM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:49PM -0500, Brijesh Singh wrote: From: Tom Lendacky The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() functions each

Re: [RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

On 7/28/2017 10:23 AM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:49PM -0500, Brijesh Singh wrote: From: Tom Lendacky The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() functions each have much of the same code. Create a new

Re: [RFC Part1 PATCH v3 08/17] x86/efi: Access EFI data as encrypted when SEV is active

On 7/28/2017 5:31 AM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:48PM -0500, Brijesh Singh wrote: From: Tom Lendacky EFI data is encrypted when the kernel is run under SEV. Update the page table references to be sure the EFI memory areas are accessed

Re: [RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes

On 7/28/2017 3:47 AM, David Laight wrote: From: Borislav Petkov Sent: 27 July 2017 15:59 On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote: From: Tom Lendacky The current code checks only for sme_active() when determining whether to perform the encryption

Re: [PATCH v6 1/2] powerpc/fadump: reduce memory consumption for capture kernel

Hello Michal, Thanks for the review.. On Tuesday 15 August 2017 04:26 PM, Michal Suchánek wrote: Hello, sorry about the late reply. Looks like I had too much faith in the parse_args sanity. Looking closely the parsing happens in next_arg and only outermost quotes are removed. So

Re: [RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes

On 7/27/2017 9:58 AM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote: From: Tom Lendacky The current code checks only for sme_active() when determining whether to perform the encryption attribute change. Include sev_active() in

Re: [RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV

On 7/27/2017 8:31 AM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:46PM -0500, Brijesh Singh wrote: From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, boot data (such as EFI related data, setup data) is encrypted and needs to be accessed

Applied "ASoC: qcom: make snd_pcm_hardware const" to the asoc tree

The patch ASoC: qcom: make snd_pcm_hardware const has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: sh: make snd_pcm_hardware const" to the asoc tree

The patch ASoC: sh: make snd_pcm_hardware const has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: Intel: Skylake: make snd_pcm_hardware const" to the asoc tree

The patch ASoC: Intel: Skylake: make snd_pcm_hardware const has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Applied "ASoC: Intel: Atom: make snd_pcm_hardware const" to the asoc tree

The patch ASoC: Intel: Atom: make snd_pcm_hardware const has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: kirkwood: make snd_pcm_hardware const" to the asoc tree

The patch ASoC: kirkwood: make snd_pcm_hardware const has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: fsl: make snd_pcm_hardware const" to the asoc tree

The patch ASoC: fsl: make snd_pcm_hardware const has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Re: [RFC v7 25/25] powerpc: Enable pkey subsystem

On Thu, Aug 10, 2017 at 06:27:34PM -0300, Thiago Jung Bauermann wrote: > > Ram Pai writes: > > --- a/arch/powerpc/include/asm/cputable.h > > +++ b/arch/powerpc/include/asm/cputable.h > > @@ -214,6 +214,7 @@ enum { > > #define CPU_FTR_DAWR > >

[PATCH] hwrng: pseries: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/char/hw_random/pseries-rng.c | 2 +- 1 file

[PATCH] tpm: vtpm: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/char/tpm/tpm_ibmvtpm.c | 2 +- 1 file changed, 1

Re: [PATCH] net: ibm: ibmvnic: constify vio_device_id

From: Arvind Yadav Date: Thu, 17 Aug 2017 18:52:54 +0530 > vio_device_id are not supposed to change at runtime. All functions > working with vio_device_id provided by work with > const vio_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind

Re: [PATCH] net: ibm: ibmveth: constify vio_device_id

From: Arvind Yadav Date: Thu, 17 Aug 2017 18:52:53 +0530 > vio_device_id are not supposed to change at runtime. All functions > working with vio_device_id provided by work with > const vio_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind

Re: [RFC v7 24/25] powerpc: Deliver SEGV signal on pkey violation

On Fri, Aug 11, 2017 at 08:26:30PM +1000, Michael Ellerman wrote: > Thiago Jung Bauermann writes: > > > Ram Pai writes: > > > >> The value of the AMR register at the time of exception > >> is made available in gp_regs[PT_AMR] of the siginfo. >

Re: [RFC v7 09/25] powerpc: store and restore the pkey state across context switches

On Fri, Aug 11, 2017 at 04:34:19PM +1000, Michael Ellerman wrote: > Thiago Jung Bauermann writes: > > > Ram Pai writes: > >> --- a/arch/powerpc/kernel/process.c > >> +++ b/arch/powerpc/kernel/process.c > >> @@ -42,6 +42,7 @@ > >> #include > >>

Re: [RFC v7 02/25] powerpc: track allocation status of all pkeys

On Fri, Aug 11, 2017 at 03:39:14PM +1000, Michael Ellerman wrote: > Thiago Jung Bauermann writes: > > > Ram Pai writes: > >> static inline void pkey_initialize(void) > >> { > >> + int os_reserved, i; > >> + > >>/* disable the pkey system

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote: > On 08/16/2017 12:21 PM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: > > > As of next-20170809, linux-next on powerpc boot hung with below trace > > > message. > > > > > > [ ... ] > > > > > > A bisection

Re: [RFC v7 02/25] powerpc: track allocation status of all pkeys

On Thu, Aug 10, 2017 at 05:25:39PM -0300, Thiago Jung Bauermann wrote: > > Ram Pai writes: > > static inline void pkey_initialize(void) > > { > > + int os_reserved, i; > > + > > /* disable the pkey system till everything > > * is in place. A patch further down

Re: [PATCH v4 7/7] ima: Support module-style appended signatures for appraisal

> diff --git a/security/integrity/ima/ima_appraise.c > b/security/integrity/ima/ima_appraise.c > index 87d2b601cf8e..5a244ebc61d9 100644 > --- a/security/integrity/ima/ima_appraise.c > +++ b/security/integrity/ima/ima_appraise.c > @@ -190,6 +190,64 @@ int ima_read_xattr(struct dentry *dentry, >

Re: [v6 05/15] mm: don't accessed uninitialized struct pages

On Thu 17-08-17 11:28:23, Pasha Tatashin wrote: > Hi Michal, > > I've been looking through this code again, and I think your suggestion will > work. I did not realize this iterator already exist: > > for_each_free_mem_range() basically iterates through (memory && !reserved) > > This is exactly

Re: [v6 01/15] x86/mm: reserve only exiting low pages

Hi Michal, While working on a bug that was reported to me by "kernel test robot". unable to handle kernel NULL pointer dereference at (null) The issue was that page_to_pfn() on that configuration was looking for a section inside flags fields in "struct page". So, reserved but

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote: > On 08/16/2017 01:15 PM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote: > > > Linux-next booted with the below warnings on powerpc > > > > > > [ ... ] > > > > > > boot warnings: > > > -- > > >

Re: [v6 05/15] mm: don't accessed uninitialized struct pages

Hi Michal, I've been looking through this code again, and I think your suggestion will work. I did not realize this iterator already exist: for_each_free_mem_range() basically iterates through (memory && !reserved) This is exactly what we need here. So, I will update this patch to use this

Re: [PATCH v4 7/7] ima: Support module-style appended signatures for appraisal

On Fri, 2017-08-04 at 19:03 -0300, Thiago Jung Bauermann wrote: > This patch introduces the modsig keyword to the IMA policy syntax to > specify that a given hook should expect the file to have the IMA signature > appended to it. Here is how it can be used in a rule: > > appraise

Re: [PATCH] powerpc: powernv: Fix build error on const discarding

On Wednesday 16 August 2017 06:04 PM, Corentin Labbe wrote: When building a random powerpc kernel I hit this build error: CC arch/powerpc/platforms/powernv/opal-imc.o arch/powerpc/platforms/powernv/opal-imc.c: In function « disable_nest_pmu_counters »:

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

"Paul E. McKenney" writes: > On Wed, Aug 16, 2017 at 05:56:17AM -0700, Paul E. McKenney wrote: >> On Wed, Aug 16, 2017 at 10:43:52PM +1000, Michael Ellerman wrote: >> > "Paul E. McKenney" writes: >> > ... >> > > >> > > commit

[PATCH 0/3] constify scsi vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] scsi: ibmvfc: constify vio_device_id [PATCH 2/3] scsi: ibmvscsi: constify

[PATCH 3/3] scsi: ibmvscsi_tgt: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +- 1 file

[PATCH 2/3] scsi: ibmvscsi: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +- 1 file changed, 1

[PATCH 1/3] scsi: ibmvfc: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/scsi/ibmvscsi/ibmvfc.c | 2 +- 1 file changed, 1

[PATCH] tty: hvcs: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/tty/hvc/hvcs.c | 2 +- 1 file changed, 1

[PATCH] tty: hvc_vio: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/tty/hvc/hvc_vio.c | 2 +- 1 file changed, 1

[PATCH] net: ibm: ibmvnic: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/ethernet/ibm/ibmvnic.c | 2 +- 1 file changed,

[PATCH] net: ibm: ibmveth: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/ethernet/ibm/ibmveth.c | 2 +- 1 file changed,

[PATCH] crypto: nx: 842: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/crypto/nx/nx-842-pseries.c | 2 +- 1 file changed,

[PATCH] crypto: nx: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/crypto/nx/nx.c | 2 +- 1 file changed, 1

Re: [1/5] powerpc: Test MSR_FP and MSR_VEC when enabling/flushing VSX

On Wed, 2017-08-16 at 06:01:14 UTC, Benjamin Herrenschmidt wrote: > VSX uses a combination of the old vector registers, the old FP registers > and new "second halves" of the FP registers. > > Thus when we need to see the VSX state in the thread struct > (flush_vsx_to_thread) or when we'll use the

Re: [PATCH 3/6] powerpc/mm: Ensure cpumask update is ordered

Nicholas Piggin writes: > On Mon, 24 Jul 2017 21:20:07 +1000 > Nicholas Piggin wrote: > >> On Mon, 24 Jul 2017 14:28:00 +1000 >> Benjamin Herrenschmidt wrote: >> >> > There is no guarantee that the various isync's involved with

Re: [PATCH] powerpc/xmon: Exclude all of xmon/ from ftrace

"Naveen N. Rao" writes: > Hi Michael, > Sorry -- was off since last week. No worries. cheers

Re: [PATCH] powerpc: powernv: Fix build error on const discarding

Corentin Labbe writes: > When building a random powerpc kernel I hit this build error: > CC arch/powerpc/platforms/powernv/opal-imc.o > arch/powerpc/platforms/powernv/opal-imc.c: In function «  > disable_nest_pmu_counters »: >

[PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

A system without PCI legacy resources (e.g. ARM64) may find that no default/boot VGA device has been marked, because the VGA arbiter checks for legacy resource decoding before marking a card as default. Split the small bit of code that does default VGA handling out from the arbiter. Add a Kconfig

[PATCH v2 0/1] Split VGA default nomination out from VGA arbiter

This is approach 3, version 2, of my patch series to sort out Xorg autoconfiguration for the Hibmc card beind a Hisilicon bridge on arm64. Approach 1 was a simple quirk for the card+bridge to mark it as default. This higlighted the fact that the default card was picked by the arbiter, which

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

From: Alex Williamson > Sent: 16 August 2017 17:56 ... > Firmware pissing match... Processors running with 8k or less page size > fall within the recommendations of the PCI spec for register alignment > of MMIO regions of the device and this whole problem becomes less of an > issue. Actually if

Re: [PATCH 00/12] ALSA: make snd_pcm_hardware const

On Thu, 17 Aug 2017 11:15:48 +0200, Bhumika Goyal wrote: > > Make these const. > > Bhumika Goyal (12): > ALSA: arm: make snd_pcm_hardware const > ALSA: atmel: make snd_pcm_hardware const > ALSA: drivers: make snd_pcm_hardware const > ALSA: isa: make snd_pcm_hardware const > ALSA: mips:

[PATCH 6/6] ASoC: qcom: make snd_pcm_hardware const

Make this const as it is either passed as the 2nd argument to the function snd_soc_set_runtime_hwparams, which is const or used in a copy operation. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- sound/soc/qcom/lpass-platform.c | 2 +- 1 file changed, 1

[PATCH 5/6] ASoC: sh: make snd_pcm_hardware const

Make these const as they are only passed as the 2nd argument to the function snd_soc_set_runtime_hwparams, which is const. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- sound/soc/sh/dma-sh7760.c | 2 +- sound/soc/sh/fsi.c| 2 +- sound/soc/sh/rcar/core.c |

[PATCH 4/6] ASoC: kirkwood: make snd_pcm_hardware const

Make this const as it is either passed as the 2nd argument to the function snd_soc_set_runtime_hwparams, which is const or used in a copy operation. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- sound/soc/kirkwood/kirkwood-dma.c | 2 +- 1 file changed, 1

[PATCH 3/6] ASoC: Intel: Skylake: make snd_pcm_hardware const

Make this const as it is only passed as the 2nd argument to the function snd_soc_set_runtime_hwparams, which is const. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- sound/soc/intel/skylake/skl-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/6] ASoC: Intel: Atom: make snd_pcm_hardware const

Make this const as it is only used in a copy operation. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c

[PATCH 1/6] ASoC: fsl: make snd_pcm_hardware const

Make these const as they are only passed as the 2nd argument to the function snd_soc_set_runtime_hwparams, which is const. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- sound/soc/fsl/fsl_asrc_dma.c | 2 +- sound/soc/fsl/imx-pcm-fiq.c | 2 +- 2 files changed, 2

[PATCH 0/6] ASoC: make snd_pcm_hardware const

Make these const. Done using Coccinelle Bhumika Goyal (6): ASoC: fsl: make snd_pcm_hardware const ASoC: Intel: Atom: make snd_pcm_hardware const ASoC: Intel: Skylake: make snd_pcm_hardware const ASoC: kirkwood: make snd_pcm_hardware const ASoC: sh: make snd_pcm_hardware const ASoC:

  1   2   >