On Thu, Oct 25, 2018 at 09:37:59AM -0300, Rafael David Tinoco wrote:
> Is it okay to propose using only MAX_PHYSMEM_BITS for zsmalloc (like
> it was before commit 02390b87) instead, and make sure *at least* ARM
> 32/64 and x86/x64, for now, have it defined outside sparsemem headers
> as well ?
It
Hi Rafael,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux-sof-driver/master]
[also build test WARNING on v4.19 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/
> MAX_PHYSMEM_BITS is a definition for sparsemem, and is only visible
> when sparsemem is enabled. When sparsemem is disabled, asm/sparsemem.h
> is not included (and should not be included) which means there is no
> MAX_PHYSMEM_BITS definition.
Missed that part :\, tks.
> I don't think zsmalloc.
On Wed, Oct 24, 2018 at 10:27:44PM -0300, Rafael David Tinoco wrote:
> On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> physical frame number might be so big that zsmalloc obj encoding (to
> location) will break IF architecture does not re-define
> MAX_PHYSMEM_BITS, causing:
On Thu, Oct 25, 2018 at 2:29 AM, Sergey Senozhatsky
wrote:
> On (10/24/18 22:27), Rafael David Tinoco wrote:
>> static unsigned long location_to_obj(struct page *page, unsigned int
>> obj_idx)
>> {
>> - unsigned long obj;
>> + unsigned long obj, pfn;
>> +
>> + pfn = page_to_pfn(page
On (10/24/18 22:27), Rafael David Tinoco wrote:
> static unsigned long location_to_obj(struct page *page, unsigned int obj_idx)
> {
> - unsigned long obj;
> + unsigned long obj, pfn;
> +
> + pfn = page_to_pfn(page);
> +
> + if (unlikely(OBJ_OVERFLOW(pfn)))
> + BUG();
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break IF architecture does not re-define
MAX_PHYSMEM_BITS, causing:
[ 497.097843]
===
7 matches
Mail list logo
