>
> 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 Nov 29, 2019, at 7:29 AM, Daniel Axtens wrote:
>
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
On Fri, Nov 29, 2019 at 1:29 PM Daniel Axtens wrote:
> >>> 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
>>> 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.g.
> fs/xfs/xfs_buf.c:
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 held by kworker/1:1/44:
>> #0: ff
On 11/29/19 2:47 PM, Dmitry Vyukov wrote:
> On Fri, Nov 29, 2019 at 12:38 PM Andrey Ryabinin
> wrote:
>
>
> Not sure if it's the same or not. Is it addressed by something in flight?
>
> My config:
> https://gist.githubusercontent.com/dvyukov/36c7be311fdec9cd51c649f7c3cb2
On 11/29/19 2:02 PM, Dmitry Vyukov wrote:
> On Fri, Nov 29, 2019 at 11:58 AM Dmitry Vyukov wrote:
>>
>> On Fri, Nov 29, 2019 at 11:43 AM Dmitry Vyukov wrote:
>>>
>>> On Tue, Nov 19, 2019 at 10:54 AM Andrey Ryabinin
>>> wrote:
On 11/18/19 6:29 AM, Daniel Axtens wrote:
> Qian Cai writ
On Fri, Nov 29, 2019 at 11:43 AM Dmitry Vyukov wrote:
>
> On Tue, Nov 19, 2019 at 10:54 AM Andrey Ryabinin
> wrote:
> > On 11/18/19 6:29 AM, Daniel Axtens wrote:
> > > Qian Cai writes:
> > >
> > >> On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote:
> > >>> /*
> > >>> * In this func
On 11/18/19 6:29 AM, Daniel Axtens wrote:
> Qian Cai writes:
>
>> On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote:
>>> /*
>>> * In this function, newly allocated vm_struct has VM_UNINITIALIZED
>>> * flag. It means that vm_struct is not fully initialized.
>>> @@ -3377,6 +34
Qian Cai writes:
> On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote:
>> /*
>> * In this function, newly allocated vm_struct has VM_UNINITIALIZED
>> * flag. It means that vm_struct is not fully initialized.
>> @@ -3377,6 +3411,9 @@ struct vm_struct **pcpu_get_vm_areas(const
On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote:
> /*
>* In this function, newly allocated vm_struct has VM_UNINITIALIZED
>* flag. It means that vm_struct is not fully initialized.
> @@ -3377,6 +3411,9 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned
> long *offs
Hook into vmalloc and vmap, and dynamically allocate real shadow
memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mapp
12 matches
Mail list logo
