<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/configfs, branch linux-6.0.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-12-31T12:26:08+00:00</updated>
<entry>
<title>configfs: fix possible memory leak in configfs_create_dir()</title>
<updated>2022-12-31T12:26:08+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=8bc77754224a2c8581727ffe2e958119b4e27c8f'/>
<id>urn:sha1:8bc77754224a2c8581727ffe2e958119b4e27c8f</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-02-22T17:30:28+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=84ec758fb2daa236026506868c8796b0500c047d'/>
<id>urn:sha1:84ec758fb2daa236026506868c8796b0500c047d</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>fsnotify: fix fsnotify hooks in pseudo filesystems</title>
<updated>2022-01-24T13:17:02+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=29044dae2e746949ad4b9cbdbfb248994d1dcdb4'/>
<id>urn:sha1:29044dae2e746949ad4b9cbdbfb248994d1dcdb4</id>
<content type='text'>
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;
</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>
<entry>
<title>Merge tag 'configfs-5.13' of git://git.infradead.org/users/hch/configfs</title>
<updated>2021-07-02T21:13:21+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-07-02T21:13:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ced4cca754a6322463720768ce50c45c2865ba5b'/>
<id>urn:sha1:ced4cca754a6322463720768ce50c45c2865ba5b</id>
<content type='text'>
Pull configfs updates from Christoph Hellwig:

 - fix a memleak in configfs_release_bin_file (Chung-Chiang Cheng)

 - implement the .read_iter and .write_iter (Bart Van Assche)

 - minor cleanups (Bart Van Assche, me)

* tag 'configfs-5.13' of git://git.infradead.org/users/hch/configfs:
  configfs: simplify configfs_release_bin_file
  configfs: fix memleak in configfs_release_bin_file
  configfs: implement the .read_iter and .write_iter methods
  configfs: drop pointless kerneldoc comments
  configfs: fix the kerneldoc comment for configfs_create_bin_file
</content>
</entry>
</feed>
