<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v6.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-04-22T16:18:35Z</updated>
<entry>
<title>Merge tag '6.3-rc7-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6</title>
<updated>2023-04-22T16:18:35Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-04-22T16:18:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=84ebdb8e0d9ca261d73677f345814505af172ae0'/>
<id>urn:sha1:84ebdb8e0d9ca261d73677f345814505af172ae0</id>
<content type='text'>
Pull cifs fixes from Steve French:
 "Three small smb3 client fixes:

   - two important fixes for unbuffered read regression with the
     iov_iter changes (e.g. read soon after mount in some multichannel
     scenarios)

   - DFS prefix path fix (also for stable)"

* tag '6.3-rc7-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: Reapply lost fix from commit 30b2b2196d6e
  cifs: Fix unbuffered read
  cifs: avoid dup prefix path in dfs_get_automount_devname()
</content>
</entry>
<entry>
<title>Merge tag 'for-6.3-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux</title>
<updated>2023-04-21T17:47:21Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-04-21T17:47:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c337b23f32c87320dffd389e4f0f793db35f0a9b'/>
<id>urn:sha1:c337b23f32c87320dffd389e4f0f793db35f0a9b</id>
<content type='text'>
Pull btrfs fixes from David Sterba:
 "Two patches fixing the problem with aync discard.

  The default settings had a low IOPS limit and processing a large batch
  to discard would take a long time. On laptops this can cause increased
  power consumption due to disk activity.

  As async discard has been on by default since 6.2 this likely affects
  a lot of users.

  Summary:

   - increase the default IOPS limit 10x which reportedly helped

   - setting the sysfs IOPS value to 0 now does not throttle anymore
     allowing the discards to be processed at full speed. Previously
     there was an arbitrary 6 hour target for processing the pending
     batch"

* tag 'for-6.3-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: reinterpret async discard iops_limit=0 as no delay
  btrfs: set default discard iops_limit to 1000
</content>
</entry>
<entry>
<title>btrfs: reinterpret async discard iops_limit=0 as no delay</title>
<updated>2023-04-20T22:28:23Z</updated>
<author>
<name>Boris Burkov</name>
<email>boris@bur.io</email>
</author>
<published>2023-04-05T19:43:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ef9cddfe57d86aac6b509b550136395669159b30'/>
<id>urn:sha1:ef9cddfe57d86aac6b509b550136395669159b30</id>
<content type='text'>
Currently, a limit of 0 results in a hard coded metering over 6 hours.
Since the default is a set limit, I suspect no one truly depends on this
rather arbitrary setting. Repurpose it for an arguably more useful
"unlimited" mode, where the delay is 0.

Note that if block groups are too new, or go fully empty, there is still
a delay associated with those conditions. Those delays implement
heuristics for not trimming a region we are relatively likely to fully
overwrite soon.

CC: stable@vger.kernel.org # 6.2+
Reviewed-by: Neal Gompa &lt;neal@gompa.dev&gt;
Signed-off-by: Boris Burkov &lt;boris@bur.io&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
</content>
</entry>
<entry>
<title>btrfs: set default discard iops_limit to 1000</title>
<updated>2023-04-20T22:28:20Z</updated>
<author>
<name>Boris Burkov</name>
<email>boris@bur.io</email>
</author>
<published>2023-04-05T19:43:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e9f59429b87d35cf23ae9ca19629bd686a1c0304'/>
<id>urn:sha1:e9f59429b87d35cf23ae9ca19629bd686a1c0304</id>
<content type='text'>
Previously, the default was a relatively conservative 10. This results
in a 100ms delay, so with ~300 discards in a commit, it takes the full
30s till the next commit to finish the discards. On a workstation, this
results in the disk never going idle, wasting power/battery, etc.

Set the default to 1000, which results in using the smallest possible
delay, currently, which is 1ms. This has shown to not pathologically
keep the disk busy by the original reporter.

Link: https://lore.kernel.org/linux-btrfs/Y%2F+n1wS%2F4XAH7X1p@nz/
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2182228
CC: stable@vger.kernel.org # 6.2+
Reviewed-by: Neal Gompa &lt;neal@gompa.dev
Signed-off-by: Boris Burkov &lt;boris@bur.io&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'mm-hotfixes-stable-2023-04-19-16-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm</title>
<updated>2023-04-20T00:55:45Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-04-20T00:55:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cb0856346a60fe3eb837ba5e73588a41f81ac05f'/>
<id>urn:sha1:cb0856346a60fe3eb837ba5e73588a41f81ac05f</id>
<content type='text'>
Pull misc fixes from Andrew Morton:
 "22 hotfixes.

  19 are cc:stable and the remainder address issues which were
  introduced during this merge cycle, or aren't considered suitable for
  -stable backporting.

  19 are for MM and the remainder are for other subsystems"

