<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/fs, branch dev-5.10-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-intel</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.10-intel'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2021-10-01T18:40:21+00:00</updated>
<entry>
<title>Merge branch 'dev-5.10' into dev-5.10-intel</title>
<updated>2021-10-01T18:40:21+00:00</updated>
<author>
<name>Jae Hyun Yoo</name>
<email>jae.hyun.yoo@linux.intel.com</email>
</author>
<published>2021-10-01T18:38:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9c881021a269af242594e2dfc79f1c4701404887'/>
<id>urn:sha1:9c881021a269af242594e2dfc79f1c4701404887</id>
<content type='text'>
Pull 5.10.67 stable from OpenBMC upstream.

Signed-off-by: Jae Hyun Yoo &lt;jae.hyun.yoo@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>fanotify: limit number of event merge attempts</title>
<updated>2021-09-18T11:40:38+00:00</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2021-03-04T10:48:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ad3ea16746cc68307165d52e22a3f75015ccd16e'/>
<id>urn:sha1:ad3ea16746cc68307165d52e22a3f75015ccd16e</id>
<content type='text'>
commit b8cd0ee8cda68a888a317991c1e918a8cba1a568 upstream.

Event merges are expensive when event queue size is large, so limit the
linear search to 128 merge tests.

[Stable backport notes] The following statement from upstream commit is
irrelevant for backport:
-
-In combination with 128 size hash table, there is a potential to merge
-with up to 16K events in the hashed queue.
-
[Stable backport notes] The problem is as old as fanotify and described
in the linked cover letter "Performance improvement for fanotify merge".
This backported patch fixes the performance issue at the cost of merging
fewer potential events.  Fixing the performance issue is more important
than preserving the "event merge" behavior, which was not predictable in
any way that applications could rely on.

Link: https://lore.kernel.org/r/20210304104826.3993892-6-amir73il@gmail.com
Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/linux-fsdevel/20210202162010.305971-1-amir73il@gmail.com/
Link: https://lore.kernel.org/linux-fsdevel/20210915163334.GD6166@quack2.suse.cz/
Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ovl: fix BUG_ON() in may_delete() when called from ovl_cleanup()</title>
<updated>2021-09-18T11:40:35+00:00</updated>
<author>
<name>chenying</name>
<email>chenying.kernel@bytedance.com</email>
</author>
<published>2021-08-16T10:02:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=69775e4e17f2380f67c972899b02828d7a71d627'/>
<id>urn:sha1:69775e4e17f2380f67c972899b02828d7a71d627</id>
<content type='text'>
commit 52d5a0c6bd8a89f460243ed937856354f8f253a3 upstream.

If function ovl_instantiate() returns an error, ovl_cleanup will be called
and try to remove newdentry from wdir, but the newdentry has been moved to
udir at this time.  This will causes BUG_ON(victim-&gt;d_parent-&gt;d_inode !=
dir) in fs/namei.c:may_delete.

Signed-off-by: chenying &lt;chenying.kernel@bytedance.com&gt;
Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly created inode")
Link: https://lore.kernel.org/linux-unionfs/e6496a94-a161-dc04-c38a-d2544633acb4@bytedance.com/
Cc: &lt;stable@vger.kernel.org&gt; # v4.18
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>io_uring: remove duplicated io_size from rw</title>
<updated>2021-09-18T11:40:35+00:00</updated>
<author>
<name>Pavel Begunkov</name>
<email>asml.silence@gmail.com</email>
</author>
<published>2020-11-07T13:16:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9a4e7f9038660b7fd41280f9d97e6c722804bd1d'/>
<id>urn:sha1:9a4e7f9038660b7fd41280f9d97e6c722804bd1d</id>
<content type='text'>
[ Upstream commit 632546c4b5a4dad8e3ac456406c65c0db9a0b570 ]

io_size and iov_count in io_read() and io_write() hold the same value,
kill the last one.

Signed-off-by: Pavel Begunkov &lt;asml.silence@gmail.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs/io_uring Don't use the return value from import_iovec().</title>
<updated>2021-09-18T11:40:35+00:00</updated>
<author>
<name>David Laight</name>
<email>David.Laight@ACULAB.COM</email>
</author>
<published>2020-11-07T13:16:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6930a2a5be5cbb0c202fcfa2773c95bd10a19197'/>
<id>urn:sha1:6930a2a5be5cbb0c202fcfa2773c95bd10a19197</id>
<content type='text'>
[ Upstream commit 10fc72e43352753a08f9cf83aa5c40baec00d212 ]

This is the only code that relies on import_iovec() returning
iter.count on success.
This allows a better interface to import_iovec().

