From: Bastien Philbert <bastienphilbert@gmail.com>
To: David Miller <davem@davemloft.net>, daniel@iogearbox.net
Cc: vyasevich@gmail.com, nhorman@tuxdriver.com,
linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sctp: Fix error handling for switch statement case in the function sctp_cmd_interprete
Date: Tue, 05 Apr 2016 23:34:05 +0000 [thread overview]
Message-ID: <57044B6D.8050703@gmail.com> (raw)
In-Reply-To: <20160405.192910.1219063056390496976.davem@davemloft.net>
On 2016-04-05 07:29 PM, David Miller wrote:
> From: Daniel Borkmann <daniel@iogearbox.net>
> Date: Tue, 05 Apr 2016 23:53:52 +0200
>
>> On 04/05/2016 11:36 PM, Bastien Philbert wrote:
>>> This fixes error handling for the switch statement case
>>> SCTP_CMD_SEND_PKT by making the error value of the call
>>> to sctp_packet_transmit equal the variable error due to
>>> this function being able to fail with a error code. In
>>
>> What actual issue have you observed that you fix?
>>
>>> addition allow the call to sctp_ootb_pkt_free afterwards
>>> to free up the no longer in use sctp packet even if the
>>> call to the function sctp_packet_transmit fails in order
>>> to avoid a memory leak here for not freeing the sctp
>>
>> Not sure how this relates to your code?
>
> Bastien, I'm seeing a clear negative pattern with the bug fixes
> you are submitting.
>
> Just now you submitted the ICMP change which obviously was never
> tested because it tried to take the RTNL mutex in atomic context,
> and now this sctp thing.
>
> If you don't start actually testing your changes and expalining
> clearly what the problem actually is, how you discovered it,
> and how you actually tested your patch, I will start completely
> ignoring your patch submissions.
>
Ok sure I will be more careful with my future patches. Sorry about those
two patches :(.
Bastien
WARNING: multiple messages have this Message-ID (diff)
From: Bastien Philbert <bastienphilbert@gmail.com>
To: David Miller <davem@davemloft.net>, daniel@iogearbox.net
Cc: vyasevich@gmail.com, nhorman@tuxdriver.com,
linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sctp: Fix error handling for switch statement case in the function sctp_cmd_interprete
Date: Tue, 5 Apr 2016 19:34:05 -0400 [thread overview]
Message-ID: <57044B6D.8050703@gmail.com> (raw)
In-Reply-To: <20160405.192910.1219063056390496976.davem@davemloft.net>
On 2016-04-05 07:29 PM, David Miller wrote:
> From: Daniel Borkmann <daniel@iogearbox.net>
> Date: Tue, 05 Apr 2016 23:53:52 +0200
>
>> On 04/05/2016 11:36 PM, Bastien Philbert wrote:
>>> This fixes error handling for the switch statement case
>>> SCTP_CMD_SEND_PKT by making the error value of the call
>>> to sctp_packet_transmit equal the variable error due to
>>> this function being able to fail with a error code. In
>>
>> What actual issue have you observed that you fix?
>>
>>> addition allow the call to sctp_ootb_pkt_free afterwards
>>> to free up the no longer in use sctp packet even if the
>>> call to the function sctp_packet_transmit fails in order
>>> to avoid a memory leak here for not freeing the sctp
>>
>> Not sure how this relates to your code?
>
> Bastien, I'm seeing a clear negative pattern with the bug fixes
> you are submitting.
>
> Just now you submitted the ICMP change which obviously was never
> tested because it tried to take the RTNL mutex in atomic context,
> and now this sctp thing.
>
> If you don't start actually testing your changes and expalining
> clearly what the problem actually is, how you discovered it,
> and how you actually tested your patch, I will start completely
> ignoring your patch submissions.
>
Ok sure I will be more careful with my future patches. Sorry about those
two patches :(.
Bastien
next prev parent reply other threads:[~2016-04-05 23:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 21:36 [PATCH] sctp: Fix error handling for switch statement case in the function sctp_cmd_interprete Bastien Philbert
2016-04-05 21:36 ` Bastien Philbert
2016-04-05 21:53 ` Daniel Borkmann
2016-04-05 21:53 ` Daniel Borkmann
2016-04-05 21:58 ` Bastien Philbert
2016-04-05 21:58 ` Bastien Philbert
2016-04-05 23:29 ` David Miller
2016-04-05 23:29 ` David Miller
2016-04-05 23:34 ` Bastien Philbert [this message]
2016-04-05 23:34 ` Bastien Philbert
2016-04-05 22:12 ` Marcelo Ricardo Leitner
2016-04-05 22:12 ` Marcelo Ricardo Leitner
2016-04-05 23:03 ` Bastien Philbert
2016-04-05 23:03 ` Bastien Philbert
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=57044B6D.8050703@gmail.com \
--to=bastienphilbert@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--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 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.