On Wed, Jan 23, 2019 at 08:28:03AM +0100, Marek Szyprowski wrote:
> Hi Mike,
>
> On 2019-01-23 06:54, Mike Rapoport wrote:
>
> > @@ -37,21 +37,16 @@ int __init __weak
> > early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
> > */
> > end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
>
Hi Mike,
On 2019-01-23 06:54, Mike Rapoport wrote:
...
> Resending it as a formal patch now, I took a liberty to add your Tested-by.
>
> >From a847ca684db29a3c09e4dd2a8a008b35cf36e52f Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Wed, 23 Jan 2019 07:38:50 +0200
> Subject: [PATCH] of: fi
On 1/23/2019 11:24 AM, Mike Rapoport wrote:
On Tue, Jan 22, 2019 at 03:12:54PM +0100, Marc Gonzalez wrote:
On 22/01/2019 15:02, Marc Gonzalez wrote:
On 21/01/2019 18:42, Mike Rapoport wrote:
If I understood correctly, the trouble comes from no-map range allocated in
early_init_dt_alloc_res
On Tue, Jan 22, 2019 at 03:12:54PM +0100, Marc Gonzalez wrote:
> On 22/01/2019 15:02, Marc Gonzalez wrote:
>
> > On 21/01/2019 18:42, Mike Rapoport wrote:
> >
> >> If I understood correctly, the trouble comes from no-map range allocated
> >> in
> >> early_init_dt_alloc_reserved_memory_arch().
>
On 22/01/2019 15:02, Marc Gonzalez wrote:
> On 21/01/2019 18:42, Mike Rapoport wrote:
>
>> If I understood correctly, the trouble comes from no-map range allocated in
>> early_init_dt_alloc_reserved_memory_arch().
>>
>> There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(), bu
On 21/01/2019 18:42, Mike Rapoport wrote:
> If I understood correctly, the trouble comes from no-map range allocated in
> early_init_dt_alloc_reserved_memory_arch().
>
> There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(), but
> memblock_remove() does not do kmemleak_free().
On 1/21/2019 7:24 PM, Marc Gonzalez wrote:
On 21/01/2019 14:35, Rob Herring wrote:
On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
On 21/01/2019 11:57, Marc Gonzalez wrote:
[...]
# echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak
kmemleak: Object 0xffc021e0 (size 209715
On Mon, Jan 21, 2019 at 09:42:07AM -0600, Rob Herring wrote:
> +Mike Rapoport
>
> On Mon, Jan 21, 2019 at 8:37 AM Catalin Marinas
> wrote:
> >
> > On Mon, Jan 21, 2019 at 07:35:11AM -0600, Rob Herring wrote:
> > > On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
> > > >
> > > > On 21/01/2019
On 21/01/2019 15:42, Rob Herring wrote:
+Mike Rapoport
On Mon, Jan 21, 2019 at 8:37 AM Catalin Marinas wrote:
On Mon, Jan 21, 2019 at 07:35:11AM -0600, Rob Herring wrote:
On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
On 21/01/2019 11:57, Marc Gonzalez wrote:
[...]
# echo dump=0xfff
+Mike Rapoport
On Mon, Jan 21, 2019 at 8:37 AM Catalin Marinas wrote:
>
> On Mon, Jan 21, 2019 at 07:35:11AM -0600, Rob Herring wrote:
> > On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
> > >
> > > On 21/01/2019 11:57, Marc Gonzalez wrote:
> > > [...]
> > > > # echo dump=0xffc021e0
On Mon, Jan 21, 2019 at 07:35:11AM -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
> >
> > On 21/01/2019 11:57, Marc Gonzalez wrote:
> > [...]
> > > # echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak
> > > kmemleak: Object 0xffc021e0 (size 2097152):
On 21/01/2019 14:35, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
>>
>> On 21/01/2019 11:57, Marc Gonzalez wrote:
>> [...]
>>> # echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak
>>> kmemleak: Object 0xffc021e0 (size 2097152):
>>> kmemleak: comm "swapp
On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
>
> On 21/01/2019 11:57, Marc Gonzalez wrote:
> [...]
> > # echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak
> > kmemleak: Object 0xffc021e0 (size 2097152):
> > kmemleak: comm "swapper/0", pid 0, jiffies 4294892296
> > kmemleak
On 21/01/2019 12:57, Marc Gonzalez wrote:
> On 19/01/2019 14:28, Catalin Marinas wrote:
>
>> As per Robin's remark, this address seems to be pretty easy to
>> reproduce. It also happens via scan_gray_list() which indicates an
>> object kmemleak was informed about via kmemleak_alloc() (so this
>>
On 21/01/2019 11:57, Marc Gonzalez wrote:
[...]
# echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak
kmemleak: Object 0xffc021e0 (size 2097152):
kmemleak: comm "swapper/0", pid 0, jiffies 4294892296
kmemleak: min_count = 0
kmemleak: count = 0
kmemleak: flags = 0x1
kmemleak:
On 19/01/2019 14:28, Catalin Marinas wrote:
> As per Robin's remark, this address seems to be pretty easy to
> reproduce. It also happens via scan_gray_list() which indicates an
> object kmemleak was informed about via kmemleak_alloc() (so this
> excludes the pfn that Qian noticed).
>
> Can you c
On Fri, Jan 18, 2019 at 04:36:59PM +0100, Marc Gonzalez wrote:
> mount -t debugfs nodev /sys/kernel/debug/
> echo scan > /sys/kernel/debug/kmemleak
>
> Unable to handle kernel paging request at virtual address ffc021e0
[...]
> Call trace:
> scan_block+0x70/0x190
> scan_gray_list+0x108/0
On 18/01/2019 18:38, Qian Cai wrote:
> On 1/18/19 12:05 PM, Marc Gonzalez wrote:
>
>> On 18/01/2019 17:14, Qian Cai wrote:
>>
>>> This looks like something different from the original "invalid PFNs from
>>> pfn_to_online_page()" issue. What's your .config ?
>>
>> Here's my defconfig:
>>
>> # CONFI
On 2019-01-18 3:36 pm, Marc Gonzalez wrote:
Unable to handle kernel paging request at virtual address ffc021e0
I can't help but notice that you seem to get the same address in 4
different logs - if it really is that deterministic then that's quite
the boon for debugging (FWIW my first
On 1/18/19 12:05 PM, Marc Gonzalez wrote:
> On 18/01/2019 17:14, Qian Cai wrote:
>
>> This looks like something different from the original "invalid PFNs from
>> pfn_to_online_page()" issue. What's your .config ?
>
> Here's my defconfig:
>
> # CONFIG_SWAP is not set
> CONFIG_NO_HZ_IDLE=y
> CO
On 18/01/2019 17:14, Qian Cai wrote:
> This looks like something different from the original "invalid PFNs from
> pfn_to_online_page()" issue. What's your .config ?
Here's my defconfig:
# CONFIG_SWAP is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_IKCONFIG=y
CONFI
On 1/18/19 10:36 AM, Marc Gonzalez wrote:
> On 18/01/2019 15:34, Catalin Marinas wrote:
>
>> On Fri, Jan 18, 2019 at 02:36:46PM +0100, Marc Gonzalez wrote:
>>
>>> Trying to diagnose a separate issue, I enabled a raft of debugging options,
>>> including kmemleak. However, it looks like kmemleak
On 18/01/2019 15:34, Catalin Marinas wrote:
> On Fri, Jan 18, 2019 at 02:36:46PM +0100, Marc Gonzalez wrote:
>
>> Trying to diagnose a separate issue, I enabled a raft of debugging options,
>> including kmemleak. However, it looks like kmemleak itself is crashing?
>>
>> We seem to be crashing on t
23 matches
Mail list logo
