netdev - Re: [PATCH] ehea: Add some info messages and fix an issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4D2703B9.3080800@linux.vnet.ibm.com>
Date:	Fri, 07 Jan 2011 10:14:49 -0200
From:	Breno Leitao <leitao@...ux.vnet.ibm.com>
To:	Anton Blanchard <anton@...ba.org>
CC:	joe@...ches.com, netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] ehea: Add some info messages and fix an issue

Hi Anton,

On 01/07/2011 01:24 AM, Anton Blanchard wrote:
> It looks like you are now only initialising half the ring, but still
>  telling the hardware to use the whole ring. Once you get through the
>  entire ring once the errors go away.
You are correct. The problem in the past ehea_init_fill_rq1() wasn't
respecting the nr_rq1a parameter. So, every time ehea_init_fill_rqX()
was trying to allocated the entire skb arrary, and assume that the
entire array was allocated, which wasn't correct.

My patch just allocate the requested number of skbs (described in
nr_rq1a) in skb array, and tell hea that only that amount of skb were
allocated (via doorbell).

On the other side, ehea_proc_rwqes() tries to maximize the array usage,
meaning that if the array is not completely used, it'd try to allocate
an skb "on-the-fly", and this is expected (For example, when you
initialize the system on memory pressure)

That is why I sent another patch that turns this message a netif_info()
instead of a netif_error() (as it was in the past). The commit id for
this patch is 782615aea84e57dc7f2f922cea823df3de635a78

So, although this behaviour is completely expected, this code path
should only being executed on memory pressure. But I am suspecting this
code path is execute more often than I'd expect. Let me investigate this.

Thanks
Breno
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html