Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1328203ybb; Fri, 20 Mar 2020 18:24:37 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvXAx/xU0fBDEV3M9QPuu3sDxKbit/JpIfUjjafRzEACH1/SA9CLfcL+DEsId9oEPDzKeDd X-Received: by 2002:a9d:70d8:: with SMTP id w24mr8881973otj.137.1584753876937; Fri, 20 Mar 2020 18:24:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584753876; cv=none; d=google.com; s=arc-20160816; b=HqpRZy+tPOjqSJ4/nmrRIIurBB+GfVU9WLH2eLT6IDFDQtY6AFozXYR6sdhvAiTzhF 25ev5/bo8wAaiKgN6oNbwFbpmvUESJYAcVwyFW6mLn8q7zZBt9fqOrjU53HtmpDLAFsp NqvSFXoRO6fNASML2w1o917SYtwH+7VsYfLFm5VfK5TfJ18iohcmLNW/QwVdEyPceOPf liV3gfx8/abPBPiKBFXxdMcYIs4u+n3dNKC4vCRUg4mXYwdEmrs6Qv0g6emPn+pBnP71 GhOOizDnd2NglpXnoH95f2kMMNUtMmve3Ym9/6/UKOtn+/q4hxDXRpa02TC67JW0FiOb SyPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=tsTgHKC2wYoTFHmjkv7F8EKYqReM1aRB2f2l4RqbkyI=; b=rpkFmzTp/NvUAq8v1YguW+mnlAlBBIm1bYJM+pPDIeG07CytQVThymI/Bi+6wbXyQo /Ihf47pGIVhkmwRlK2EYHWiVvPOufPQOOxWSuggzLfBFG6oyN5WoTNcFuw208rjYyv/3 mcEFaP45Vui9BOQGqJrgfsDUbrx7lehaaZORvcIBpgBsJeyuxf9srBxcmcE2IfZqrgiw hzJXLI7uvovLwO5ATvNRVLqImsO/O/dU+RJ1jYpeSkCX07v01FQRChidMqn40FZ5I5qP jrJ9DoWPS9VHK5wLOSvIx2NQs5HZZ5SqTtdPsLuQb4MT0++L7ZxzwIpKroYn54onIP9x MqJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QFJxoFrT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p3si4437078otk.212.2020.03.20.18.24.24; Fri, 20 Mar 2020 18:24:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QFJxoFrT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727241AbgCUBYI (ORCPT + 99 others); Fri, 20 Mar 2020 21:24:08 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:36048 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726773AbgCUBYH (ORCPT ); Fri, 20 Mar 2020 21:24:07 -0400 Received: by mail-io1-f66.google.com with SMTP id d15so8166534iog.3; Fri, 20 Mar 2020 18:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tsTgHKC2wYoTFHmjkv7F8EKYqReM1aRB2f2l4RqbkyI=; b=QFJxoFrTkHzwa4kMCy+p1Gjqrf8Tf/lujHcwNY5QvyokfkbkDjIhAOmf8x9gBlj2sE MDVcQ4lIN+nBB8JKY/QP++Qj+KCU+WHzIcCwjL2L0jKBqsuyNflP9n25Nq4F6Lj9ojEv MesF75DYWmonpTQ2kw/lYLq6rPxdLgPDC4tOL2Y4ba+ldzFmudobZwImz/LVRzG7QK76 IUUa0AYImWYcsgfETe9kFdDHzhl0zIObMJvQK2TLguxdlb7i2I+z9KvDGNvmoTYxWtxC ugR4Ifhkh31lI96hV8dEfBpkZ9BXur2ndlT/GT8PQk7mmyG2wJXmDmgH0cx6Gf2mmvCZ DOQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tsTgHKC2wYoTFHmjkv7F8EKYqReM1aRB2f2l4RqbkyI=; b=XWsnTKRPek39muXmsLydbM3i10Z7CPtnwe7JKyiuz063G+VroE57Zezo5hG7DcA8fx UkZ/0lnC6Alcn81GPDSX73pSBSQ1hR9P+SUvDc4tzEOMqfYYpBZW6ffh7clUkvoVCaMG t3sQRaamirpcFQD97iujohDpqwpd4hsrhYpyFXC526BwpVdhwmCJpRA+kTH1ibw2dtiH KAwG6o7REVDlvSrNd4QX9DqtNw2hXkrXm1tkaS4+GVfucd1AV2EHPya4DBJfFM7WVbz1 yB9cacZh/7J7SBPB4VdrSlLlpZKrSmNWBfteZQ23gOnrzlkx4piRnd/ZcRH1Jh4ENxT4 XmAA== X-Gm-Message-State: ANhLgQ2k5W/eUrp3si30gQm87diNUqmWeuXXLcQPaeOjvS9GfjJoE7bK 9zQ+hWwsVKzIt4r1zOvOO04FuEWHI07sOUdXp34= X-Received: by 2002:a02:cd8a:: with SMTP id l10mr9722945jap.106.1584753846777; Fri, 20 Mar 2020 18:24:06 -0700 (PDT) MIME-Version: 1.0 References: <20200320110959.2114-1-hqjagain@gmail.com> <20200320185204.GB3828@localhost.localdomain> <20200321010246.GC3828@localhost.localdomain> In-Reply-To: <20200321010246.GC3828@localhost.localdomain> From: Qiujun Huang Date: Sat, 21 Mar 2020 09:23:54 +0800 Message-ID: Subject: Re: [PATCH v3] sctp: fix refcount bug in sctp_wfree To: Marcelo Ricardo Leitner Cc: "David S. Miller" , vyasevich@gmail.com, nhorman@tuxdriver.com, Jakub Kicinski , linux-sctp@vger.kernel.org, netdev , LKML , anenbupt@gmail.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 21, 2020 at 9:02 AM Marcelo Ricardo Leitner wrote: > > On Sat, Mar 21, 2020 at 07:53:29AM +0800, Qiujun Huang wrote: > ... > > > > So, sctp_wfree was not called to destroy SKB) > > > > > > > > then migrate happened > > > > > > > > sctp_for_each_tx_datachunk( > > > > sctp_clear_owner_w); > > > > sctp_assoc_migrate(); > > > > sctp_for_each_tx_datachunk( > > > > sctp_set_owner_w); > > > > SKB was not in the outq, and was not changed to newsk > > > > > > The real fix is to fix the migration to the new socket, though the > > > situation on which it is happening is still not clear. > > > > > > The 2nd sendto() call on the reproducer is sending 212992 bytes on a > > > single call. That's usually the whole sndbuf size, and will cause > > > fragmentation to happen. That means the datamsg will contain several > > > skbs. But still, the sacked chunks should be freed if needed while the > > > remaining ones will be left on the queues that they are. > > > > in sctp_sendmsg_to_asoc > > datamsg holds his chunk result in that the sacked chunks can't be freed > > Right! Now I see it, thanks. > In the end, it's not a locking race condition. It's just not iterating > on the lists properly. > > > > > list_for_each_entry(chunk, &datamsg->chunks, frag_list) { > > sctp_chunk_hold(chunk); > > sctp_set_owner_w(chunk); > > chunk->transport = transport; > > } > > > > any ideas to handle it? > > sctp_for_each_tx_datachunk() needs to be aware of this situation. > Instead of iterating directly/only over the chunk list, it should > iterate over the datamsgs instead. Something like the below (just > compile tested). > > Then, the old socket will be free to die regardless of the new one. > Otherwise, if this association gets stuck on retransmissions or so, > the old socket would not be freed till then. > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c > index fed26a1e9518..85c742310d26 100644 > --- a/net/sctp/socket.c > +++ b/net/sctp/socket.c > @@ -151,9 +151,10 @@ static void sctp_for_each_tx_datachunk(struct sctp_association *asoc, > void (*cb)(struct sctp_chunk *)) > > { > + struct sctp_datamsg *msg, *prev_msg = NULL; > struct sctp_outq *q = &asoc->outqueue; > struct sctp_transport *t; > - struct sctp_chunk *chunk; > + struct sctp_chunk *chunk, *c; > > list_for_each_entry(t, &asoc->peer.transport_addr_list, transports) > list_for_each_entry(chunk, &t->transmitted, transmitted_list) > @@ -162,8 +163,14 @@ static void sctp_for_each_tx_datachunk(struct sctp_association *asoc, > list_for_each_entry(chunk, &q->retransmit, transmitted_list) > cb(chunk); > > - list_for_each_entry(chunk, &q->sacked, transmitted_list) > - cb(chunk); > + list_for_each_entry(chunk, &q->sacked, transmitted_list) { > + msg = chunk->msg; > + if (msg == prev_msg) > + continue; > + list_for_each_entry(c, &msg->chunks, frag_list) > + cb(c); > + prev_msg = msg; > + } great. I'll trigger a syzbot test. Thanks. > > list_for_each_entry(chunk, &q->abandoned, transmitted_list) > cb(chunk);