From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>
Cc: patchwork-bot+netdevbpf@kernel.org,
Santosh Shilimkar <santosh.shilimkar@oracle.com>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
syzbot <syzbot+694120e1002c117747ed@syzkaller.appspotmail.com>,
netdev <netdev@vger.kernel.org>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
linux-rdma <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH v2] net: rds: acquire refcount on TCP sockets
Date: Thu, 5 May 2022 00:15:46 +0900 [thread overview]
Message-ID: <5f3feecc-65ad-af5f-0ecd-94b2605ab67e@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <bf5ce176-35e6-0a75-1ada-6bed071a6a75@I-love.SAKURA.ne.jp>
On 2022/05/04 13:58, Tetsuo Handa wrote:
> On 2022/05/04 12:09, Eric Dumazet wrote:
>> This exit() handler _has_ to remove all known listeners, and
>> definitely cancel work queues (synchronous operation)
>> before the actual "struct net" free can happen later.
>
> But in your report, rds_tcp_tune() is called from rds_tcp_conn_path_connect() from
> rds_connect_worker() via "struct rds_connection"->cp_conn_w work. I can see that
> rds_tcp_kill_sock() calls rds_tcp_listen_stop(lsock, &rtn->rds_tcp_accept_w), and
> rds_tcp_listen_stop() calls flush_workqueue(rds_wq) and flush_work(&rtn->rds_tcp_accept_w).
>
> But I can't see how rds_tcp_exit_net() synchronously cancels all works associated
> with "struct rds_conn_path".
>
> struct rds_conn_path {
> struct delayed_work cp_send_w;
> struct delayed_work cp_recv_w;
> struct delayed_work cp_conn_w;
> struct work_struct cp_down_w;
> }
>
> These works are queued to rds_wq, but flush_workqueue() waits for completion only
> if already queued. What if timer for queue_delayed_work() has not expired, or was
> about to call queue_delayed_work() ? Is flush_workqueue(rds_wq) sufficient?
rds_tcp_tune+0x5a0/0x5f0 net/rds/tcp.c:503
rds_tcp_conn_path_connect+0x489/0x880 net/rds/tcp_connect.c:127
rds_connect_worker+0x1a5/0x2c0 net/rds/threads.c:176
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
rds_tcp_conn_path_connect is referenced by
"struct rds_transport rds_tcp_transport"->conn_path_connect.
It is invoked by
ret = conn->c_trans->conn_path_connect(cp)
in rds_connect_worker().
rds_connect_worker is referenced by "struct rds_conn_path"->cp_conn_w
via INIT_DELAYED_WORK().
queue_delayed_work(rds_wq, &cp->cp_conn_w, *) is called by
rds_queue_reconnect() or rds_conn_path_connect_if_down().
If rds_conn_path_connect_if_down() were called from
rds_tcp_accept_one_path() from rds_tcp_accept_one(),
rds_tcp_tune() from rds_tcp_accept_one() was already called
before rds_tcp_tune() from rds_tcp_conn_path_connect() is called.
Since the addition on 0 was not reported at rds_tcp_tune() from
rds_tcp_accept_one(), what Eric is reporting cannot be from
rds_tcp_accept_one() from rds_tcp_accept_worker().
Despite rds_tcp_kill_sock() sets rtn->rds_tcp_listen_sock = NULL and
waits for rds_tcp_accept_one() from rds_tcp_accept_worker() to complete
using flush_workqueue(rds_wq), what Eric is reporting is different from
what syzbot+694120e1002c117747ed was reporting.
>
> Anyway, if rds_tcp_kill_sock() can somehow guarantee that all works are completed
> or cancelled, the fix would look like something below?
I think it is OK to apply below diff in order to avoid addition on 0 problem, but
it is not proven that kmem_cache_free() is not yet called. What should we do?
>
> net/rds/tcp.c | 11 ++++++++---
> net/rds/tcp.h | 2 +-
> net/rds/tcp_connect.c | 5 ++++-
> net/rds/tcp_listen.c | 5 ++++-
> 4 files changed, 17 insertions(+), 6 deletions(-)
>
next prev parent reply other threads:[~2022-05-04 15:16 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 7:40 KASAN: use-after-free Read in tcp_retransmit_timer (5) syzbot
2021-12-22 11:00 ` [syzbot] " syzbot
2022-04-09 8:19 ` Tetsuo Handa
2022-04-09 16:46 ` Eric Dumazet
2022-04-09 17:47 ` Eric Dumazet
2022-04-09 17:55 ` Eric Dumazet
2022-04-10 0:38 ` Tetsuo Handa
2022-04-10 5:39 ` Tetsuo Handa
2022-04-10 11:36 ` Tetsuo Handa
2022-04-22 14:40 ` Tetsuo Handa
2022-04-24 3:57 ` Tetsuo Handa
2022-05-01 15:29 ` [PATCH] net: rds: acquire refcount on TCP sockets Tetsuo Handa
2022-05-01 16:14 ` Eric Dumazet
2022-05-02 1:40 ` [PATCH v2] " Tetsuo Handa
2022-05-02 14:12 ` Haakon Bugge
2022-05-02 14:29 ` Tetsuo Handa
2022-05-03 9:02 ` Paolo Abeni
2022-05-03 9:56 ` Tetsuo Handa
2022-05-03 11:10 ` Paolo Abeni
2022-05-03 13:27 ` David Laight
2022-05-03 13:43 ` Eric Dumazet
2022-05-03 14:25 ` David Laight
2022-05-03 13:45 ` Eric Dumazet
2022-05-03 14:08 ` Tetsuo Handa
2022-05-03 11:40 ` patchwork-bot+netdevbpf
2022-05-03 21:17 ` Eric Dumazet
2022-05-03 22:37 ` Eric Dumazet
2022-05-04 1:04 ` Tetsuo Handa
2022-05-04 3:09 ` Eric Dumazet
2022-05-04 4:58 ` Tetsuo Handa
2022-05-04 15:15 ` Tetsuo Handa [this message]
2022-05-05 0:45 ` [PATCH] net: rds: use maybe_get_net() when acquiring " Tetsuo Handa
2022-05-05 0:53 ` Eric Dumazet
2022-05-05 1:04 ` Jakub Kicinski
2022-05-05 1:53 ` [PATCH net v2] " Tetsuo Handa
2022-05-05 19:13 ` Eric Dumazet
2022-05-06 1:20 ` patchwork-bot+netdevbpf
2022-05-04 13:09 ` [PATCH v2] net: rds: acquire " Paolo Abeni
2022-05-04 13:25 ` Eric Dumazet
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=5f3feecc-65ad-af5f-0ecd-94b2605ab67e@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=patchwork-bot+netdevbpf@kernel.org \
--cc=santosh.shilimkar@oracle.com \
--cc=syzbot+694120e1002c117747ed@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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).