From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 19DD5393DC2 for ; Tue, 18 Nov 2025 17:06:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763485566; cv=none; b=NzzoSdAN0p7+Vl4wlF6GbuTI83SAi/VuQcwgooY02tHciUf0O4GkhBHmw3xAYhv63VlY58yjUxniG2may53e5/A60rqxTKnW9bx6sLqaBAP2oXRJ8om6JJoHTDDz9hkLTl6Nkx7Set7rMjohhv9dm9TziY75uDOB/+zcubf1Dmw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763485566; c=relaxed/simple; bh=c8iyZOUFGOMLU5rvPBd1mGZsPw8GXHa0miKrdp2Vaiw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Yq83J+v5yOYsEihnWJaPoaY1z0vhOlULmD894RXgXqBI3phRapHvcL2S9mNmatQzH5vpDSInTkQ9IGfHdoFo3iNJgt8BbXTFlR56ttHuthWUykTokZe48FgTCe1QtfEXJdbjkMqx0BQk9vC1B6O90EZVc5LzptpHLPe0tsO4Oh4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jVpuhu6m; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jVpuhu6m" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4779d8286d8so3252155e9.0 for ; Tue, 18 Nov 2025 09:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763485563; x=1764090363; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=h4LKFLLmkHOO2YyB1FuGp5QuRpPLnDUvWV5UXKIiXfk=; b=jVpuhu6mHg+qDh5QLi/6d5Ipv9fp8gLAjgZTOwowRsPftT0MK64rujI/TxYG9ulxnA s0UBzR+WnhH6Uqjj1FTg9TerTRDyyFrBuZI4HTPQi0Cgxb+83x/5KuC6KkubDESPBsAH 7OJ8xkISiNitkPbKj28XW7irZsEsMhL7iptCKJDi/os+yOTZ41IieDhhIPT8B7j00AIS F/nYlacCqvufCDOZMJAEXG5N93JvZNQcz4oYqe901tV68cLFsAmXivAEgdw2LCJjXhf0 tW3L91HsL+7jCTKtLHWx7QHqJuyLcRbQF3HJyBnEqWbxMRQgeh4qUbvc0PvgFMZGKnUB 78/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763485563; x=1764090363; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=h4LKFLLmkHOO2YyB1FuGp5QuRpPLnDUvWV5UXKIiXfk=; b=EeSSk9Lzx6X7wKtvFc1TrKeCZUoW0jB4pTJmTERIKAc33CrykfSMGIe6Ec5VIn2pVC 5yXEQ4r6SarC+9hM+aK8phJMikEZb6KmUbhDEwlAyuSaI/1is347vZdxAe8sAAqzdZdB iCARsZAyUlo6hy9I83kuFQVXeEBKrhvpzh+ZGkl8lXgVWXH+P+zdu0vfypfzJhJdlYbr OH5fyjg6Hw06dFu1fKjBwxG8rNjYpWZfodIX0pJ85+n/Esg5Z3bZOQLDW2N6fFFqOLBg MvTfOaPAL0Merqvi8x5N8Hkm0Q0l5aUiZ90NsyduJ32BfZ6BxSgNVgZr7+blxdDLLW47 c1cA== X-Forwarded-Encrypted: i=1; AJvYcCVqnZOTpwobvWmfOTX/A3zM9qUoPCUOyqdtwmfHSi1K2/6Al/4JYoElN3K54UzrfB/kSlxrab+pg01XJIk=@vger.kernel.org X-Gm-Message-State: AOJu0YyYbdgcRYFUkXaAHV7EvlmPqOTjs2Xd0PTDzaDTt+9d7nHuWVww 8/OEJtJcHgdd2h/eaZh8hCh4Xb0nfxV4uy8Ph1pZIyanzWIviTxpdBPk X-Gm-Gg: ASbGncvnfEY//pPIM8eY+zuKyckopIRvYgdm2gpDvuBBmoCK/Pn7nwGuEh861uxuuTf WB9tBbS+pXwaUS/ASttMDCMZDo7yc8ZCdcXbrdWGrJ3kXgsSC3+3CdhnnjLhKccjaWOO+45pVaE 48kDF+CCgvBMAbbGLzF1H4Fkpe+ZxOISO3WGUtKIr/v5dLRMdOUiwXq1Gu1o5R3EfGbzu9LdyOk 51EOfgskrtcNtuG8NW9A98KiPBfVkkFkAYjCc3fUnYkNCmJQ+HUxVRm4K8cWuB8RNyP3Igk+DFa xlPQdL2alZ1QAp6Jk1eP7Z15FtzuEpyX1dQtIUx9kuylWTKmq3G9rsJ5zW4YkvScf3vSy+n8t33 eqL6XIiKcokbcQNMYwQ9AOhmhAFkBcbbmGwJvJAQ/k3F0yfnKXU9fd3MnTC/0M8XBtK5KwNaKdx 8BQ4+/AgZHjoGVjivqwX24u9aXdoD8D/zE1U+gfXec X-Google-Smtp-Source: AGHT+IEry1hEqU9c+Efos00n6PiUk5jPDLkd+/hqr8m0S/JkYYA1s82T4mTqsPxXSNj4jy8GNkox2A== X-Received: by 2002:a05:600c:1d26:b0:477:9fd6:7a53 with SMTP id 5b1f17b1804b1-477a9bf23f8mr19857245e9.2.1763485563223; Tue, 18 Nov 2025 09:06:03 -0800 (PST) Received: from [192.168.1.105] ([165.50.73.153]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-477a9dea7fcsm21111345e9.8.2025.11.18.09.06.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Nov 2025 09:06:02 -0800 (PST) Message-ID: <86897b3b-23b7-400a-b8d6-4169e78bf5d9@gmail.com> Date: Tue, 18 Nov 2025 19:05:44 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] fs/super: fix memory leak of s_fs_info on setup_bdev_super failure To: Al Viro Cc: brauner@kernel.org, jack@suse.cz, syzbot+ad45f827c88778ff7df6@syzkaller.appspotmail.com, frank.li@vivo.com, glaubitz@physik.fu-berlin.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, slava@dubeyko.com, syzkaller-bugs@googlegroups.com, skhan@linuxfoundation.org, david.hunter.linux@gmail.com, khalid@kernel.org, linux-kernel-mentees@lists.linuxfoundation.org References: <20251114165255.101361-1-mehdi.benhadjkhelifa@gmail.com> <20251118145957.GD2441659@ZenIV> <6c482108-78b8-4e09-814a-67820a5c021e@gmail.com> <20251118163509.GE2441659@ZenIV> <20251118165553.GF2441659@ZenIV> Content-Language: en-US From: Mehdi Ben Hadj Khelifa In-Reply-To: <20251118165553.GF2441659@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/18/25 5:55 PM, Al Viro wrote: > On Tue, Nov 18, 2025 at 04:35:09PM +0000, Al Viro wrote: > >> For HFS I would expect that hfs_fill_super() would call hfs_mdb_put(sb) >> on all failures and have it called from subsequent ->put_super() if >> we succeed and later unmount the filesystem. That seems to be where >> ->s_fs_info is taken out of superblock and freed. >> >> What do you observe getting leaked and in which case does that happen? Sorry for my other late reply. My thunderbird client had some issues and got delayed and seperated emails somehow... > > AFAICS, the problem is with aca740cecbe5 "fs: open block device after superblock > creation" where you get a failure exit stuck between getting a new superblock > from sget_fc() and calling fill_super(). > Yes this is what I mentionned in my earlier mail.(not the commit causing the issue though). > That is where the gap has been introduced. I see two possible solutions: > one is to have failure of setup_bdev_super() (and only it) steal ->s_fs_info > back, on the theory that filesystem didn't have a chance to do anything > yet. Another is to move the call of hfs_mdb_put() from failure exits of > hfs_fill_super() *and* from hfs_put_super() into hfs_kill_sb(), that > would do that: > > generic_shutdown_super(sb); > hfs_mdb_put(sb); > if (sb->s_bdev) { > sync_blockdev(sb->s_bdev); > bdev_fput(sb->s_bdev_file); > } I will do the second approach, test it send it for review shortly. Best regards, Mehdi Ben Hadj Khelifa