[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150413003333.GA17193@honli.nay.redhat.com>
Date: Mon, 13 Apr 2015 08:33:33 +0800
From: Honggang LI <honli@...hat.com>
To: Eli Cohen <eli@...lanox.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [linux-next PATCH] mlx5: wrong page mask if
CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures
On Sun, Apr 12, 2015 at 03:04:16PM +0000, Eli Cohen wrote:
> Good catch, thanks!
>
> There are more places in this file where PAGE_MASK is wrongly used. Need to fix them as well.
>
Yes, replaced all of the PAGE_MASK in the file. Please see attched new
patch.
> Also, see below [Eli]
>
> @@ -241,7 +243,7 @@ static void free_4k(struct mlx5_core_dev *dev, u64 addr) static int alloc_system_page(struct mlx5_core_dev *dev, u16 func_id) {
> struct page *page;
> - u64 addr;
> + u64 addr = 0; [Eli] Why is this required?
For 32bit architectures, if CONFIG_ARCH_DMA_ADDR_T_64BIT disabled and
physical memory is less than 4GB, dma_map_page will return an u32 integer
less than 0xffff_ffff. And if addr had been initialized with random
rubbish in the stack of alloc_system_page, the high four bytes is
unpredictable. The new mask, MLX5_NUM_4K_IN_PAGE, will reserve the high
four bytes. So, free_4k/find_fw_page will randomly failed.
thanks
> int err;
> int nid = dev_to_node(&dev->pdev->dev);
>
> --
> 1.8.3.1
>
View attachment "0001-mlx5-wrong-page-mask-if-CONFIG_ARCH_DMA_ADDR_T_64BIT.patch" of type "text/plain" (3201 bytes)
Powered by blists - more mailing lists