On Thu, Sep 20, 2018 at 11:51 PM, Christoph Hellwig wrote:
> On Thu, Sep 20, 2018 at 12:08:28PM -0700, Max Filippov wrote:
>> I'm not familiar with the details of alloc_contig_range implementation, but
>> I don't see how gfp_mask is used to limit allocation to non-high memory.
>> So when alloc_con
> On Thu, Sep 20, 2018 at 12:08:28PM -0700, Max Filippov wrote:
> > I'm not familiar with the details of alloc_contig_range implementation, but
> > I don't see how gfp_mask is used to limit allocation to non-high memory.
> > So when alloc_contig_range gets start and end PFNs in high memory
> > (fro
On Thu, Sep 20, 2018 at 11:08 AM, Christoph Hellwig wrote:
> On Thu, Sep 20, 2018 at 10:44:55AM -0700, Max Filippov wrote:
>> Hi Christoph,
>>
>> On Thu, Sep 20, 2018 at 10:15 AM, Christoph Hellwig wrote:
>> > This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
>> >
>> > We explicitly c
On Thu, Sep 20, 2018 at 10:44:55AM -0700, Max Filippov wrote:
> Hi Christoph,
>
> On Thu, Sep 20, 2018 at 10:15 AM, Christoph Hellwig wrote:
> > This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
> >
> > We explicitly clear GFP_HIGHMEM from the allowed dma flags at the beginning
> > of
Hi Christoph,
On Thu, Sep 20, 2018 at 10:15 AM, Christoph Hellwig wrote:
> This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
>
> We explicitly clear GFP_HIGHMEM from the allowed dma flags at the beginning
> of the function (and the generic dma_alloc_attr function calling us does the
>
This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
We explicitly clear GFP_HIGHMEM from the allowed dma flags at the beginning
of the function (and the generic dma_alloc_attr function calling us does the
same!), so this code just adds dead wood.
Signed-off-by: Christoph Hellwig
---
a