On Sun 03-01-16 20:35:14, Al Viro wrote:
[...]
> BTW, far scarier one is not GFP_NOFS or GFP_IO - there's a weird
> caller passing GFP_ATOMIC to __vmalloc(), for no reason I can guess.
>
> _That_ really couldn't be handled without passing gfp_t to page allocation
> primitives, but I very much
On Sun 03-01-16 20:35:14, Al Viro wrote:
[...]
> BTW, far scarier one is not GFP_NOFS or GFP_IO - there's a weird
> caller passing GFP_ATOMIC to __vmalloc(), for no reason I can guess.
>
> _That_ really couldn't be handled without passing gfp_t to page allocation
> primitives, but I very much
On 2016/01/03 16:12, Al Viro wrote:
> Those, AFAICS, are such callers with GFP_NOIO; however, there's a shitload
> of GFP_NOFS ones. XFS uses memalloc_noio_save(), but a _lot_ of other
> callers do not. For example, all call chains leading to ceph_kvmalloc()
> pass GFP_NOFS and none of them is
On 2016/01/03 16:12, Al Viro wrote:
> Those, AFAICS, are such callers with GFP_NOIO; however, there's a shitload
> of GFP_NOFS ones. XFS uses memalloc_noio_save(), but a _lot_ of other
> callers do not. For example, all call chains leading to ceph_kvmalloc()
> pass GFP_NOFS and none of them is
On Mon, Jan 04, 2016 at 07:12:33AM +1100, Dave Chinner wrote:
> That'd be a nice start, though it doesn't address callers of
> vm_map_ram() which also has hard-coded GFP_KERNEL allocation masks
> for various allocations.
... all 3 of them, that is - XFS, android/ion/ion_heap.c and
v4l2-core. 5
On Sun, Jan 03, 2016 at 07:12:47AM +, Al Viro wrote:
> While trying to write documentation on allocator choice, I've run
> into something odd:
> /*
> * __vmalloc() will allocate data pages and auxillary structures (e.g.
> * pagetables) with GFP_KERNEL, yet we
On Sun, Jan 03, 2016 at 07:12:47AM +, Al Viro wrote:
> Allocation page tables doesn't have gfp argument at all. Trying to propagate
> it down there could be done, but it's not attractive.
While we are at it, is there ever a reason to _not_ pass __GFP_HIGHMEM in
__vmalloc() flags? After
On Mon, Jan 04, 2016 at 07:12:33AM +1100, Dave Chinner wrote:
> That'd be a nice start, though it doesn't address callers of
> vm_map_ram() which also has hard-coded GFP_KERNEL allocation masks
> for various allocations.
... all 3 of them, that is - XFS, android/ion/ion_heap.c and
v4l2-core. 5
On Sun, Jan 03, 2016 at 07:12:47AM +, Al Viro wrote:
> Allocation page tables doesn't have gfp argument at all. Trying to propagate
> it down there could be done, but it's not attractive.
While we are at it, is there ever a reason to _not_ pass __GFP_HIGHMEM in
__vmalloc() flags? After
On Sun, Jan 03, 2016 at 07:12:47AM +, Al Viro wrote:
> While trying to write documentation on allocator choice, I've run
> into something odd:
> /*
> * __vmalloc() will allocate data pages and auxillary structures (e.g.
> * pagetables) with GFP_KERNEL, yet we
While trying to write documentation on allocator choice, I've run
into something odd:
/*
* __vmalloc() will allocate data pages and auxillary structures (e.g.
* pagetables) with GFP_KERNEL, yet we may be under GFP_NOFS context
* here. Hence we need to
While trying to write documentation on allocator choice, I've run
into something odd:
/*
* __vmalloc() will allocate data pages and auxillary structures (e.g.
* pagetables) with GFP_KERNEL, yet we may be under GFP_NOFS context
* here. Hence we need to
12 matches
Mail list logo
