<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/fs, branch dev-5.10.49-intel</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.10.49-intel</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.10.49-intel'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2021-07-14T17:03:00+00:00</updated>
<entry>
<title>Fix for dirty node in jffs2 summary entry</title>
<updated>2021-07-14T17:03:00+00:00</updated>
<author>
<name>Thomas Betker</name>
<email>thomas.betker@rohde-schwarz.com</email>
</author>
<published>2020-03-30T05:30:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e771d36e31db0e6a3a55af3a8813da0dfd2e5872'/>
<id>urn:sha1:e771d36e31db0e6a3a55af3a8813da0dfd2e5872</id>
<content type='text'>
jffs2_flash_direct_writev() always invokes jffs2_sum_add_kvec(), even
if mtd_writev() fails. Usually, this results in an extra summary entry
pointing to dirty node space, which should be ignored -- it is a bit of
a waste, but harmless.

When mtd_writev() returns *retlen == 0, though, the node space is not
reserved as dirty, but re-used; the extra summary entry then points
into the space of the next node. After the erase block has been closed,
we get the following messages on remount:

    jffs2: error: (79) jffs2_link_node_ref:
        Adding new ref c3048d18 at (0x00ec5b88-0x00ec6bcc)
        not immediately after previous (0x00ec5b88-0x00ec5b88)
    ...
    jffs2: Checked all inodes but still 0x2088 bytes of unchecked space?
    jffs2: No space for garbage collection. Aborting GC thread

The extra summary entries amount to "unchecked space", so that
jffs2_garbage_collect_pass() returns -ENOSPC. And without garbage
collection, the filesystem becomes unuseable over time as the erase
blocks fill up.

Fix this by skipping jffs2_sum_add_kvec() when the MTD write fails. We
don't need the summary entry anyway, and the behaviour matches that of
jffs2_flash_writev() in wbuf.c (with write buffering enabled).

Signed-off-by: Thomas Betker &lt;thomas.betker@rohde-schwarz.com&gt;
</content>
</entry>
<entry>
<title>netfs: fix test for whether we can skip read when writing beyond EOF</title>
<updated>2021-06-30T12:47:29+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2021-06-13T23:33:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0463b49e0239bb04f6ca5d7b697645e1122c30f8'/>
<id>urn:sha1:0463b49e0239bb04f6ca5d7b697645e1122c30f8</id>
<content type='text'>
commit 827a746f405d25f79560c7868474aec5aee174e1 upstream.

It's not sufficient to skip reading when the pos is beyond the EOF.
There may be data at the head of the page that we need to fill in
before the write.

Add a new helper function that corrects and clarifies the logic of
when we can skip reads, and have it only zero out the part of the page
that won't have data copied in for the write.

Finally, don't set the page Uptodate after zeroing. It's not up to date
since the write data won't have been copied in yet.

[DH made the following changes:

 - Prefixed the new function with "netfs_".

 - Don't call zero_user_segments() for a full-page write.

 - Altered the beyond-last-page check to avoid a DIV instruction and got
   rid of then-redundant zero-length file check.
]

[ Note: this fix is commit 827a746f405d in mainline kernels. The
	original bug was in ceph, but got lifted into the fs/netfs
	library for v5.13. This backport should apply to stable
	kernels v5.10 though v5.12. ]

Fixes: e1b1240c1ff5f ("netfs: Add write_begin helper")
Reported-by: Andrew W Elble &lt;aweits@rit.edu&gt;
Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
cc: ceph-devel@vger.kernel.org
Link: https://lore.kernel.org/r/20210613233345.113565-1-jlayton@kernel.org/
Link: https://lore.kernel.org/r/162367683365.460125.4467036947364047314.stgit@warthog.procyon.org.uk/ # v1
Link: https://lore.kernel.org/r/162391826758.1173366.11794946719301590013.stgit@warthog.procyon.org.uk/ # v2
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ceph: must hold snap_rwsem when filling inode for async create</title>
<updated>2021-06-30T12:47:25+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2021-06-01T13:40:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=02c303f3b9fbc5ad9c1f50f971304ef86b69f29b'/>
<id>urn:sha1:02c303f3b9fbc5ad9c1f50f971304ef86b69f29b</id>
<content type='text'>
commit 27171ae6a0fdc75571e5bf3d0961631a1e4fb765 upstream.

...and add a lockdep assertion for it to ceph_fill_inode().

