Re: [patch v2 4/4] mm, mempool: poison elements backed by page allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 31 Mar 2015, Andrey Ryabinin wrote:

> > We don't have a need to set PAGE_EXT_DEBUG_POISON on these pages sitting 
> > in the reserved pool, nor do we have a need to do kmap_atomic() since it's 
> > already mapped and must be mapped to be on the reserved pool, which is 
> > handled by mempool_free().
> > 
> 
> Hmm.. I just realized that this statement might be wrong.
> Why pages has to be mapped to be on reserved pool?
> mempool could be used for highmem pages and there is no need to kmap()
> until these pages will be used.
> 
> drbd (drivers/block/drbd) already uses mempool for highmem pages:
> 

Yes, you're exactly right, I didn't see this because the mempool is 
created in one file and then solely used in another file, but regardless 
we still need protection from this usecase.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]