<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/configfs, branch v5.15.208</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-06-27T10:05:22+00:00</updated>
<entry>
<title>configfs: Do not override creating attribute file failure in populate_attrs()</title>
<updated>2025-06-27T10:05:22+00:00</updated>
<author>
<name>Zijun Hu</name>
<email>quic_zijuhu@quicinc.com</email>
</author>
<published>2025-05-07T11:50:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8cb51a55b26eadc671748adbac12ebb2375ec9c1'/>
<id>urn:sha1:8cb51a55b26eadc671748adbac12ebb2375ec9c1</id>
<content type='text'>
commit f830edbae247b89228c3e09294151b21e0dc849c upstream.

populate_attrs() may override failure for creating attribute files
by success for creating subsequent bin attribute files, and have
wrong return value.

Fix by creating bin attribute files under successfully creating
attribute files.

Fixes: 03607ace807b ("configfs: implement binary attributes")
Cc: stable@vger.kernel.org
Reviewed-by: Joel Becker &lt;jlbec@evilplan.org&gt;
Reviewed-by: Breno Leitao &lt;leitao@debian.org&gt;
Signed-off-by: Zijun Hu &lt;quic_zijuhu@quicinc.com&gt;
Link: https://lore.kernel.org/r/20250507-fix_configfs-v3-2-fe2d96de8dc4@quicinc.com
Signed-off-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>configfs: fix possible memory leak in configfs_create_dir()</title>
<updated>2022-12-31T12:14:15+00:00</updated>
<author>
<name>Chen Zhongjin</name>
<email>chenzhongjin@huawei.com</email>
</author>
<published>2022-10-17T01:42:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07f82dca112262b169bec0001378126439cab776'/>
<id>urn:sha1:07f82dca112262b169bec0001378126439cab776</id>
<content type='text'>
[ Upstream commit c65234b283a65cfbfc94619655e820a5e55199eb ]

kmemleak reported memory leaks in configfs_create_dir():

unreferenced object 0xffff888009f6af00 (size 192):
  comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
  backtrace:
    kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
    new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)
    configfs_register_subsystem (fs/configfs/dir.c:1857)
    basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
    do_one_initcall (init/main.c:1296)
    do_init_module (kernel/module/main.c:2455)
    ...

unreferenced object 0xffff888003ba7180 (size 96):
  comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
  backtrace:
    kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
    configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)
    configfs_make_dirent (fs/configfs/dir.c:248)
    configfs_create_dir (fs/configfs/dir.c:296)
    configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)
    configfs_register_subsystem (fs/configfs/dir.c:1881)
    basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
    do_one_initcall (init/main.c:1296)
    do_init_module (kernel/module/main.c:2455)
    ...

This is because the refcount is not correct in configfs_make_dirent().
For normal stage, the refcount is changing as:

configfs_register_subsystem()
  configfs_create_dir()
    configfs_make_dirent()
      configfs_new_dirent() # set s_count = 1
      dentry-&gt;d_fsdata = configfs_get(sd); # s_count = 2
...
configfs_unregister_subsystem()
  configfs_remove_dir()
    remove_dir()
      configfs_remove_dirent() # s_count = 1
    dput() ...
      *dentry_unlink_inode()*
        configfs_d_iput() # s_count = 0, release

However, if we failed in configfs_create():

configfs_register_subsystem()
  configfs_create_dir()
    configfs_make_dirent() # s_count = 2
    ...
    configfs_create() # fail
    -&gt;out_remove:
    configfs_remove_dirent(dentry)
      configfs_put(sd) # s_count = 1
      return PTR_ERR(inode);

There is no inode in the error path, so the configfs_d_iput() is lost
and makes sd and fragment memory leaked.

To fix this, when we failed in configfs_create(), manually call
configfs_put(sd) to keep the refcount correct.

Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem")
Signed-off-by: Chen Zhongjin &lt;chenzhongjin@huawei.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>configfs: fix a race in configfs_{,un}register_subsystem()</title>
<updated>2022-03-02T10:48:02+00:00</updated>
<author>
<name>ChenXiaoSong</name>
<email>chenxiaosong2@huawei.com</email>
</author>
<published>2022-02-15T07:10:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7a66dd2687758718eddd79b542a95cf3aa488cc'/>
<id>urn:sha1:e7a66dd2687758718eddd79b542a95cf3aa488cc</id>
<content type='text'>
[ Upstream commit 84ec758fb2daa236026506868c8796b0500c047d ]

When configfs_register_subsystem() or configfs_unregister_subsystem()
is executing link_group() or unlink_group(),
it is possible that two processes add or delete list concurrently.
Some unfortunate interleavings of them can cause kernel panic.

One of cases is:
A --&gt; B --&gt; C --&gt; D
A &lt;-- B &lt;-- C &lt;-- D

     delete list_head *B        |      delete list_head *C
--------------------------------|-----------------------------------
configfs_unregister_subsystem   |   configfs_unregister_subsystem
  unlink_group                  |     unlink_group
    unlink_obj                  |       unlink_obj
      list_del_init             |         list_del_init
        __list_del_entry        |           __list_del_entry
          __list_del            |             __list_del
            // next == C        |
            next-&gt;prev = prev   |
                                |               next-&gt;prev = prev
            prev-&gt;next = next   |
                                |                 // prev == B
                                |                 prev-&gt;next = next