Signed-off-by: David Laight &lt;david.laight@aculab.com&gt;
Signed-off-by: Pavel Begunkov &lt;asml.silence@gmail.com&gt;
Reviewed-by: Pavel Begunkov &lt;asml.silence@gmail.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nfsd: fix crash on LOCKT on reexported NFSv3</title>
<updated>2021-09-18T11:40:33+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2021-08-25T02:36:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=eb04c51a439e38dbbab363cf5f0599cbe0507b13'/>
<id>urn:sha1:eb04c51a439e38dbbab363cf5f0599cbe0507b13</id>
<content type='text'>
[ Upstream commit 0bcc7ca40bd823193224e9f38bafbd8325aaf566 ]

Unlike other filesystems, NFSv3 tries to use fl_file in the GETLK case.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cifs: fix wrong release in sess_alloc_buffer() failed path</title>
<updated>2021-09-18T11:40:32+00:00</updated>
<author>
<name>Ding Hui</name>
<email>dinghui@sangfor.com.cn</email>
</author>
<published>2021-08-17T14:55:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ba2faddf1f14c2a7ecb0adecaebcc332c919cf05'/>
<id>urn:sha1:ba2faddf1f14c2a7ecb0adecaebcc332c919cf05</id>
<content type='text'>
[ Upstream commit d72c74197b70bc3c95152f351a568007bffa3e11 ]

smb_buf is allocated by small_smb_init_no_tc(), and buf type is
CIFS_SMALL_BUFFER, so we should use cifs_small_buf_release() to
release it in failed path.

Signed-off-by: Ding Hui &lt;dinghui@sangfor.com.cn&gt;
Reviewed-by: Paulo Alcantara (SUSE) &lt;pc@cjr.nz&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>btrfs: tree-log: check btrfs_lookup_data_extent return value</title>
<updated>2021-09-18T11:40:31+00:00</updated>
<author>
<name>Marcos Paulo de Souza</name>
<email>mpdesouza@suse.com</email>
</author>
<published>2021-08-02T12:34:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b225eeaf3a02f2d47a4a5ee8cc976fc822eddac7'/>
<id>urn:sha1:b225eeaf3a02f2d47a4a5ee8cc976fc822eddac7</id>
<content type='text'>
[ Upstream commit 3736127a3aa805602b7a2ad60ec9cfce68065fbb ]

Function btrfs_lookup_data_extent calls btrfs_search_slot to verify if
the EXTENT_ITEM exists in the extent tree. btrfs_search_slot can return
values bellow zero if an error happened.

Function replay_one_extent currently checks if the search found
something (0 returned) and increments the reference, and if not, it
seems to evaluate as 'not found'.

Fix the condition by checking if the value was bellow zero and return
early.

Reviewed-by: Filipe Manana &lt;fdmanana@suse.com&gt;
Signed-off-by: Marcos Paulo de Souza &lt;mpdesouza@suse.com&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>lockd: lockd server-side shouldn't set fl_ops</title>
<updated>2021-09-18T11:40:30+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2021-08-20T21:01:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9ce6e29375bab3c081bc61162d82e47e8d7a439a'/>
<id>urn:sha1:9ce6e29375bab3c081bc61162d82e47e8d7a439a</id>
<content type='text'>
[ Upstream commit 7de875b231edb807387a81cde288aa9e1015ef9e ]

Locks have two sets of op arrays, fl_lmops for the lock manager (lockd
or nfsd), fl_ops for the filesystem.  The server-side lockd code has
been setting its own fl_ops, which leads to confusion (and crashes) in
the reexport case, where the filesystem expects to be the only one
setting fl_ops.

And there's no reason for it that I can see-the lm_get/put_owner ops do
the same job.

Reported-by: Daire Byrne &lt;daire@dneg.com&gt;
Tested-by: Daire Byrne &lt;daire@dneg.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gfs2: Don't call dlm after protocol is unmounted</title>
<updated>2021-09-18T11:40:30+00:00</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2021-07-30T17:41:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2225a5cd2fbc2ef0e0f78e585db3844f60416a39'/>
<id>urn:sha1:2225a5cd2fbc2ef0e0f78e585db3844f60416a39</id>
<content type='text'>
[ Upstream commit d1340f80f0b8066321b499a376780da00560e857 ]

In the gfs2 withdraw sequence, the dlm protocol is unmounted with a call
to lm_unmount. After a withdraw, users are allowed to unmount the
withdrawn file system. But at that point we may still have glocks left
over that we need to free via unmount's call to gfs2_gl_hash_clear.
These glocks may have never been completed because of whatever problem
caused the withdraw (IO errors or whatever).

Before this patch, function gdlm_put_lock would still try to call into
dlm to unlock these leftover glocks, which resulted in dlm returning
-EINVAL because the lock space was abandoned. These glocks were never
freed because there was no mechanism after that to free them.

This patch adds a check to gdlm_put_lock to see if the locking protocol
was inactive (DFL_UNMOUNT flag) and if so, free the glock and not
make the invalid call into dlm.

I could have combined this "if" with the one that follows, related to
leftover glock LVBs, but I felt the code was more readable with its own
if clause.

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