Cc: stable@vger.kernel.org # v5.7+
Fixes: 9a8d03ca2e2c3 ("ceph: attempt to do async create when possible")
Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Reviewed-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>nilfs2: fix memory leak in nilfs_sysfs_delete_device_group</title>
<updated>2021-06-30T12:47:24+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2021-06-25T01:39:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ab5bef9780386be0e54f98a40eeedb8295cd450b'/>
<id>urn:sha1:ab5bef9780386be0e54f98a40eeedb8295cd450b</id>
<content type='text'>
[ Upstream commit 8fd0c1b0647a6bda4067ee0cd61e8395954b6f28 ]

My local syzbot instance hit memory leak in nilfs2.  The problem was in
missing kobject_put() in nilfs_sysfs_delete_device_group().

kobject_del() does not call kobject_cleanup() for passed kobject and it
leads to leaking duped kobject name if kobject_put() was not called.

Fail log:

  BUG: memory leak
  unreferenced object 0xffff8880596171e0 (size 8):
  comm "syz-executor379", pid 8381, jiffies 4294980258 (age 21.100s)
  hex dump (first 8 bytes):
    6c 6f 6f 70 30 00 00 00                          loop0...
  backtrace:
     kstrdup+0x36/0x70 mm/util.c:60
     kstrdup_const+0x53/0x80 mm/util.c:83
     kvasprintf_const+0x108/0x190 lib/kasprintf.c:48
     kobject_set_name_vargs+0x56/0x150 lib/kobject.c:289
     kobject_add_varg lib/kobject.c:384 [inline]
     kobject_init_and_add+0xc9/0x160 lib/kobject.c:473
     nilfs_sysfs_create_device_group+0x150/0x800 fs/nilfs2/sysfs.c:999
     init_nilfs+0xe26/0x12b0 fs/nilfs2/the_nilfs.c:637

Link: https://lkml.kernel.org/r/20210612140559.20022-1-paskripkin@gmail.com
Fixes: da7141fb78db ("nilfs2: add /sys/fs/nilfs2/&lt;device&gt; group")
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Acked-by: Ryusuke Konishi &lt;konishi.ryusuke@gmail.com&gt;
Cc: Michael L. Semon &lt;mlsemon35@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fanotify: fix copy_event_to_user() fid error clean up</title>
<updated>2021-06-23T12:42:41+00:00</updated>
<author>
<name>Matthew Bobrowski</name>
<email>repnop@google.com</email>
</author>
<published>2021-06-11T03:32:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ae1d3b989d19e4d8d4fee612a4d24ef992fcd25f'/>
<id>urn:sha1:ae1d3b989d19e4d8d4fee612a4d24ef992fcd25f</id>
<content type='text'>
[ Upstream commit f644bc449b37cc32d3ce7b36a88073873aa21bd5 ]

Ensure that clean up is performed on the allocated file descriptor and
struct file object in the event that an error is encountered while copying
fid info objects. Currently, we return directly to the caller when an error
is experienced in the fid info copying helper, which isn't ideal given that
the listener process could be left with a dangling file descriptor in their
fdtable.

Fixes: 5e469c830fdb ("fanotify: copy event fid info to user")
Fixes: 44d705b0370b ("fanotify: report name info for FAN_DIR_MODIFY event")
Link: https://lore.kernel.org/linux-fsdevel/YMKv1U7tNPK955ho@google.com/T/#m15361cd6399dad4396aad650de25dbf6b312288e
Link: https://lore.kernel.org/r/1ef8ae9100101eb1a91763c516c2e9a3a3b112bd.1623376346.git.repnop@google.com
Signed-off-by: Matthew Bobrowski &lt;repnop@google.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>afs: Fix an IS_ERR() vs NULL check</title>
<updated>2021-06-23T12:42:40+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-06-15T07:39:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=090b1bb928a91c6c402ebb067fb32a14f41f6951'/>
<id>urn:sha1:090b1bb928a91c6c402ebb067fb32a14f41f6951</id>
<content type='text'>
[ Upstream commit a33d62662d275cee22888fa7760fe09d5b9cd1f9 ]

The proc_symlink() function returns NULL on error, it doesn't return
error pointers.

Fixes: 5b86d4ff5dce ("afs: Implement network namespacing")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: linux-afs@lists.infradead.org
Link: https://lore.kernel.org/r/YLjMRKX40pTrJvgf@mwanda/
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gfs2: Fix use-after-free in gfs2_glock_shrink_scan</title>
<updated>2021-06-18T08:00:04+00:00</updated>
<author>
<name>Hillf Danton</name>
<email>hdanton@sina.com</email>
</author>
<published>2021-05-18T08:46:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a61156314b66456ab6a291ed5deba1ebd002ab3c'/>
<id>urn:sha1:a61156314b66456ab6a291ed5deba1ebd002ab3c</id>
<content type='text'>
[ Upstream commit 1ab19c5de4c537ec0d9b21020395a5b5a6c059b2 ]

