CONFIG_RELOCATABLE and CONFIG_KASAN cannot be enabled at the same time
on ppce500 fsl_booke. All functions called before kasan_early_init()
should be disabled with kasan check. When CONFIG_RELOCATABLE is enabled
on ppce500 fsl_booke, relocate_init() is called before kasan_early_init()
which trigger
On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote:
> Changes since v4:
>
> - v4 can be seen here:
> http://lists.infradead.org/pipermail/kexec/2019-November/023961.html
> - Addressed comments from Dave and added patches for documenting
> new variables appended to v
_locked(vms[area], vas[area], VM_ALLOC,
> > > pcpu_get_vm_areas);
> > > + }
> > > + spin_unlock(&vmap_area_lock);
> > >
> > > + /* populate the shadow space outside of the lock */
> > >
On Mon 25-11-19 15:10:33, John Hubbard wrote:
> 1. Convert from get_user_pages() to pin_user_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page(). In this case, do so via put_user_pages_dirty_lock().
>
> That has the side effect of calling set_page_dirty_lock
t;>>>
>>>>> setup_vmalloc_vm_locked(vms[area], vas[area], VM_ALLOC,
>>>>> pcpu_get_vm_areas);
>>>>> + }
>>>>> + spin_unlock(&vmap_area_lock);
>>>>>
>&g
;b_addr = vm_map_ram(bp->b_pages,
bp->b_page_count,
>
> BUG: unable to handle page fault for address: f52005b8
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
> Oops: 00
Hi Dmitry,
>> I am testing this support on next-20191129 and seeing the following warnings:
>>
>> BUG: sleeping function called from invalid context at mm/page_alloc.c:4681
>> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 44, name: kworker/1:1
>> 4 locks
Hi all,
Commit
6f090192f822 ("x86/efi: remove unused variables")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpwOkerSneth.pgp
Description: OpenPGP digital signature
Hi all,
hmm, that subject is completely wrong, sorry.
On Fri, 29 Nov 2019 23:12:00 +1100 Stephen Rothwell
wrote:
>
> Commit
>
> 6f090192f822 ("x86/efi: remove unused variables")
>
> is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpUTv7q4WJWs.pgp
Description
e involved?
Regards,
Daniel
>
>>
>> BUG: unable to handle page fault for address: f52005b8
>> #PF: supervisor read access in kernel mode
>> #PF: error_code(0x) - not-present page
>> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
>> Oops: 000
gt;
> >>
> >> BUG: unable to handle page fault for address: f52005b8
> >> #PF: supervisor read access in kernel mode
> >> #PF: error_code(0x) - not-present page
> >> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
> >> Oops: 00
Le 29/11/2019 à 08:46, Christophe Leroy a écrit :
Le 29/11/2019 à 08:04, Lexi Shao a écrit :
CONFIG_RELOCATABLE and CONFIG_KASAN cannot be enabled at the same time
on ppce500 fsl_booke. All functions called before kasan_early_init()
should be disabled with kasan check. When CONFIG_RELOCATAB
When enabling CONFIG_RELOCATABLE and CONFIG_KASAN on FSL_BOOKE,
the kernel doesn't boot.
relocate_init() requires KASAN early shadow area to be set up because
it needs access to the device tree through generic functions.
Call kasan_early_init() before calling relocate_init()
Reported-by: Lexi Sh
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-function-declaration]
iovec.iov_base = kmap(iter->bvec->bv_page)
^
fs/io_uring.c:1628:19: warning: assignment makes
Daniel
>
>>
>>>
>>> BUG: unable to handle page fault for address: f52005b8
>>> #PF: supervisor read access in kernel mode
>>> #PF: error_code(0x) - not-present page
>>> PGD 7ffcd067 P4D 7ffcd067 PUD 2cd10067 PMD 66d76067 PTE 0
&
I've been looking at phandle_cache and noticed the following: The raw
phandle value as generated by dtc starts at zero and is incremented by
one for each phandle entry. The qemu pSeries model is using Slof (which
is probably the same thing as used on real hardware) and this looks like
a poiner valu
>
> Nope, it's vm_map_ram() not being handled
Another suspicious one. Related to kasan/vmalloc?
>>>
>>> Very likely the same as with ion:
>>>
>>> # git grep vm_map_ram|grep xfs
>>> fs/xfs/xfs_buf.c:* vm_map_ram() will allocate auxiliary
>>> structures (e
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-function-declaration]
iovec.iov_base = kmap(iter->bvec->bv_page)
^
Le 29/11/2019 à 17:04, Jens Axboe a écrit :
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-function-declaration]
iovec.iov_base = km
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Le 29/11/2019 à 17:04, Jens Axboe a écrit :
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-f
Hi!
On Wed, Nov 27, 2019 at 04:15:15PM +0100, Christophe Leroy wrote:
> Le 27/11/2019 à 15:59, Segher Boessenkool a écrit :
> >On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
> >>So what do we do ? We just drop the "r2" clobber ?
> >
> >You have to make sure your asm code works f
- Resending the v5 version as Will Deacon reported that the patchset was
split into two seperate threads while sending out. It was an issue
with my 'msmtp' settings which is now fixed.
Changes since v4:
- v4 can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-N
Right now user-space tools like 'makedumpfile' and 'crash' need to rely
on a best-guess method of determining value of 'MAX_PHYSMEM_BITS'
supported by underlying kernel.
This value is used in user-space code to calculate the bit-space
required to store a section for SPARESMEM (similar to the exist
- Resending the v5 version as Will Deacon reported that the patchset was
split into two seperate threads while sending out. It was an issue
with my 'msmtp' settings which seems to be now fixed. Please ignore
all previous v5 versions.
Changes since v4:
- v4 can be seen here:
Right now user-space tools like 'makedumpfile' and 'crash' need to rely
on a best-guess method of determining value of 'MAX_PHYSMEM_BITS'
supported by underlying kernel.
This value is used in user-space code to calculate the bit-space
required to store a section for SPARESMEM (similar to the exist
vabits_actual variable on arm64 indicates the actual VA space size,
and allows a single binary to support both 48-bit and 52-bit VA
spaces.
If the ARMv8.2-LVA optional feature is present, and we are running
with a 64KB page size; then it is possible to use 52-bits of address
space for both userspa
Fix a simple typo in arm64/memory.rst
Cc: Jonathan Corbet
Cc: James Morse
Cc: Mark Rutland
Cc: Will Deacon
Cc: Steve Capper
Cc: Catalin Marinas
Cc: Ard Biesheuvel
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Bhupesh S
Add documentation for 'MAX_PHYSMEM_BITS' variable being added to
vmcoreinfo.
'MAX_PHYSMEM_BITS' defines the maximum supported physical address
space memory.
Cc: Boris Petkov
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: James Morse
Cc: Will Deacon
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Benj
Add documentation for TCR_EL1.T1SZ variable being added to
vmcoreinfo.
It indicates the size offset of the memory region addressed by TTBR1_EL1
and hence can be used for determining the vabits_actual value.
Cc: James Morse
Cc: Mark Rutland
Cc: Will Deacon
Cc: Steve Capper
Cc: Catalin Marinas
Hi Will,
On Fri, Nov 29, 2019 at 3:54 PM Will Deacon wrote:
>
> On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote:
> > Changes since v4:
> >
> > - v4 can be seen here:
> > http://lists.infradead.org/pipermail/kexec/2019-November/023961.html
> > - Addressed comments
On 11/29/19 10:07 AM, Pavel Begunkov wrote:
On 29/11/2019 20:16, Jens Axboe wrote:
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Reverting commit 311ae9e159d8 ("io_uring: fix dead-hung for non-iter
fixed rw") clears the failure.
Most likely an #include is missing.
Huh weird how the build bot
On 11/29/19 3:23 AM, Jan Kara wrote:
On Mon 25-11-19 15:10:33, John Hubbard wrote:
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of
Hi Michael,
On Thu, Nov 28, 2019 at 7:38 PM Michael Walle wrote:
>
> The LS1028A SoC uses the same interrupt line for adjacent SAIs. Use
> IRQF_SHARED to be able to use these SAIs simultaneously.
On i.MX8M SAI5 and SAI6 share the same interrupt number too:
Reviewed-by: Fabio Estevam
Thanks
>Le 29/11/2019 à 08:46, Christophe Leroy a écrit :
>>
>>
>> Le 29/11/2019 à 08:04, Lexi Shao a écrit :
>>> CONFIG_RELOCATABLE and CONFIG_KASAN cannot be enabled at the same
>>> time on ppce500 fsl_booke. All functions called before
>>> kasan_early_init() should be disabled with kasan check. When
>>
On 11/29/19 9:10 AM, Sebastian Andrzej Siewior wrote:
> I've been looking at phandle_cache and noticed the following: The raw
> phandle value as generated by dtc starts at zero and is incremented by
> one for each phandle entry. The qemu pSeries model is using Slof (which
> is probably the same thi
35 matches
Mail list logo
