[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170608071237.GL1127@mtr-leonro.local>
Date: Thu, 8 Jun 2017 10:12:37 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Felix Manlunas <felix.manlunas@...ium.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
raghu.vatsavayi@...ium.com, derek.chickles@...ium.com,
satananda.burla@...ium.com, ricardo.farrington@...ium.com
Subject: Re: [PATCH net-next 0/3] LiquidIO: avoid VM low memory crashes
On Wed, Jun 07, 2017 at 08:50:45PM -0700, Felix Manlunas wrote:
> From: Rick Farrington <ricardo.farrington@...ium.com>
>
> This patchset addresses issues brought about by low memory conditions
> in a VM. These conditions were only seen when VM's were intentionally
> created with small amounts of memory (for stress testing).
>
> 1. Fix GPF in octeon_init_droq(); zero the allocated block 'recv_buf_list'.
> This prevents a GPF trying to access an invalid 'recv_buf_list[i]' entry
> in octeon_droq_destroy_ring_buffers() if init didn't alloc all entries.
> 2. Don't dereference a NULL ptr in octeon_droq_destroy_ring_buffers().
> 3. For defensive programming, zero the allocated block 'oct->droq[0]' in
> octeon_setup_output_queues() and 'oct->instr_queue[0]' in
> octeon_setup_instr_queues().
>
While these patches are harmless, I don't really understand how
allocating the same arrays just with zeros in it can prevent low memory
crashes. Once you used v[m,z]alloc, you should expect for failures in
these flows and relying on content of that page is not called "solve the
bug".
Thanks
> drivers/net/ethernet/cavium/liquidio/octeon_device.c | 8 ++++----
> drivers/net/ethernet/cavium/liquidio/octeon_droq.c | 6 ++++--
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> --
> 1.8.3.1
>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists