netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: davem@davemloft.net, linux-sctp@vger.kernel.org,
	netdev@vger.kernel.org, Vlad Yasevich <vyasevich@gmail.com>
Subject: Re: [PATCH net 2/3] net: sctp: fix panic on duplicate ASCONF chunks
Date: Mon, 13 Oct 2014 01:25:11 +0200	[thread overview]
Message-ID: <543B0DD7.7000900@redhat.com> (raw)
In-Reply-To: <20141012014233.GA16360@localhost.localdomain>

On 10/12/2014 03:42 AM, Neil Horman wrote:
> On Sat, Oct 11, 2014 at 12:02:31AM +0200, Daniel Borkmann wrote:
>> On 10/10/2014 05:39 PM, Neil Horman wrote:
>> ...
>>> Is it worth adding a WARN_ON, to indicate that two ASCONF chunks have been
>>> received with duplicate serials?
>>
>> Don't think so, as this would be triggerable from outside.
>>
> WARN_ON_ONCE then, per serial number?

Sorry, but no. If someone seriously runs that in production and it
triggers a WARN() from outside, admins will start sending us bug
reports that apparently something with the kernel code is wrong.

WARN() should only be used if we have some *internal* unexpected bug,
but can still fail gracefully. This would neither be an actual code bug
nor would it be an internally triggered one, plus we add unnecessary
complexity to the code. Similarly, for those reasons we don't WARN()
and throw a stack trace when we receive, say, an skb of invalid length
elsewhere.

I'd also like to avoid any additional pr_debug().

I don't think people enable them in production, and if they really do,
it's too late anyway as we already have received this chunk. If anything,
I'd rather like to see debugging code further removed as we have already
different facilities in the kernel for runtime debugging that are much
more powerful.

  parent reply	other threads:[~2014-10-12 23:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09 20:55 [PATCH net 0/3] SCTP fixes Daniel Borkmann
2014-10-09 20:55 ` [PATCH net 1/3] net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks Daniel Borkmann
2014-10-10 10:04   ` Joshua Kinard
2014-10-10 22:06     ` Daniel Borkmann
2014-10-10 14:48   ` Neil Horman
2014-10-09 20:55 ` [PATCH net 2/3] net: sctp: fix panic on duplicate " Daniel Borkmann
2014-10-10 15:39   ` Neil Horman
2014-10-10 22:02     ` Daniel Borkmann
2014-10-12  1:42       ` Neil Horman
2014-10-12  7:15         ` Vladislav Yasevich
2014-10-12 23:25         ` Daniel Borkmann [this message]
2014-10-15  2:58           ` Neil Horman
2014-10-15 23:13             ` Daniel Borkmann
2014-10-15  7:51           ` Vlad Yasevich
2014-10-09 20:55 ` [PATCH net 3/3] net: sctp: fix remote memory pressure from excessive queueing Daniel Borkmann
2014-10-14 16:46 ` [PATCH net 0/3] SCTP fixes David Miller
2014-10-15  3:06   ` Neil Horman
2014-10-15  4:21     ` David Miller
2014-10-15 20:20       ` Neil Horman

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=543B0DD7.7000900@redhat.com \
    --to=dborkman@redhat.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=vyasevich@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).