[PATCH 6.4 018/800] splice: Fix filemap_splice_read() to use the correct inode

[PATCH 6.4 018/800] splice: Fix filemap_splice_read() to use the correct inode

[Greg Kroah-Hartman]

From: David Howells <dhowells@redhat.com>

[ Upstream commit c37222082f23c456664d1c3182a714670ab8f9a4 ]

Fix filemap_splice_read() to use file->f_mapping->host, not file->f_inode,
as the source of the file size because in the case of a block device,
file->f_inode points to the block-special file (which is typically 0
length) and not the backing store.

Fixes: 07073eb01c5f ("splice: Add a func to do a splice from a buffered file without ITER_PIPE")
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christian Brauner <brauner@kernel.org>
cc: Steve French <stfrench@microsoft.com>
cc: Jens Axboe <axboe@kernel.dk>
cc: Al Viro <viro@zeniv.linux.org.uk>
cc: David Hildenbrand <david@redhat.com>
cc: John Hubbard <jhubbard@nvidia.com>
cc: linux-mm@kvack.org
cc: linux-block@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
Link: https://lore.kernel.org/r/20230522135018.2742245-2-dhowells@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 mm/filemap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 83dda76d1fc36..8abce63b259c9 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2906,7 +2906,7 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos,
 	do {
 		cond_resched();
 
-		if (*ppos >= i_size_read(file_inode(in)))
+		if (*ppos >= i_size_read(in->f_mapping->host))
 			break;
 
 		iocb.ki_pos = *ppos;
@@ -2922,7 +2922,7 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos,
 		 * part of the page is not copied back to userspace (unless
 		 * another truncate extends the file - this is desired though).
 		 */
-		isize = i_size_read(file_inode(in));
+		isize = i_size_read(in->f_mapping->host);
 		if (unlikely(*ppos >= isize))
 			break;
 		end_offset = min_t(loff_t, isize, *ppos + len);
-- 
2.39.2

[PATCH 6.4 706/800] afs: Fix accidental truncation when storing data

[Greg Kroah-Hartman]

From: David Howells <dhowells@redhat.com>

[ Upstream commit 03275585cabd0240944f19f33d7584a1b099a3a8 ]

When an AFS FS.StoreData RPC call is made, amongst other things it is
given the resultant file size to be.  On the server, this is processed
by truncating the file to new size and then writing the data.

Now, kafs has a lock (vnode->io_lock) that serves to serialise
operations against a specific vnode (ie.  inode), but the parameters for
the op are set before the lock is taken.  This allows two writebacks
(say sync and kswapd) to race - and if writes are ongoing the writeback
for a later write could occur before the writeback for an earlier one if
the latter gets interrupted.

Note that afs_writepages() cannot take i_mutex and only takes a shared
lock on vnode->validate_lock.

Also note that the server does the truncation and the write inside a
lock, so there's no problem at that end.

Fix this by moving the calculation for the proposed new i_size inside
the vnode->io_lock.  Also reset the iterator (which we might have read
from) and update the mtime setting there.

Fixes: bd80d8a80e12 ("afs: Use ITER_XARRAY for writing")
Reported-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
cc: linux-fsdevel@vger.kernel.org
Link: https://lore.kernel.org/r/3526895.1687960024@warthog.procyon.org.uk/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/afs/write.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/afs/write.c b/fs/afs/write.c
index 8750b99c3f566..c1f4391ccd7c6 100644
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -413,17 +413,19 @@ static int afs_store_data(struct afs_vnode *vnode, struct iov_iter *iter, loff_t
 	afs_op_set_vnode(op, 0, vnode);
 	op->file[0].dv_delta = 1;
 	op->file[0].modification = true;
-	op->store.write_iter = iter;
 	op->store.pos = pos;
 	op->store.size = size;
-	op->store.i_size = max(pos + size, vnode->netfs.remote_i_size);
 	op->store.laundering = laundering;
-	op->mtime = vnode->netfs.inode.i_mtime;
 	op->flags |= AFS_OPERATION_UNINTR;
 	op->ops = &afs_store_data_operation;
 
 try_next_key:
 	afs_begin_vnode_operation(op);
+
+	op->store.write_iter = iter;
+	op->store.i_size = max(pos + size, vnode->netfs.remote_i_size);
+	op->mtime = vnode->netfs.inode.i_mtime;
+
 	afs_wait_for_operation(op);
 
 	switch (op->error) {
-- 
2.39.2

Re: [PATCH 6.4 000/800] 6.4.4-rc1 review

[Naresh Kamboju]

On Mon, 17 Jul 2023 at 01:24, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.4.4 release.
> There are 800 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue, 18 Jul 2023 19:48:07 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.4.4-rc1.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Following kernel warnings / BUG noticed on qemu-arm64 while running
Kunit / KASAN tests while booting stable rc 6.4 kernel.

Similar issues have been reported on Linux next [1].
 next: qemu-arm64: kernel BUG at fs/inode.c:1763!
[1] https://lore.kernel.org/linux-mm/5d48dd9a-1822-4917-a77e-193a48ed3bd8@kili.mountain/

Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>


Crash log:
---

<6>[  928.522368] ok 67 Encryption test suite # SKIP
<6>[  928.526361]     KTAP version 1
<6>[  928.527663]     # Subtest: Handshake API tests
<6>[  928.528569]     1..11
<6>[  928.529461]         KTAP version 1
<6>[  928.530289]         # Subtest: req_alloc API fuzzing
<6>[  928.534580]         ok 1 handshake_req_alloc NULL proto
<6>[  928.540928]         ok 2 handshake_req_alloc CLASS_NONE
<6>[  928.546026]         ok 3 handshake_req_alloc CLASS_MAX
<6>[  928.556181]         ok 4 handshake_req_alloc no callbacks
<6>[  928.561854]         ok 5 handshake_req_alloc no done callback
<6>[  928.568591]         ok 6 handshake_req_alloc excessive privsize
<6>[  928.574197]         ok 7 handshake_req_alloc all good
<6>[  928.577290]     # req_alloc API fuzzing: pass:7 fail:0 skip:0 total:7
<6>[  928.578830]     ok 1 req_alloc API fuzzing
<6>[  928.589194]     ok 2 req_submit NULL req arg
<6>[  928.595860]     ok 3 req_submit NULL sock arg
<6>[  928.601760]     ok 4 req_submit NULL sock->file
<6>[  928.613613]     ok 5 req_lookup works
<6>[  928.621095]     ok 6 req_submit max pending
<6>[  928.627492]     ok 7 req_submit multiple
<6>[  928.633124]     ok 8 req_cancel before accept
<6>[  928.640751]     ok 9 req_cancel after accept
<6>[  928.646414]     ok 10 req_cancel after done
<4>[  928.650411] ------------[ cut here ]------------
<2>[  928.654074] kernel BUG at fs/inode.c:1805!
<0>[  928.655661] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
<4>[  928.657205] Modules linked in:
<4>[  928.659307] CPU: 1 PID: 21 Comm: kworker/1:0 Tainted: G
       N 6.4.4-rc1 #1
<4>[  928.660829] Hardware name: linux,dummy-virt (DT)
<4>[  928.662415] Workqueue: events delayed_fput
<4>[  928.664806] pstate: 42400005 (nZcv daif +PAN -UAO +TCO -DIT
-SSBS BTYPE=--)
<4>[  928.666592] pc : iput+0x2cc/0x2d0
<4>[  928.667870] lr : iput+0x30/0x2d0
<4>[  928.668975] sp : ffff8000081d7af0
<4>[  928.669951] x29: ffff8000081d7af0 x28: ffff0000c094c020 x27:
00000000002e0003
<4>[  928.672194] x26: ffff0000c4f61668 x25: ffff0000c6911590 x24:
0000000000000000
<4>[  928.674232] x23: ffff0000c0467638 x22: ffff0000c69115b0 x21:
ffff0000c0467598
<4>[  928.676413] x20: ffff0000c0467500 x19: ffff0000c0467500 x18:
0000000010992f9a
<4>[  928.678485] x17: ffffa2bb7d60bc64 x16: ffffa2bb7d60c00c x15:
ffffa2bb7e7c02f4
<4>[  928.680443] x14: ffffa2bb7d63c708 x13: ffffa2bb7d216100 x12:
0000000000000001
<4>[  928.682505] x11: 1fffe0001808ceb1 x10: 1fffe0001808ceb3 x9 :
0000000000000000
<4>[  928.684647] x8 : 0000000000000060 x7 : 0000000000000000 x6 :
ffffa2bb7d5c67b8
<4>[  928.686630] x5 : ffff0000c814a6d8 x4 : 0000000000000000 x3 :
ffffa2bb7ead2fec
<4>[  928.689091] x2 : 0000000000000001 x1 : 0000000000000001 x0 :
ffff0000c0467598
<6>[  928.690005]     ok 11 req_destroy works
<4>[  928.690476]
<6>[  928.693528] # Handshake API tests: pass:11 fail:0 skip:0 total:11
<4>[  928.694200] Call trace:
<4>[  928.694404]  iput+0x2cc/0x2d0
<6>[  928.697513] # Totals: pass:17 fail:0 skip:0 total:17
<4>[  928.697467]  dentry_unlink_inode+0x220/0x240
<6>[  928.698341] ok 68 Handshake API tests
<4>[  928.699216]  __dentry_kill+0x190/0x2a4
<4>[  928.702948]  dentry_kill+0x90/0x150
<4>[  928.704551]  dput+0xd8/0x144
<4>[  928.706425]  __fput+0x2bc/0x3cc
<4>[  928.707982]  delayed_fput+0x54/0x6c
<4>[  928.709490]  process_one_work+0x3c4/0x574
<4>[  928.711092]  worker_thread+0x488/0x83c
<4>[  928.712551]  kthread+0x1ac/0x238
<4>[  928.714034]  ret_from_fork+0x10/0x20
<0>[  928.717103] Code: 94522f0a 17ffffec d4210000 17ffffba (d4210000)
<4>[  928.719393] ---[ end trace 0000000000000000 ]---
<6>[  928.721045] note: kworker/1:0[21] exited with irqs disabled
<6>[  928.725022] note: kworker/1:0[21] exited with preempt_count 1
<6>[  928.730067] uart-pl011 9000000.pl011: no DMA platform data
<4>[  928.733763] ------------[ cut here ]------------
<4>[  928.735164] WARNING: CPU: 1 PID: 0 at
kernel/context_tracking.c:128 ct_kernel_exit+0xa4/0xac
<4>[  928.737209] Modules linked in:
<4>[  928.738504] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D
    N 6.4.4-rc1 #1
<4>[  928.740310] Hardware name: linux,dummy-virt (DT)
<4>[  928.741569] pstate: 224003c5 (nzCv DAIF +PAN -UAO +TCO -DIT
-SSBS BTYPE=--)
<4>[  928.743556] pc : ct_kernel_exit+0xa4/0xac
<4>[  928.745560] lr : ct_kernel_exit+0x14/0xac
<4>[  928.747498] sp : ffff800008187db0
<4>[  928.749156] x29: ffff800008187db0 x28: ffffa2bb7ff5cb38 x27:
ffffa2bb7ffdd000
<4>[  928.751416] x26: 0000000000000002 x25: 0000000000000001 x24:
0000000000000000
<4>[  928.753426] x23: 0000000000000000 x22: 0000000000000000 x21:
ffffa2bb7ffddb50
<4>[  928.755520] x20: ffffa2bb7ffdda40 x19: ffff0000daea6a20 x18:
0000000010992f9a
<4>[  928.757619] x17: 0000000000000000 x16: 0000000100000000 x15:
0000000200000002
<4>[  928.759766] x14: 00000000ffffa2bb x13: 00000000000711d6 x12:
0000000008000000
<4>[  928.761789] x11: 000db58580000000 x10: 4000000000000000 x9 :
4000000000000002
<4>[  928.763942] x8 : ffffa2bb7ff5aa20 x7 : 0000000000000000 x6 :
000000000000003f
<4>[  928.766237] x5 : 0000000000000040 x4 : 0000000000000000 x3 :
ffffa2bb7d316f00
<4>[  928.768327] x2 : 0000000000000001 x1 : 0000000000000001 x0 :
ffff5d455af4c000
<4>[  928.770366] Call trace:
<4>[  928.771153]  ct_kernel_exit+0xa4/0xac
<4>[  928.772308]  ct_idle_enter+0x10/0x1c
<4>[  928.773463]  default_idle_call+0x1c/0x38
<4>[  928.774700]  do_idle+0x134/0x2fc
<4>[  928.775976]  cpu_startup_entry+0x24/0x28
<4>[  928.777255]  secondary_start_kernel+0x170/0x194
<4>[  928.778638]  __secondary_switched+0xb8/0xbc
<4>[  928.780012] ---[ end trace 0000000000000000 ]---
<6>[  928.888117] EXT4-fs (vda): mounted filesystem
488f3595-af73-4163-86f5-9256efc01ed6 ro with ordered data mode. Quota
mode: none.


Links:
 - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4.3-801-g2b7c5a626789/testrun/18368775/suite/boot/test/clang-nightly-defconfig-40bc7ee5/log
 - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4.3-801-g2b7c5a626789/testrun/18368340/suite/boot/test/gcc-12-defconfig-40bc7ee5/log
 - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4.3-801-g2b7c5a626789/testrun/18374719/suite/boot/test/gcc-12-lkftconfig-kunit/details/
 - https://storage.tuxsuite.com/public/linaro/lkft/builds/2SfVz5dCm2BdJzRORqOHFcy7nOK/


--
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 6.4 000/800] 6.4.4-rc1 review

[Greg Kroah-Hartman]

On Mon, Jul 17, 2023 at 11:23:40AM +0530, Naresh Kamboju wrote:
> On Mon, 17 Jul 2023 at 01:24, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 6.4.4 release.
> > There are 800 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue, 18 Jul 2023 19:48:07 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.4.4-rc1.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> 
> Following kernel warnings / BUG noticed on qemu-arm64 while running
> Kunit / KASAN tests while booting stable rc 6.4 kernel.
> 
> Similar issues have been reported on Linux next [1].
>  next: qemu-arm64: kernel BUG at fs/inode.c:1763!
> [1] https://lore.kernel.org/linux-mm/5d48dd9a-1822-4917-a77e-193a48ed3bd8@kili.mountain/
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

Does bisection help?

thanks,

greg k-h