From: Xin Long <lucien.xin@gmail.com> To: Julian Anastasov <ja@ssi.bg> Cc: network dev <netdev@vger.kernel.org>, linux-sctp@vger.kernel.org, davem <davem@davemloft.net>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>, Neil Horman <nhorman@tuxdriver.com>, Vlad Yasevich <vyasevich@gmail.com> Subject: Re: [PATCH net] sctp: remove temporary variable confirm from sctp_packet_transmit Date: Sun, 19 Mar 2017 00:26:50 +0800 [thread overview] Message-ID: <CADvbK_fnC3VHL6QM=Xj+kxW9jRuB8e7ZFbb3CTVApu+mRU+vhA@mail.gmail.com> (raw) In-Reply-To: <alpine.LFD.2.20.1703181323280.7390@ja.home.ssi.bg> On Sat, Mar 18, 2017 at 7:48 PM, Julian Anastasov <ja@ssi.bg> wrote: > > Hello, > > On Sat, 18 Mar 2017, Xin Long wrote: > >> Commit c86a773c7802 ("sctp: add dst_pending_confirm flag") introduced >> a temporary variable "confirm" in sctp_packet_transmit. >> >> But it broke the rule that longer lines should be above shorter ones. >> Besides, this variable is not necessary, so this patch is to just >> remove it and use tp->dst_pending_confirm directly. >> >> Fixes: c86a773c7802 ("sctp: add dst_pending_confirm flag") >> Signed-off-by: Xin Long <lucien.xin@gmail.com> >> --- >> net/sctp/output.c | 7 +++---- >> 1 file changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/net/sctp/output.c b/net/sctp/output.c >> index 71ce6b9..1224421 100644 >> --- a/net/sctp/output.c >> +++ b/net/sctp/output.c >> @@ -546,7 +546,6 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp) >> struct sctp_association *asoc = tp->asoc; >> struct sctp_chunk *chunk, *tmp; >> int pkt_count, gso = 0; >> - int confirm; >> struct dst_entry *dst; >> struct sk_buff *head; >> struct sctphdr *sh; >> @@ -625,13 +624,13 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp) >> asoc->peer.last_sent_to = tp; >> } >> head->ignore_df = packet->ipfragok; >> - confirm = tp->dst_pending_confirm; >> - if (confirm) >> + if (tp->dst_pending_confirm) >> skb_set_dst_pending_confirm(head, 1); >> /* neighbour should be confirmed on successful transmission or >> * positive error >> */ >> - if (tp->af_specific->sctp_xmit(head, tp) >= 0 && confirm) >> + if (tp->af_specific->sctp_xmit(head, tp) >= 0 && >> + tp->dst_pending_confirm) >> tp->dst_pending_confirm = 0; >> >> out: >> -- > > I played safe here, I was not sure if currently > or some day in the future the SCTP stack can allow another > thread to set tp->dst_pending_confirm concurrently with the > sending. My idea was only when skb was used to confirm > neighbour only then to clear the indication. I guess, your > patch is ok because we should be locking the socket > everywhere. Yeps, It's safe, as all the codes for dst_pending_confirm are under the sock lock protection. > > Regards > > -- > Julian Anastasov <ja@ssi.bg>
WARNING: multiple messages have this Message-ID (diff)
From: Xin Long <lucien.xin@gmail.com> To: Julian Anastasov <ja@ssi.bg> Cc: network dev <netdev@vger.kernel.org>, linux-sctp@vger.kernel.org, davem <davem@davemloft.net>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>, Neil Horman <nhorman@tuxdriver.com>, Vlad Yasevich <vyasevich@gmail.com> Subject: Re: [PATCH net] sctp: remove temporary variable confirm from sctp_packet_transmit Date: Sat, 18 Mar 2017 16:26:50 +0000 [thread overview] Message-ID: <CADvbK_fnC3VHL6QM=Xj+kxW9jRuB8e7ZFbb3CTVApu+mRU+vhA@mail.gmail.com> (raw) In-Reply-To: <alpine.LFD.2.20.1703181323280.7390@ja.home.ssi.bg> On Sat, Mar 18, 2017 at 7:48 PM, Julian Anastasov <ja@ssi.bg> wrote: > > Hello, > > On Sat, 18 Mar 2017, Xin Long wrote: > >> Commit c86a773c7802 ("sctp: add dst_pending_confirm flag") introduced >> a temporary variable "confirm" in sctp_packet_transmit. >> >> But it broke the rule that longer lines should be above shorter ones. >> Besides, this variable is not necessary, so this patch is to just >> remove it and use tp->dst_pending_confirm directly. >> >> Fixes: c86a773c7802 ("sctp: add dst_pending_confirm flag") >> Signed-off-by: Xin Long <lucien.xin@gmail.com> >> --- >> net/sctp/output.c | 7 +++---- >> 1 file changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/net/sctp/output.c b/net/sctp/output.c >> index 71ce6b9..1224421 100644 >> --- a/net/sctp/output.c >> +++ b/net/sctp/output.c >> @@ -546,7 +546,6 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp) >> struct sctp_association *asoc = tp->asoc; >> struct sctp_chunk *chunk, *tmp; >> int pkt_count, gso = 0; >> - int confirm; >> struct dst_entry *dst; >> struct sk_buff *head; >> struct sctphdr *sh; >> @@ -625,13 +624,13 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp) >> asoc->peer.last_sent_to = tp; >> } >> head->ignore_df = packet->ipfragok; >> - confirm = tp->dst_pending_confirm; >> - if (confirm) >> + if (tp->dst_pending_confirm) >> skb_set_dst_pending_confirm(head, 1); >> /* neighbour should be confirmed on successful transmission or >> * positive error >> */ >> - if (tp->af_specific->sctp_xmit(head, tp) >= 0 && confirm) >> + if (tp->af_specific->sctp_xmit(head, tp) >= 0 && >> + tp->dst_pending_confirm) >> tp->dst_pending_confirm = 0; >> >> out: >> -- > > I played safe here, I was not sure if currently > or some day in the future the SCTP stack can allow another > thread to set tp->dst_pending_confirm concurrently with the > sending. My idea was only when skb was used to confirm > neighbour only then to clear the indication. I guess, your > patch is ok because we should be locking the socket > everywhere. Yeps, It's safe, as all the codes for dst_pending_confirm are under the sock lock protection. > > Regards > > -- > Julian Anastasov <ja@ssi.bg>
next prev parent reply other threads:[~2017-03-18 16:26 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-18 11:12 [PATCH net] sctp: remove temporary variable confirm from sctp_packet_transmit Xin Long 2017-03-18 11:12 ` Xin Long 2017-03-18 11:48 ` Julian Anastasov 2017-03-18 11:48 ` Julian Anastasov 2017-03-18 16:26 ` Xin Long [this message] 2017-03-18 16:26 ` Xin Long 2017-03-18 19:05 ` Neil Horman 2017-03-18 19:05 ` Neil Horman 2017-03-22 1:31 ` David Miller 2017-03-22 1:31 ` David Miller
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='CADvbK_fnC3VHL6QM=Xj+kxW9jRuB8e7ZFbb3CTVApu+mRU+vhA@mail.gmail.com' \ --to=lucien.xin@gmail.com \ --cc=davem@davemloft.net \ --cc=ja@ssi.bg \ --cc=linux-sctp@vger.kernel.org \ --cc=marcelo.leitner@gmail.com \ --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: linkBe 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.