From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48BD023BD05 for ; Thu, 26 Feb 2026 21:21:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772140882; cv=none; b=W221NtF+LykfVl8/hPt0z/VhkdKy8NsNxzQarSEOAKZgBF3i7+hEjFTRz6LYBUKcefZLuUI7FBbjOrnTl319CQazeMieEq5vPSSbNxZhcja7m/+ARMUc59EbnRbjy9cmQCPQ2d8snIz6LuZ0bSPlTi/hgxpANNRU9W7UZHrkTKA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772140882; c=relaxed/simple; bh=0F2Qi1Dafw1ixSq01pk97OGkJVfkNNHs5Z3+md6MgC8=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To:Cc: Content-Type; b=Prno0Pa84zKHk+8yCZsUh4KESnN+yP4vBo+6n+9Ey9vJdgHTRUOc2uUrsPBbTSAgJ9GegSXfWZXleTH84DiNpmMjP67o3qWtXOKjg9ESsN/4ADWd3cCKVJSTMT8ngiUtHa0LJciV6aGnBeB4087OPnOhmlZ4Ga9ybP1YBAOYc7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-679a47a1febso27444481eaf.3 for ; Thu, 26 Feb 2026 13:21:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772140880; x=1772745680; h=cc:to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0Qc9TUN45zXHwdTdXnZtwtEDwZ15aysHRoZ6mjXTkxQ=; b=fXC/QkfIuEA5m+KTpRIwkd2k3DUOVF+7Aw42tjFCsc+S4pyEqATtpuheIIjWWZVUK1 YazuRP7ErZOvLyR1thALyCr9m1wVhZzJu+lxQ/09m3vPr1rSJvB11gAU6AmzAoYQQD4l ui8ytAXiwToAD+mSpbnNbS2kdZZi1Wi80U4S/5IHrdJ/hZe37plZOak46NRTKeUbTwb0 0rEOExFrRcEjLINs8OvWdFlT4YAvxH4Sw/Y9N8uJ96TRBJIUWoOuNAd3oYOFRV+w0/lR qLfGllmXgc5SpTUART4cK7qM1YRMjJBRhA57WXMbAYcLjMFnJvmTmbWC4ya0OOcs/Uvi 3SZg== X-Forwarded-Encrypted: i=1; AJvYcCUpjBiFGpuPt256eNfUYqP9pfWHHF+S2y+iZ7JWNFTNFNhmcmhAtJVLjYmcnj5wtvDFCBnZSVMAOP3WsRw=@vger.kernel.org X-Gm-Message-State: AOJu0YzduOGYrBJennu2ATrjMMmTwrfzD5sDm2k/VldDrMotW/iAVLln DJ+DK7AfPt+rBfMNY44DzFePZBPWUs7uPJsyh9zNeiQr8jMLkDRUiI3FlUGEAYp99T7AQsVlpsR LwT/5V0A956/go+7brmpgYEiBiG+H4oXJqZnl7CLpM1rxg2MBC2YDegRZxRU= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a4a:ee17:0:b0:65f:64e2:d625 with SMTP id 006d021491bc7-679faf0cbabmr464113eaf.37.1772140880155; Thu, 26 Feb 2026 13:21:20 -0800 (PST) Date: Thu, 26 Feb 2026 13:21:20 -0800 In-Reply-To: <39a7023a281e36568f2b2468755d4a65f5cae0e4.camel@oracle.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69a0b950.050a0220.3a55be.000d.GAE@google.com> Subject: Re: [syzbot] [rds?] possible deadlock in rds_tcp_tune (2) From: syzbot To: allison.henderson@oracle.com Cc: allison.henderson@oracle.com, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" > #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git main This crash does not have a reproducer. I cannot test it. > > commit 4cd6716706210de3ed52d549ee784a12cc8ffe3a (HEAD) > Author: Allison Henderson > Date: Thu Feb 26 12:45:39 2026 -0700 > > net/rds: Fix circular locking dependency in rds_tcp_tune > > syzbot reported a circular locking dependency in rds_tcp_tune() where > sk_net_refcnt_upgrade() is called while holding the socket lock: > > ====================================================== > WARNING: possible circular locking dependency detected > ------------------------------------------------------ > kworker/u10:8/15040 is trying to acquire lock: > ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x4b/0x6f0 > > but task is already holding lock: > ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: rds_tcp_tune+0xd7/0x930 > > The issue occurs because sk_net_refcnt_upgrade() performs memory allocation > (via get_net_track() -> ref_tracker_alloc()) while the socket lock is held, > creating a circular dependency with fs_reclaim. > > Fix this by moving sk_net_refcnt_upgrade() outside the socket lock critical > section. Since the fresh socket is not yet exposed to other threads, no > locks are needed at this time. > > Reported-by: syzbot+2e2cf5331207053b8106@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=2e2cf5331207053b8106 > Fixes: 5c70eb5c593d ("net: better track kernel sockets lifetime") > Signed-off-by: Allison Henderson > > diff --git a/net/rds/tcp.c b/net/rds/tcp.c > index 04f310255692..da22b3dfdbf0 100644 > --- a/net/rds/tcp.c > +++ b/net/rds/tcp.c > @@ -490,18 +490,24 @@ bool rds_tcp_tune(struct socket *sock) > commit 4cd6716706210de3ed52d549ee784a12cc8ffe3a (HEAD) > Author: Allison Henderson > Date: Thu Feb 26 12:45:39 2026 -0700 > > net/rds: Fix circular locking dependency in rds_tcp_tune > > syzbot reported a circular locking dependency in rds_tcp_tune() where > sk_net_refcnt_upgrade() is called while holding the socket lock: > > ====================================================== > WARNING: possible circular locking dependency detected > ------------------------------------------------------ > kworker/u10:8/15040 is trying to acquire lock: > ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x4b/0x6f0 > > but task is already holding lock: > ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: rds_tcp_tune+0xd7/0x930 > > The issue occurs because sk_net_refcnt_upgrade() performs memory allocation > (via get_net_track() -> ref_tracker_alloc()) while the socket lock is held, > creating a circular dependency with fs_reclaim. > > Fix this by moving sk_net_refcnt_upgrade() outside the socket lock critical > section. Since the fresh socket is not yet exposed to other threads, no > locks are needed at this time. > > Reported-by: syzbot+2e2cf5331207053b8106@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=2e2cf5331207053b8106 > Fixes: 5c70eb5c593d ("net: better track kernel sockets lifetime") > Signed-off-by: Allison Henderson > > diff --git a/net/rds/tcp.c b/net/rds/tcp.c > index 04f310255692..da22b3dfdbf0 100644 > --- a/net/rds/tcp.c > +++ b/net/rds/tcp.c > @@ -490,18 +490,24 @@ bool rds_tcp_tune(struct socket *sock) > struct rds_tcp_net *rtn; > > tcp_sock_set_nodelay(sock->sk); > - lock_sock(sk); > /* TCP timer functions might access net namespace even after > * a process which created this net namespace terminated. > */ > if (!sk->sk_net_refcnt) { > - if (!maybe_get_net(net)) { > - release_sock(sk); > + if (!maybe_get_net(net)) > return false; > - } > + /* > + * We call sk_net_refcnt_upgrade before the lock_sock since it is > + * not yet shared, no lock is needed at this time. Further, > + * because sk_net_refcnt_upgrade does a GFP_KERNEL allocation, > + * this can trigger an fs_reclaim in other systems which creates > + * a circular lock dependancy. Avoid this by upgrading the > + * refcnt before the locking the socket. > + */ > sk_net_refcnt_upgrade(sk); > put_net(net); > } > + lock_sock(sk); > rtn = net_generic(net, rds_tcp_netid); > if (rtn->sndbuf_size > 0) { > sk->sk_sndbuf = rtn->sndbuf_size; > @@ -490,18 +490,24 @@ bool rds_tcp_tune(struct socket *sock) > struct rds_tcp_net *rtn; > > tcp_sock_set_nodelay(sock->sk); > - lock_sock(sk); > /* TCP timer functions might access net namespace even after > * a process which created this net namespace terminated. > */ > if (!sk->sk_net_refcnt) { > - if (!maybe_get_net(net)) { > - release_sock(sk); > + if (!maybe_get_net(net)) > return false; > - } > + /* > + * We call sk_net_refcnt_upgrade before the lock_sock since it is > + * not yet shared, no lock is needed at this time. Further, > + * because sk_net_refcnt_upgrade does a GFP_KERNEL allocation, > + * this can trigger an fs_reclaim in other systems which creates > + * a circular lock dependancy. Avoid this by upgrading the > + * refcnt before the locking the socket. > + */ > sk_net_refcnt_upgrade(sk); > put_net(net); > } > + lock_sock(sk); > rtn = net_generic(net, rds_tcp_netid); > if (rtn->sndbuf_size > 0) { > sk->sk_sndbuf = rtn->sndbuf_size; >