* [PATCH 5.10.y] f2fs: fix to seek incorrect data offset in inline data file
@ 2020-12-22 1:16 Chao Yu
2020-12-22 8:36 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: Chao Yu @ 2020-12-22 1:16 UTC (permalink / raw)
To: stable, gregkh; +Cc: linux-f2fs-devel, chao, jaegeuk, yuchao0, kitestramuort
As kitestramuort reported:
F2FS-fs (nvme0n1p4): access invalid blkaddr:1598541474
[ 25.725898] ------------[ cut here ]------------
[ 25.725903] WARNING: CPU: 6 PID: 2018 at f2fs_is_valid_blkaddr+0x23a/0x250
[ 25.725923] Call Trace:
[ 25.725927] ? f2fs_llseek+0x204/0x620
[ 25.725929] ? ovl_copy_up_data+0x14f/0x200
[ 25.725931] ? ovl_copy_up_inode+0x174/0x1e0
[ 25.725933] ? ovl_copy_up_one+0xa22/0xdf0
[ 25.725936] ? ovl_copy_up_flags+0xa6/0xf0
[ 25.725938] ? ovl_aio_cleanup_handler+0xd0/0xd0
[ 25.725939] ? ovl_maybe_copy_up+0x86/0xa0
[ 25.725941] ? ovl_open+0x22/0x80
[ 25.725943] ? do_dentry_open+0x136/0x350
[ 25.725945] ? path_openat+0xb7e/0xf40
[ 25.725947] ? __check_sticky+0x40/0x40
[ 25.725948] ? do_filp_open+0x70/0x100
[ 25.725950] ? __check_sticky+0x40/0x40
[ 25.725951] ? __check_sticky+0x40/0x40
[ 25.725953] ? __x64_sys_openat+0x1db/0x2c0
[ 25.725955] ? do_syscall_64+0x2d/0x40
[ 25.725957] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
llseek() reports invalid block address access, the root cause is if
file has inline data, f2fs_seek_block() will access inline data regard
as block address index in inode block, which should be wrong, fix it.
Fixes: 788e96d1d3994 ("f2fs: code cleanup by removing unnecessary check")
Fixes: 267378d4de69 ("f2fs: introduce f2fs_seek_block to support SEEK_{DATA, HOLE} in llseek")
Cc: stable <stable@vger.kernel.org> # 3.16+
Reported-by: kitestramuort <kitestramuort@autistici.org>
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
This will cause boot failure in f2fs image, which was reported in gentoo
community, I'd like to fix them in stable kernel 5.10 first as request in
bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=210825
fs/f2fs/file.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index ee861c6d9ff0..fe39e591e5b4 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -412,9 +412,14 @@ static loff_t f2fs_seek_block(struct file *file, loff_t offset, int whence)
goto fail;
/* handle inline data case */
- if (f2fs_has_inline_data(inode) && whence == SEEK_HOLE) {
- data_ofs = isize;
- goto found;
+ if (f2fs_has_inline_data(inode)) {
+ if (whence == SEEK_HOLE) {
+ data_ofs = isize;
+ goto found;
+ } else if (whence == SEEK_DATA) {
+ data_ofs = offset;
+ goto found;
+ }
}
pgofs = (pgoff_t)(offset >> PAGE_SHIFT);
--
2.29.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH 5.10.y] f2fs: fix to seek incorrect data offset in inline data file
2020-12-22 1:16 [PATCH 5.10.y] f2fs: fix to seek incorrect data offset in inline data file Chao Yu
@ 2020-12-22 8:36 ` Greg KH
2020-12-22 8:37 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2020-12-22 8:36 UTC (permalink / raw)
To: Chao Yu; +Cc: stable, linux-f2fs-devel, chao, jaegeuk, kitestramuort
On Tue, Dec 22, 2020 at 09:16:34AM +0800, Chao Yu wrote:
> As kitestramuort reported:
>
> F2FS-fs (nvme0n1p4): access invalid blkaddr:1598541474
> [ 25.725898] ------------[ cut here ]------------
> [ 25.725903] WARNING: CPU: 6 PID: 2018 at f2fs_is_valid_blkaddr+0x23a/0x250
> [ 25.725923] Call Trace:
> [ 25.725927] ? f2fs_llseek+0x204/0x620
> [ 25.725929] ? ovl_copy_up_data+0x14f/0x200
> [ 25.725931] ? ovl_copy_up_inode+0x174/0x1e0
> [ 25.725933] ? ovl_copy_up_one+0xa22/0xdf0
> [ 25.725936] ? ovl_copy_up_flags+0xa6/0xf0
> [ 25.725938] ? ovl_aio_cleanup_handler+0xd0/0xd0
> [ 25.725939] ? ovl_maybe_copy_up+0x86/0xa0
> [ 25.725941] ? ovl_open+0x22/0x80
> [ 25.725943] ? do_dentry_open+0x136/0x350
> [ 25.725945] ? path_openat+0xb7e/0xf40
> [ 25.725947] ? __check_sticky+0x40/0x40
> [ 25.725948] ? do_filp_open+0x70/0x100
> [ 25.725950] ? __check_sticky+0x40/0x40
> [ 25.725951] ? __check_sticky+0x40/0x40
> [ 25.725953] ? __x64_sys_openat+0x1db/0x2c0
> [ 25.725955] ? do_syscall_64+0x2d/0x40
> [ 25.725957] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> llseek() reports invalid block address access, the root cause is if
> file has inline data, f2fs_seek_block() will access inline data regard
> as block address index in inode block, which should be wrong, fix it.
>
> Fixes: 788e96d1d3994 ("f2fs: code cleanup by removing unnecessary check")
> Fixes: 267378d4de69 ("f2fs: introduce f2fs_seek_block to support SEEK_{DATA, HOLE} in llseek")
> Cc: stable <stable@vger.kernel.org> # 3.16+
> Reported-by: kitestramuort <kitestramuort@autistici.org>
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>
> This will cause boot failure in f2fs image, which was reported in gentoo
> community, I'd like to fix them in stable kernel 5.10 first as request in
> bugzilla:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=210825
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 5.10.y] f2fs: fix to seek incorrect data offset in inline data file
2020-12-22 8:36 ` Greg KH
@ 2020-12-22 8:37 ` Greg KH
2020-12-22 8:45 ` Chao Yu
0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2020-12-22 8:37 UTC (permalink / raw)
To: Chao Yu; +Cc: stable, linux-f2fs-devel, chao, jaegeuk, kitestramuort
On Tue, Dec 22, 2020 at 09:36:35AM +0100, Greg KH wrote:
> On Tue, Dec 22, 2020 at 09:16:34AM +0800, Chao Yu wrote:
> > As kitestramuort reported:
> >
> > F2FS-fs (nvme0n1p4): access invalid blkaddr:1598541474
> > [ 25.725898] ------------[ cut here ]------------
> > [ 25.725903] WARNING: CPU: 6 PID: 2018 at f2fs_is_valid_blkaddr+0x23a/0x250
> > [ 25.725923] Call Trace:
> > [ 25.725927] ? f2fs_llseek+0x204/0x620
> > [ 25.725929] ? ovl_copy_up_data+0x14f/0x200
> > [ 25.725931] ? ovl_copy_up_inode+0x174/0x1e0
> > [ 25.725933] ? ovl_copy_up_one+0xa22/0xdf0
> > [ 25.725936] ? ovl_copy_up_flags+0xa6/0xf0
> > [ 25.725938] ? ovl_aio_cleanup_handler+0xd0/0xd0
> > [ 25.725939] ? ovl_maybe_copy_up+0x86/0xa0
> > [ 25.725941] ? ovl_open+0x22/0x80
> > [ 25.725943] ? do_dentry_open+0x136/0x350
> > [ 25.725945] ? path_openat+0xb7e/0xf40
> > [ 25.725947] ? __check_sticky+0x40/0x40
> > [ 25.725948] ? do_filp_open+0x70/0x100
> > [ 25.725950] ? __check_sticky+0x40/0x40
> > [ 25.725951] ? __check_sticky+0x40/0x40
> > [ 25.725953] ? __x64_sys_openat+0x1db/0x2c0
> > [ 25.725955] ? do_syscall_64+0x2d/0x40
> > [ 25.725957] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > llseek() reports invalid block address access, the root cause is if
> > file has inline data, f2fs_seek_block() will access inline data regard
> > as block address index in inode block, which should be wrong, fix it.
> >
> > Fixes: 788e96d1d3994 ("f2fs: code cleanup by removing unnecessary check")
> > Fixes: 267378d4de69 ("f2fs: introduce f2fs_seek_block to support SEEK_{DATA, HOLE} in llseek")
> > Cc: stable <stable@vger.kernel.org> # 3.16+
> > Reported-by: kitestramuort <kitestramuort@autistici.org>
> > Signed-off-by: Chao Yu <yuchao0@huawei.com>
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >
> > This will cause boot failure in f2fs image, which was reported in gentoo
> > community, I'd like to fix them in stable kernel 5.10 first as request in
> > bugzilla:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=210825
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
> </formletter>
Specifically, what is the git commit id of this patch in Linus's tree?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 5.10.y] f2fs: fix to seek incorrect data offset in inline data file
2020-12-22 8:37 ` Greg KH
@ 2020-12-22 8:45 ` Chao Yu
0 siblings, 0 replies; 4+ messages in thread
From: Chao Yu @ 2020-12-22 8:45 UTC (permalink / raw)
To: Greg KH; +Cc: stable, linux-f2fs-devel, chao, jaegeuk, kitestramuort
On 2020/12/22 16:37, Greg KH wrote:
> On Tue, Dec 22, 2020 at 09:36:35AM +0100, Greg KH wrote:
>> On Tue, Dec 22, 2020 at 09:16:34AM +0800, Chao Yu wrote:
>>> As kitestramuort reported:
>>>
>>> F2FS-fs (nvme0n1p4): access invalid blkaddr:1598541474
>>> [ 25.725898] ------------[ cut here ]------------
>>> [ 25.725903] WARNING: CPU: 6 PID: 2018 at f2fs_is_valid_blkaddr+0x23a/0x250
>>> [ 25.725923] Call Trace:
>>> [ 25.725927] ? f2fs_llseek+0x204/0x620
>>> [ 25.725929] ? ovl_copy_up_data+0x14f/0x200
>>> [ 25.725931] ? ovl_copy_up_inode+0x174/0x1e0
>>> [ 25.725933] ? ovl_copy_up_one+0xa22/0xdf0
>>> [ 25.725936] ? ovl_copy_up_flags+0xa6/0xf0
>>> [ 25.725938] ? ovl_aio_cleanup_handler+0xd0/0xd0
>>> [ 25.725939] ? ovl_maybe_copy_up+0x86/0xa0
>>> [ 25.725941] ? ovl_open+0x22/0x80
>>> [ 25.725943] ? do_dentry_open+0x136/0x350
>>> [ 25.725945] ? path_openat+0xb7e/0xf40
>>> [ 25.725947] ? __check_sticky+0x40/0x40
>>> [ 25.725948] ? do_filp_open+0x70/0x100
>>> [ 25.725950] ? __check_sticky+0x40/0x40
>>> [ 25.725951] ? __check_sticky+0x40/0x40
>>> [ 25.725953] ? __x64_sys_openat+0x1db/0x2c0
>>> [ 25.725955] ? do_syscall_64+0x2d/0x40
>>> [ 25.725957] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>
>>> llseek() reports invalid block address access, the root cause is if
>>> file has inline data, f2fs_seek_block() will access inline data regard
>>> as block address index in inode block, which should be wrong, fix it.
>>>
>>> Fixes: 788e96d1d3994 ("f2fs: code cleanup by removing unnecessary check")
>>> Fixes: 267378d4de69 ("f2fs: introduce f2fs_seek_block to support SEEK_{DATA, HOLE} in llseek")
>>> Cc: stable <stable@vger.kernel.org> # 3.16+
>>> Reported-by: kitestramuort <kitestramuort@autistici.org>
>>> Signed-off-by: Chao Yu <yuchao0@huawei.com>
>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>> ---
>>>
>>> This will cause boot failure in f2fs image, which was reported in gentoo
>>> community, I'd like to fix them in stable kernel 5.10 first as request in
>>> bugzilla:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=210825
>>
>> <formletter>
>>
>> This is not the correct way to submit patches for inclusion in the
>> stable kernel tree. Please read:
>> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>> for how to do this properly.
I forgot to add "Cc: stable ..." tag in original patch before this patch been
merged in Linus' tree, so I think "Option 2" should be right way to backport this
patch, however, I forgot to tag commit id of this patch.
>>
>> </formletter>
>
> Specifically, what is the git commit id of this patch in Linus's tree?
Will add git commit id, and resend the patch.
Thanks,
>
> thanks,
>
> greg k-h
> .
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-22 8:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-12-22 1:16 [PATCH 5.10.y] f2fs: fix to seek incorrect data offset in inline data file Chao Yu
2020-12-22 8:36 ` Greg KH
2020-12-22 8:37 ` Greg KH
2020-12-22 8:45 ` Chao Yu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).