From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 613721A5B9E for ; Sat, 18 Jul 2026 12:34:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784378086; cv=none; b=DnkZEVX3a+MiwtZyH7T8cfgO18MPxlBh7j1Fv9/vF7Wvjoi09JvSj68PjWPxA4d/bK6ZaNHtPrGD0pPZ2MRlEA0RJEJlSns5hcgojf7P3ZQgfrgBh6PytYoVLswyHHVD4AYfSjp9wAa2Bv91hWv0U6rgkc6rknaPMLKxTZa2/Ew= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784378086; c=relaxed/simple; bh=6jdbYcxq8RmC3tiFymZVTnY1wEARorthv0QnmGX0zmI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=T3dQm3cFHo1KYOavbqMgdpzSubz+qzPeTGa7zN0PibVohv1GCp0Mmvl1MiyMkUXTdIy4ehMAWaom2umujg2/lJ+cIxvGlMx9IKP/IhN74Fp2wtiEljON5voteTYUnnQPkdb4fS3Z92Yzu70ZpEhO/+ch2qRwaLHRUrBXIf849bE= 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=BNRwwZcr; arc=none smtp.client-ip=209.85.128.43 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="BNRwwZcr" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4954dff6536so6162465e9.0 for ; Sat, 18 Jul 2026 05:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784378082; x=1784982882; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=2l4FYWFSpulqsw2d3VOSnee+AYUde051R9WsyPAffPM=; b=BNRwwZcrGhGQOpE7hVojYwTCXKFisr1QxM5L33zAfRgIKDVR3vMXVSlXATQZ1mvV7L UC5F4maSKVgZi9ojikDw2JQe/8O2FVwEFZ9lDIKtm/EqWOx2b5A8nqjoiYQEFyYW/yjG JTmjb3BYHU20rVkOsPndNZPFP0xTSUhf6wn/0x9FdAl0nR/E2RITWCqwFaoM+C8rl1Z7 WO0YzUQrMYCuMrQ5Z+YbyDEBLB7+/A3UFoeRqrqgHYy3JCklsx7hEwXZkWF9IskodndE fqQyrEQeuH3+73c9PIc7YAcsScFkuAEKCNTiqDHDU7fmw3Ua4UEsBjTnVphXyXxPH1Nr 3hVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784378082; x=1784982882; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2l4FYWFSpulqsw2d3VOSnee+AYUde051R9WsyPAffPM=; b=dha+3MQ34LqvERdS0xgYJT0C7cmOk4OjaKSBF+T2N3S1YKZ1LaMtbt7CFJl4/pe/U9 jtlJGPTVjbn+HL8jJC1j54a1KZyNP3nzv2xS6patb5UeAbmGAUMEWTiAmrPVREdAk4ij zwDd6neY9dJ3Qu/Ih929q+fg9WgX5PZxkdmsf7mntJQ0HjUHLjZDJKIFi6vMkjN9yHVn yzlQhpdD8Z22hmcGJosUJ3Y7ObehkfNn8rrhevmbTkzXT1eaC2qPtYhqdrUBzwqsq5St QDqhS+RQbx6N+ei0W+y8jTa7/s0A1dKTHhEZ2o/Jvows816aFzkeP0f0fDkAnEMeFqNI cx+w== X-Forwarded-Encrypted: i=1; AHgh+RqjNoiteBdjEpin0TX4pQmHurFg4mSO5w93mKbNe2n2QE/G5L9e7TXBdGa8b2rgEBvGCLw7koKk2aHWS4g=@vger.kernel.org X-Gm-Message-State: AOJu0Yzr1vz1A9DjDYAGzf6UL3aV2hfwsU4nky0thrl5lsfibbffYEr4 cNGFUNG78ocCM0ZYq64RHvhBQLnxXN+aDhCfFswRAU1JaSXCOrLOZib8 X-Gm-Gg: AfdE7cme1tIMoGi7BSrSUGssTNNqhxmUPSr5p960EIfrC0J/6wKaRqkWnnx5/yid+5B zaue9EwHRD/65nynrAu9LSpGvNeRS6wGHkFfGwlg/Bdn6Bq+MCL18CFHNN2GfoGppTp4d/TAhm/ Zv9xD9FzYLBsTIhafAE4/5rTrWYRHyLuwb/bnUDiONkEdXwUbEUn+T9v47FAJYySWZQhyqTEcGI C5G1YmX9iQv43kYm3fzcKu0DYfk0U9ZMwbqxRwlAPeQp5M5wm/YmUrfZHVMvbBWEftttzb1SPBT YqpWhM9qCg0DOu3JsGrx1ddpN9dezEmVwZ9ousfOo3YoBRLZMz3drDBjX+O0d7UOHlW7z7E3H15 9mWipZtct+digLxf4lfOYdfNr8rGPj/bZ6Dxhgg6w+6WImdQ1NPKg+NwVWPgzUtktFM8Mi0C3OV 71jCCekz4BX2iB X-Received: by 2002:a05:600c:6c91:b0:493:c337:db0e with SMTP id 5b1f17b1804b1-4954a402d87mr49546165e9.18.1784378082332; Sat, 18 Jul 2026 05:34:42 -0700 (PDT) Received: from liavpc.localdomain ([2a06:c701:4900:1700:d578:12e4:b9d6:6e36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49549a35830sm129041165e9.3.2026.07.18.05.34.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jul 2026 05:34:41 -0700 (PDT) From: Liav Albani To: akpm@linux-foundation.org Cc: david@kernel.org, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Liav Albani Subject: [PATCH 0/1] Fix an imbalanced file ref count in the mmap syscall Date: Sat, 18 Jul 2026 15:34:16 +0300 Message-ID: <20260718123417.16339-1-liavalb@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi! This is my first patch that I contribute myself to the Linux kernel. My apologize if there are issues, I tried to solve this issue in one evening and understand the call graph and what could go wrong. I work recently on a project of mine called nfiop, and specifically on a kernel module called ufedm - https://github.com/nfiop/ufedm . The project has a driver that allows a userspace implementation to intervene in the write and read callbacks of an MTD device by spawning an upper MTD device that sends the data back and forth to userspace, so userspace can implement its custom ECC engine and send back the results. So far so good. I started working with kernel 6.18.8 on an Olimex A20 board and then moved to my x86 linux machine with a nandsim simulation. When I started my project, I implemented a memory backing based on a shmem file for the shared memory buffer, that is expected to be mmap'ed from my custom character device. When I updated my host machine, the new kernel version was 7.x so I decided to update my module as well. Many changes were comsetic, but the major change was to implement a mmap_prepare hook. I wrote something simple, taking notes on the mmap_prepare rules and the guide from kernel docs. Then I started to test that my character device is at least working fine, so I have my unit tests for ioctls and mmap, and the mmap unit-test failed after the second-run. A kernel stack looked like this: ``` imbalanced put on file reference count WARNING: fs/file.c:36 at __file_ref_put_badval.isra.0+0x3f/0x60, CPU#1: test_proxy_mmap/116 Modules linked in: ufedm(OE) virtio_net net_failover failover nandsim nand nandcore bch mtd CPU: 1 UID: 0 PID: 116 Comm: test_proxy_mmap Tainted: G OE 7.2.0-rc3-gaf5e34a41cd6 #1 PREEMPT(full) bdadc55b51524b311c430c1536a97e7071150fd3 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:__file_ref_put_badval.isra.0+0x3f/0x60 Code: 85 f6 78 05 c3 cc cc cc cc 48 b8 00 00 00 00 00 00 00 a0 48 89 07 c3 cc cc cc cc 48 83 ec 08 48 89 3c 24 48 8d 3d 61 bc 30 02 <67> 48 0f b9 3a 48 ba 00 00 00 00 00 00 00 e0 48 8b 04 24 48 89 10 RSP: 0018:ffffc900006bbae8 EFLAGS: 00010296 RAX: bfffffffffffffff RBX: ffff88810409a180 RCX: 0000000038748000 RDX: ffff888100a44480 RSI: dfffffffffffffff RDI: ffffffff83b12730 RBP: ffffc900006bbbf8 R08: 0000000000000000 R09: 00007f8b49f8f000 R10: ffffc900006bbba0 R11: ffff88810409a208 R12: ffffc900006bbba0 R13: 00007f8b4a179000 R14: ffff888102222440 R15: 0000000000015040 FS: 0000000038726400(0000) GS:ffff8881b77d1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000038728618 CR3: 0000000104a1c006 CR4: 0000000000370ef0 Call Trace: __file_ref_put+0x30/0x40 fput+0x4f/0x80 remove_vma+0x42/0x60 vms_complete_munmap_vmas+0x179/0x230 do_vmi_align_munmap+0x225/0x2a0 do_vmi_munmap+0xe6/0x1c0 __vm_munmap+0x113/0x200 __x64_sys_munmap+0x1b/0x30 do_syscall_64+0xaa/0x660 ? ksys_mmap_pgoff+0x168/0x200 ? do_syscall_64+0xaa/0x660 ? vfs_write+0x281/0x560 ? ksys_write+0x7b/0x110 ? do_syscall_64+0xaa/0x660 ? do_syscall_64+0x5f/0x660 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x440bcb ``` I started investigating this, and it became apparent that there's an issue with ref-counting of the vm_file - I changed it in my mmap_prepare hook, so it must be the cause, right? I also tried to artificially increment the ref-count of my shmem file when I create it (taking another ref), so the second attempt didn't fail but the third did... I looked at the stack trace, and the culprit is the fact that we do fput on a vm_file that we didn't pin - to fix this, I added a flag if we actually did get_file() on the vm_file or not, on the vma struct. When testing this patch, I've observed that the problem was completely gone. The mmap_prepare hook is still quite new, so presumably fixing corner cases like this one is a good candidate for upstream, for future drivers that might do the same as I do in my driver. Liav Albani (1): mm/vma: fix imbalanced file reference count, properly abort mmap_prepare include/linux/mm_types.h | 1 + mm/vma.c | 24 +++++++++++++----------- 2 files changed, 14 insertions(+), 11 deletions(-) -- 2.55.0