All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Vlad Yasevich <vladislav.yasevich@hp.com>,
	Sridhar Samudrala <sri@us.ibm.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 18/24] sctp: Remove unnecessary OOM logging messages
Date: Mon, 29 Aug 2011 23:43:28 +0200	[thread overview]
Message-ID: <1314654209.2563.7.camel@edumazet-laptop> (raw)
In-Reply-To: <21b4d996c8861373ac77d427914ec7882fe0c83e.1314650069.git.joe@perches.com>

Le lundi 29 août 2011 à 14:17 -0700, Joe Perches a écrit :
> Removing unnecessary messages saves code and text.
> 
> Site specific OOM messages are duplications of a generic MM
> out of memory message and aren't really useful, so just
> delete them.
> 
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  net/sctp/protocol.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 91784f4..0801444 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1326,7 +1326,6 @@ SCTP_STATIC __init int sctp_init(void)
>  			__get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order);
>  	} while (!sctp_assoc_hashtable && --order > 0);
>  	if (!sctp_assoc_hashtable) {
> -		pr_err("Failed association hash alloc\n");
>  		status = -ENOMEM;
>  		goto err_ahash_alloc;
>  	}
> @@ -1340,7 +1339,6 @@ SCTP_STATIC __init int sctp_init(void)
>  	sctp_ep_hashtable = (struct sctp_hashbucket *)
>  		kmalloc(64 * sizeof(struct sctp_hashbucket), GFP_KERNEL);
>  	if (!sctp_ep_hashtable) {
> -		pr_err("Failed endpoint_hash alloc\n");
>  		status = -ENOMEM;
>  		goto err_ehash_alloc;
>  	}
> @@ -1359,7 +1357,6 @@ SCTP_STATIC __init int sctp_init(void)
>  			__get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order);
>  	} while (!sctp_port_hashtable && --order > 0);
>  	if (!sctp_port_hashtable) {
> -		pr_err("Failed bind hash alloc\n");
>  		status = -ENOMEM;
>  		goto err_bhash_alloc;
>  	}


It would be nice if you could avoid all these patches, that you dont
even read.

As I already told you in the past, __GFP_NOWARN dont print generic OOM
messages.

Its not because I told Wang Shaoyan not adding a useless "pr_err("Out of
memory\n");" in last gianfar patch, that you have to remove all
messages, with one hundred or more patches.

If I remember well, you even disagreed at that time.

Furthermore, a failed vmalloc() is not guaranteed to emit an OOM
message, is it ?




WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Vlad Yasevich <vladislav.yasevich@hp.com>,
	Sridhar Samudrala <sri@us.ibm.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 18/24] sctp: Remove unnecessary OOM logging messages
Date: Mon, 29 Aug 2011 21:43:28 +0000	[thread overview]
Message-ID: <1314654209.2563.7.camel@edumazet-laptop> (raw)
In-Reply-To: <21b4d996c8861373ac77d427914ec7882fe0c83e.1314650069.git.joe@perches.com>

Le lundi 29 août 2011 à 14:17 -0700, Joe Perches a écrit :
> Removing unnecessary messages saves code and text.
> 
> Site specific OOM messages are duplications of a generic MM
> out of memory message and aren't really useful, so just
> delete them.
> 
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  net/sctp/protocol.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 91784f4..0801444 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1326,7 +1326,6 @@ SCTP_STATIC __init int sctp_init(void)
>  			__get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order);
>  	} while (!sctp_assoc_hashtable && --order > 0);
>  	if (!sctp_assoc_hashtable) {
> -		pr_err("Failed association hash alloc\n");
>  		status = -ENOMEM;
>  		goto err_ahash_alloc;
>  	}
> @@ -1340,7 +1339,6 @@ SCTP_STATIC __init int sctp_init(void)
>  	sctp_ep_hashtable = (struct sctp_hashbucket *)
>  		kmalloc(64 * sizeof(struct sctp_hashbucket), GFP_KERNEL);
>  	if (!sctp_ep_hashtable) {
> -		pr_err("Failed endpoint_hash alloc\n");
>  		status = -ENOMEM;
>  		goto err_ehash_alloc;
>  	}
> @@ -1359,7 +1357,6 @@ SCTP_STATIC __init int sctp_init(void)
>  			__get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order);
>  	} while (!sctp_port_hashtable && --order > 0);
>  	if (!sctp_port_hashtable) {
> -		pr_err("Failed bind hash alloc\n");
>  		status = -ENOMEM;
>  		goto err_bhash_alloc;
>  	}


It would be nice if you could avoid all these patches, that you dont
even read.

As I already told you in the past, __GFP_NOWARN dont print generic OOM
messages.

Its not because I told Wang Shaoyan not adding a useless "pr_err("Out of
memory\n");" in last gianfar patch, that you have to remove all
messages, with one hundred or more patches.

If I remember well, you even disagreed at that time.

Furthermore, a failed vmalloc() is not guaranteed to emit an OOM
message, is it ?




  parent reply	other threads:[~2011-08-29 21:43 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-29 21:17 [PATCH 00/24] net: Remove unnecessary OOM logging messages Joe Perches
2011-08-29 21:17 ` [Bridge] " Joe Perches
2011-08-29 21:17 ` [B.A.T.M.A.N.] " Joe Perches
2011-08-29 21:17 ` Joe Perches
2011-08-29 21:17 ` Joe Perches
2011-08-29 21:17 ` [PATCH 01/24] 802: " Joe Perches
2011-08-29 21:17 ` [PATCH 02/24] 9p: " Joe Perches
2011-08-29 21:17 ` [PATCH 03/24] atm: " Joe Perches
2011-08-29 21:17 ` [PATCH 04/24] ax25: " Joe Perches
2011-08-29 22:42   ` Joerg Reuter
2011-08-29 21:17 ` [PATCH 05/24] batman-adv: " Joe Perches
2011-08-29 21:17   ` [B.A.T.M.A.N.] " Joe Perches
2011-08-30 10:58   ` Marek Lindner
2011-08-30 10:58     ` Marek Lindner
2011-08-30 10:58     ` Marek Lindner
2011-08-29 21:17 ` [PATCH 06/24] netfilter: " Joe Perches
2011-08-29 21:17   ` [Bridge] " Joe Perches
2011-08-30 12:46   ` Patrick McHardy
2011-08-30 12:46     ` [Bridge] " Patrick McHardy
2011-08-30 16:13     ` Joe Perches
2011-08-30 16:13       ` [Bridge] " Joe Perches
2011-08-30 17:55     ` David Miller
2011-08-30 17:55       ` [Bridge] " David Miller
2011-08-31 10:13       ` Patrick McHardy
2011-08-31 10:13         ` [Bridge] " Patrick McHardy
2011-10-11  0:15         ` Pablo Neira Ayuso
2011-08-29 21:17 ` [PATCH 07/24] can: " Joe Perches
2011-08-31 17:11   ` Oliver Hartkopp
2011-08-29 21:17 ` [PATCH 08/24] ceph: " Joe Perches
2011-08-29 21:17 ` [PATCH 09/24] decnet: " Joe Perches
2011-08-29 21:17 ` [PATCH 10/24] econet: " Joe Perches
2011-08-29 21:17 ` [PATCH 11/24] iucv: " Joe Perches
2011-08-29 21:17 ` [PATCH 12/24] mac80211: " Joe Perches
2011-08-29 21:17 ` [PATCH 13/24] netrom: " Joe Perches
2011-08-29 21:17 ` [PATCH 14/24] rds: " Joe Perches
2011-08-29 21:17 ` [PATCH 15/24] rfkill: " Joe Perches
2011-08-29 21:17 ` [PATCH 16/24] rose: " Joe Perches
2011-08-29 21:17 ` [PATCH 17/24] sched: " Joe Perches
2011-08-30 22:27   ` jamal
2011-08-29 21:17 ` [PATCH 18/24] sctp: " Joe Perches
2011-08-29 21:17   ` Joe Perches
2011-08-29 21:29   ` Vladislav Yasevich
2011-08-29 21:29     ` Vladislav Yasevich
2011-08-29 21:43   ` Eric Dumazet [this message]
2011-08-29 21:43     ` Eric Dumazet
2011-08-29 21:51     ` Eric Dumazet
2011-08-29 21:51       ` Eric Dumazet
2011-08-29 22:15       ` David Miller
2011-08-29 22:15         ` David Miller
2011-09-01  0:25         ` Joe Perches
2011-09-01  0:25           ` Joe Perches
2011-08-30  1:21     ` Joe Perches
2011-08-30  1:21       ` Joe Perches
2011-08-29 21:17 ` [PATCH 19/24] sunrpc: " Joe Perches
2011-08-29 21:36   ` Myklebust, Trond
2011-08-29 21:37     ` David Miller
2011-08-29 21:54       ` Boaz Harrosh
2011-08-29 21:54         ` Boaz Harrosh
2011-08-29 22:03         ` David Miller
2011-08-29 22:03           ` David Miller
2011-08-29 23:25           ` Myklebust, Trond
2011-08-29 23:33             ` Boaz Harrosh
2011-08-29 23:33               ` Boaz Harrosh
2011-08-30  2:35             ` David Miller
2011-08-30  2:35               ` David Miller
2011-08-29 22:08         ` Myklebust, Trond
2011-08-29 22:08           ` Myklebust, Trond
2011-08-29 22:08           ` Myklebust, Trond
2011-08-29 21:17 ` [PATCH 20/24] tipc: " Joe Perches
2011-08-29 21:17 ` [PATCH 21/24] wanrouter: " Joe Perches
2011-08-29 21:17 ` [PATCH 22/24] wireless: " Joe Perches
2011-08-29 21:17 ` [PATCH 23/24] x25: " Joe Perches
2011-08-29 21:17 ` [PATCH 24/24] net: " Joe Perches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1314654209.2563.7.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sri@us.ibm.com \
    --cc=vladislav.yasevich@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.