The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
remove the glock from the lru list in __gfs2_glock_put().

On the shrink scan path, the same flag is cleared under lru_lock but because
of cond_resched_lock(&amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the
put side can be made without deleting the glock from the lru list.

Keep GLF_LRU across the race window opened by cond_resched_lock(&amp;lru_lock) to
ensure correct behavior on both sides - clear GLF_LRU after list_del under
lru_lock.

Reported-by: syzbot &lt;syzbot+34ba7ddbf3021981a228@syzkaller.appspotmail.com&gt;
Signed-off-by: Hillf Danton &lt;hdanton@sina.com&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gfs2: fix a deadlock on withdraw-during-mount</title>
<updated>2021-06-18T08:00:04+00:00</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2021-05-18T13:14:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=7a557de07917600a12bcb9867acad771e4b29837'/>
<id>urn:sha1:7a557de07917600a12bcb9867acad771e4b29837</id>
<content type='text'>
[ Upstream commit 865cc3e9cc0b1d4b81c10d53174bced76decf888 ]

Before this patch, gfs2 would deadlock because of the following
sequence during mount:

mount
   gfs2_fill_super
      gfs2_make_fs_rw &lt;--- Detects IO error with glock
         kthread_stop(sdp-&gt;sd_quotad_process);
            &lt;--- Blocked waiting for quotad to finish

logd
   Detects IO error and the need to withdraw
   calls gfs2_withdraw
      gfs2_make_fs_ro
         kthread_stop(sdp-&gt;sd_quotad_process);
            &lt;--- Blocked waiting for quotad to finish

gfs2_quotad
   gfs2_statfs_sync
      gfs2_glock_wait &lt;---- Blocked waiting for statfs glock to be granted

glock_work_func
   do_xmote &lt;---Detects IO error, can't release glock: blocked on withdraw
      glops-&gt;go_inval
      glock_blocked_by_withdraw
         requeue glock work &amp; exit &lt;--- work requeued, blocked by withdraw

This patch makes a special exception for the statfs system inode glock,
which allows the statfs glock UNLOCK to proceed normally. That allows the
quotad daemon to exit during the withdraw, which allows the logd daemon
to exit during the withdraw, which allows the mount to exit.

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gfs2: Prevent direct-I/O write fallback errors from getting lost</title>
<updated>2021-06-18T08:00:04+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2021-05-10T10:25:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c3e9ea16adc1ce378e7c1416dace0c93631e2fcc'/>
<id>urn:sha1:c3e9ea16adc1ce378e7c1416dace0c93631e2fcc</id>
<content type='text'>
[ Upstream commit 43a511c44e58e357a687d61a20cf5ef1dc9e5a7c ]

When a direct I/O write falls entirely and falls back to buffered I/O and the
buffered I/O fails, the write failed with return value 0 instead of the error
number reported by the buffered I/O. Fix that.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>proc: only require mm_struct for writing</title>
<updated>2021-06-16T10:01:47+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-06-15T16:26:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ef9a0d224bafc0f4f8f85d0eb69fc59a6fbd1318'/>
<id>urn:sha1:ef9a0d224bafc0f4f8f85d0eb69fc59a6fbd1318</id>
<content type='text'>
commit 94f0b2d4a1d0c52035aef425da5e022bd2cb1c71 upstream.

Commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct") we
started using __mem_open() to track the mm_struct at open-time, so that
we could then check it for writes.

But that also ended up making the permission checks at open time much
stricter - and not just for writes, but for reads too.  And that in turn
caused a regression for at least Fedora 29, where NIC interfaces fail to
start when using NetworkManager.

Since only the write side wanted the mm_struct test, ignore any failures
by __mem_open() at open time, leaving reads unaffected.  The write()
time verification of the mm_struct pointer will then catch the failure
case because a NULL pointer will not match a valid 'current-&gt;mm'.

Link: https://lore.kernel.org/netdev/YMjTlp2FSJYvoyFa@unreal/
Fixes: 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct")
Reported-and-tested-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Christian Brauner &lt;christian.brauner@ubuntu.com&gt;
Cc: Andrea Righi &lt;andrea.righi@canonical.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