* tag 'mm-hotfixes-stable-2023-04-19-16-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (22 commits)
  nilfs2: initialize unused bytes in segment summary blocks
  mm: page_alloc: skip regions with hugetlbfs pages when allocating 1G pages
  mm/mmap: regression fix for unmapped_area{_topdown}
  maple_tree: fix mas_empty_area() search
  maple_tree: make maple state reusable after mas_empty_area_rev()
  mm: kmsan: handle alloc failures in kmsan_ioremap_page_range()
  mm: kmsan: handle alloc failures in kmsan_vmap_pages_range_noflush()
  tools/Makefile: do missed s/vm/mm/
  mm: fix memory leak on mm_init error handling
  mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock
  kernel/sys.c: fix and improve control flow in __sys_setres[ug]id()
  Revert "userfaultfd: don't fail on unrecognized features"
  writeback, cgroup: fix null-ptr-deref write in bdi_split_work_to_wbs
  maple_tree: fix a potential memory leak, OOB access, or other unpredictable bug
  tools/mm/page_owner_sort.c: fix TGID output when cull=tg is used
  mailmap: update jtoppins' entry to reference correct email
  mm/mempolicy: fix use-after-free of VMA iterator
  mm/huge_memory.c: warn with pr_warn_ratelimited instead of VM_WARN_ON_ONCE_FOLIO
  mm/mprotect: fix do_mprotect_pkey() return on error
  mm/khugepaged: check again on anon uffd-wp during isolation
  ...
</content>
</entry>
<entry>
<title>cifs: Reapply lost fix from commit 30b2b2196d6e</title>
<updated>2023-04-19T02:26:09Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2023-04-18T22:49:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=023fc150a39ffe656da3e459ad801eb1c7fdfad9'/>
<id>urn:sha1:023fc150a39ffe656da3e459ad801eb1c7fdfad9</id>
<content type='text'>
Reapply the fix from:

   30b2b2196d6e ("cifs: do not include page data when checking signature")

that got lost in the iteratorisation of the cifs driver.

Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list")
Acked-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Reported-by: Paulo Alcantara &lt;pc@manguebit.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Paulo Alcantara &lt;pc@cjr.nz&gt;
cc: Shyam Prasad N &lt;nspmangalore@gmail.com&gt;
cc: Bharath S M &lt;bharathsm@microsoft.com&gt;
cc: Enzo Matsumiya &lt;ematsumiya@suse.de&gt;
cc: linux-cifs@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: Fix unbuffered read</title>
<updated>2023-04-19T02:22:08Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2023-04-18T22:40:07Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ac13692844f2fb23c503066c0cb231243218a7c8'/>
<id>urn:sha1:ac13692844f2fb23c503066c0cb231243218a7c8</id>
<content type='text'>
If read() is done in an unbuffered manner, such that, say,
cifs_strict_readv() goes through cifs_user_readv() and thence
__cifs_readv(), it doesn't recognise the EOF and keeps indicating to
userspace that it returning full buffers of data.

This is due to ctx-&gt;iter being advanced in cifs_send_async_read() as the
buffer is split up amongst a number of rdata objects.  The iterator count
is then used in collect_uncached_read_data() in the non-DIO case to set the
total length read - and thus the return value of sys_read().  But since the
iterator normally gets used up completely during splitting, ctx-&gt;total_len
gets overridden to the full amount.

However, prior to that in collect_uncached_read_data(), we've gone through
the list of rdatas and added up the amount of data we actually received
(which we then throw away).

Fix this by removing the bit that overrides the amount read in the non-DIO
case and just going with the total added up in the aforementioned loop.

This was observed by mounting a cifs share with multiple channels, e.g.:

	mount //192.168.6.1/test /test/ -o user=shares,pass=...,max_channels=6

and then reading a 1MiB file on the share:

	strace cat /xfstest.test/1M  &gt;/dev/null