Fix this by adding mutex when calling link_group() or unlink_group(),
but parent configfs_subsystem is NULL when config_item is root.
So I create a mutex configfs_subsystem_mutex.

Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem")
Signed-off-by: ChenXiaoSong &lt;chenxiaosong2@huawei.com&gt;
Signed-off-by: Laibin Qiu &lt;qiulaibin@huawei.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsnotify: fix fsnotify hooks in pseudo filesystems</title>
<updated>2022-02-01T16:27:01+00:00</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2022-01-20T21:53:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e6023ab8c729b9edb99c6bc5f0169f474deeabe5'/>
<id>urn:sha1:e6023ab8c729b9edb99c6bc5f0169f474deeabe5</id>
<content type='text'>
commit 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 upstream.

Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of
d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify
will have access to a positive dentry.

This allowed a race where opening the deleted file via cached dentry
is now possible after receiving the IN_DELETE event.

To fix the regression in pseudo filesystems, convert d_delete() calls
to d_drop() (see commit 46c46f8df9aa ("devpts_pty_kill(): don't bother
with d_delete()") and move the fsnotify hook after d_drop().

Add a missing fsnotify_unlink() hook in nfsdfs that was found during
the audit of fsnotify hooks in pseudo filesystems.

Note that the fsnotify hooks in simple_recursive_removal() follow
d_invalidate(), so they require no change.

Link: https://lore.kernel.org/r/20220120215305.282577-2-amir73il@gmail.com
Reported-by: Ivan Delalande &lt;colona@arista.com&gt;
Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/
Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()")
Cc: stable@vger.kernel.org # v5.3+
Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>configfs: fix a race in configfs_lookup()</title>
<updated>2021-08-25T05:58:49+00:00</updated>
<author>
<name>Sishuai Gong</name>
<email>sishuai@purdue.edu</email>
</author>
<published>2021-08-25T05:52:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c42dd069be8dfc9b2239a5c89e73bbd08ab35de0'/>
<id>urn:sha1:c42dd069be8dfc9b2239a5c89e73bbd08ab35de0</id>
<content type='text'>
When configfs_lookup() is executing list_for_each_entry(),
it is possible that configfs_dir_lseek() is calling list_del().
Some unfortunate interleavings of them can cause a kernel NULL
pointer dereference error

Thread 1                  Thread 2
//configfs_dir_lseek()    //configfs_lookup()
list_del(&amp;cursor-&gt;s_sibling);
                         list_for_each_entry(sd, ...)

Fix this by grabbing configfs_dirent_lock in configfs_lookup()
while iterating -&gt;s_children.

Signed-off-by: Sishuai Gong &lt;sishuai@purdue.edu&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>configfs: fold configfs_attach_attr into configfs_lookup</title>
<updated>2021-08-25T05:58:46+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2021-08-25T05:50:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d07f132a225c013e59aa77f514ad9211ecab82ee'/>
<id>urn:sha1:d07f132a225c013e59aa77f514ad9211ecab82ee</id>
<content type='text'>
This makes it more clear what gets added to the dcache and prepares
for an additional locking fix.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>configfs: simplify the configfs_dirent_is_ready</title>
<updated>2021-08-25T05:43:55+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2021-08-25T05:43:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=899587c8d0908e5124fd074d52bf05b4b0633a79'/>
<id>urn:sha1:899587c8d0908e5124fd074d52bf05b4b0633a79</id>
<content type='text'>
Return the error directly instead of using a goto.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>configfs: return -ENAMETOOLONG earlier in configfs_lookup</title>
<updated>2021-08-25T05:42:44+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2021-08-25T05:42:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=417b962ddeca2b70eb72d28c87541bdad4e234f8'/>
<id>urn:sha1:417b962ddeca2b70eb72d28c87541bdad4e234f8</id>
<content type='text'>
Just like most other file systems: get the simple checks out of the
way first.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>configfs: restore the kernel v5.13 text attribute write behavior</title>
<updated>2021-08-09T14:56:00+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2021-08-05T04:35:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=769f52676756b8c5feb302d2d95af59577fc69ec'/>
<id>urn:sha1:769f52676756b8c5feb302d2d95af59577fc69ec</id>
<content type='text'>
Instead of appending new text attribute data at the offset specified by the
write() system call, only pass the newly written data to the .store()
callback.

Reported-by: Bodo Stroesser &lt;bostroesser@gmail.com&gt;
Tested-by: Bodo Stroesser &lt;bostroesser@gmail.com&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>configfs: fix the read and write iterators</title>
<updated>2021-07-13T18:56:24+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2021-07-13T17:49:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=420405ecde061fde76d67bd3a67577a563ea758e'/>
<id>urn:sha1:420405ecde061fde76d67bd3a67577a563ea758e</id>
<content type='text'>
Commit 7fe1e79b59ba ("configfs: implement the .read_iter and .write_iter
methods") changed the simple_read_from_buffer() calls into copy_to_iter()
calls and the simple_write_to_buffer() calls into copy_from_iter() calls.
The simple*buffer() methods update the file offset (*ppos) but the read
and write iterators not yet. Make the read and write iterators update the
file offset (iocb-&gt;ki_pos).

This patch has been tested as follows:

 # modprobe target_core_user
 # dd if=/sys/kernel/config/target/dbroot bs=1
/var/target
12+0 records in
12+0 records out
12 bytes copied, 9.5539e-05 s, 126 kB/s

 # cd /sys/kernel/config/acpi/table
 # mkdir test
 # cd test
 # dmesg -c &gt;/dev/null; printf 'SSDT\x8\0\0\0abcdefghijklmnopqrstuvwxyz' | dd of=aml bs=1; dmesg -c
34+0 records in
34+0 records out
34 bytes copied, 0.010627 s, 3.2 kB/s
[  261.056551] ACPI configfs: invalid table length

Reported-by: Yanko Kaneti &lt;yaneti@declera.com&gt;
Cc: Yanko Kaneti &lt;yaneti@declera.com&gt;
Fixes: 7fe1e79b59ba ("configfs: implement the .read_iter and .write_iter methods")
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
</feed>
