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]
Date:	Thu, 9 Jun 2016 15:06:23 -0700
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	Hariprasad Shenai <hariprasad@...lsio.com>
Cc:	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	nirranjan@...lsio.com
Subject: Re: [PATCH net-next] net: Reduce queue allocation to one in kdump kernel

On Wed, Jun 8, 2016 at 5:39 AM, Hariprasad Shenai
<hariprasad@...lsio.com> wrote:
> When in kdump kernel, reduce memory usage by only using a single Queue
> Set for multiqueue devices. So make netif_get_num_default_rss_queues()
> return one, when in kdump kernel.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@...lsio.com>
> ---
>  net/core/dev.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 904ff431d570..161c4627a798 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -139,6 +139,7 @@
>  #include <linux/hrtimer.h>
>  #include <linux/netfilter_ingress.h>
>  #include <linux/sctp.h>
> +#include <linux/crash_dump.h>
>
>  #include "net-sysfs.h"
>
> @@ -2249,7 +2250,8 @@ EXPORT_SYMBOL(netif_set_real_num_rx_queues);
>   */
>  int netif_get_num_default_rss_queues(void)
>  {
> -       return min_t(int, DEFAULT_MAX_NUM_RSS_QUEUES, num_online_cpus());
> +       return is_kdump_kernel() ?
> +               1 : min_t(int, DEFAULT_MAX_NUM_RSS_QUEUES, num_online_cpus());

IIRC, kdump kernel already uses cpus=1, or at least you can tell how many
CPU's you want in kdump config.

This change doesn't make any sense to me, we don't want to check
for kdump for every of such places, do we?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