Through strace, the same data can be seen being read again and again.

Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list")
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
cc: Jérôme Glisse &lt;jglisse@redhat.com&gt;
cc: Long Li &lt;longli@microsoft.com&gt;
cc: Enzo Matsumiya &lt;ematsumiya@suse.de&gt;
cc: Shyam Prasad N &lt;nspmangalore@gmail.com&gt;
cc: Rohith Surabattula &lt;rohiths.msft@gmail.com&gt;
cc: Jeff Layton &lt;jlayton@kernel.org&gt;
cc: linux-cifs@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>nilfs2: initialize unused bytes in segment summary blocks</title>
<updated>2023-04-18T21:22:14Z</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@gmail.com</email>
</author>
<published>2023-04-17T17:35:13Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ef832747a82dfbc22a3702219cc716f449b24e4a'/>
<id>urn:sha1:ef832747a82dfbc22a3702219cc716f449b24e4a</id>
<content type='text'>
Syzbot still reports uninit-value in nilfs_add_checksums_on_logs() for
KMSAN enabled kernels after applying commit 7397031622e0 ("nilfs2:
initialize "struct nilfs_binfo_dat"-&gt;bi_pad field").

This is because the unused bytes at the end of each block in segment
summaries are not initialized.  So this fixes the issue by padding the
unused bytes with null bytes.

Link: https://lkml.kernel.org/r/20230417173513.12598-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@gmail.com&gt;
Tested-by: Ryusuke Konishi &lt;konishi.ryusuke@gmail.com&gt;
Reported-by: syzbot+048585f3f4227bb2b49b@syzkaller.appspotmail.com
  Link: https://syzkaller.appspot.com/bug?extid=048585f3f4227bb2b49b
Cc: Alexander Potapenko &lt;glider@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>cifs: avoid dup prefix path in dfs_get_automount_devname()</title>
<updated>2023-04-16T23:04:36Z</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.com</email>
</author>
<published>2023-04-16T18:38:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d5a863a153e90996ab2aef6b9e08d509f4d5662b'/>
<id>urn:sha1:d5a863a153e90996ab2aef6b9e08d509f4d5662b</id>
<content type='text'>
@server-&gt;origin_fullpath already contains the tree name + optional
prefix, so avoid calling __build_path_from_dentry_optional_prefix() as
it might end up duplicating prefix path from @cifs_sb-&gt;prepath into
final full path.

Instead, generate DFS full path by simply merging
@server-&gt;origin_fullpath with dentry's path.

This fixes the following case

	mount.cifs //root/dfs/dir /mnt/ -o ...
	ls /mnt/link

where cifs_dfs_do_automount() will call smb3_parse_devname() with
@devname set to "//root/dfs/dir/link" instead of
"//root/dfs/dir/dir/link".

Fixes: 7ad54b98fc1f ("cifs: use origin fullpath for automounts")
Cc: &lt;stable@vger.kernel.org&gt; # 6.2+
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>Revert "userfaultfd: don't fail on unrecognized features"</title>
<updated>2023-04-16T17:41:26Z</updated>
<author>
<name>Peter Xu</name>
<email>peterx@redhat.com</email>
</author>
<published>2023-04-12T16:38:52Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2ff559f31a5d50c31a3f9d849f8af90dc36c7105'/>
<id>urn:sha1:2ff559f31a5d50c31a3f9d849f8af90dc36c7105</id>
<content type='text'>
This is a proposal to revert commit 914eedcb9ba0ff53c33808.

I found this when writing a simple UFFDIO_API test to be the first unit
test in this set.  Two things breaks with the commit:

  - UFFDIO_API check was lost and missing.  According to man page, the
  kernel should reject ioctl(UFFDIO_API) if uffdio_api.api != 0xaa.  This
  check is needed if the api version will be extended in the future, or
  user app won't be able to identify which is a new kernel.

  - Feature flags checks were removed, which means UFFDIO_API with a
  feature that does not exist will also succeed.  According to the man
  page, we should (and it makes sense) to reject ioctl(UFFDIO_API) if
  unknown features passed in.

Link: https://lore.kernel.org/r/20220722201513.1624158-1-axelrasmussen@google.com
Link: https://lkml.kernel.org/r/20230412163922.327282-2-peterx@redhat.com
Fixes: 914eedcb9ba0 ("userfaultfd: don't fail on unrecognized features")
Signed-off-by: Peter Xu &lt;peterx@redhat.com&gt;
Acked-by: David Hildenbrand &lt;david@redhat.com&gt;
Cc: Axel Rasmussen &lt;axelrasmussen@google.com&gt;
Cc: Dmitry Safonov &lt;0x7f454c46@gmail.com&gt;
Cc: Mike Kravetz &lt;mike.kravetz@oracle.com&gt;
Cc: Mike Rapoport (IBM) &lt;rppt@kernel.org&gt;
Cc: Zach O'Keefe &lt;zokeefe@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
</feed>
