syzbot report null-ptr-deref Write in f2fs_stop_gc_thread, because
shutdown and remount can cause multi-path entry into f2fs_stop_gc_thread,
resulting in incorrect access to f2fs_gc_task before it is properly
initialized.
Reported-and-tested-by: syzbot+1a8e2b31f2ac9bd3d...@syzkaller.appspotmail.c
On 07/26, Chao Yu wrote:
> On 2024/7/26 0:55, Jaegeuk Kim wrote:
> > On 07/12, Chao Yu wrote:
> > > All directory blocks are within the scope of i_size, so let's limit
> > > the end_block to just check valid dirent blocks.
> >
> > Do we really need this?
>
> f2fs_readdir() and f2fs_empty_dir() us
On 07/26, Chao Yu wrote:
> On 2024/2/21 15:32, liujinbao1 wrote:
> > From: liujinbao1
> >
> > When we add "atgc" to the fstab table, ATGC is not immediately enabled.
> > There is a 7-day time threshold, and we can use "atgc_enabled" to
> > show whether ATGC is enabled.
>
> Oh, I missed to reply
The path field in c.devices[i] is a pointer and is normally filled
in using strdup. This makes it invalid to copy MAX_PATH_LEN bytes
from it because the string may be shorter than that. Therefore,
fix the code to use strncpy to copy the string instead.
Signed-off-by: Peter Collingbourne
---
mkfs
On Fri, Jul 26, 2024 at 11:09:02AM -0700, Christoph Hellwig wrote:
> On Fri, Jul 26, 2024 at 01:58:00PM -0400, Theodore Ts'o wrote:
> > Yeah, that's my reaction as well. This only saves 50 lines of code in
> > ext4, and that includes unrelated changes such as getting rid of "int
> > i" and putting
On Fri, Jul 26, 2024 at 05:22:37PM +0200, David Sterba wrote:
> All of this sounds overengineered for something that is a simple array
> and two helpers. The code is not finalized so I'll wait for the next
> version but specific file order in makefile and linker tricks seems
> fragile and I'm not s
On Fri, Jul 26, 2024 at 01:58:00PM -0400, Theodore Ts'o wrote:
> Yeah, that's my reaction as well. This only saves 50 lines of code in
> ext4, and that includes unrelated changes such as getting rid of "int
> i" and putting the declaration into the for loop --- "for (int i =
> ..."). Sure, that s
On Sat, Jul 20, 2024 at 03:45:40PM +0800, Chao Yu wrote:
> Test that we will simulate sqlite atomic write logic w/ below steps:
> 1. create a regular file, and initialize it w/ 0xff data
> 2. start transaction (via F2FS_IOC_START_ATOMIC_WRITE) on it
> 3. write transaction data
> 4. trigger direct r
On Sat, Jul 20, 2024 at 03:43:16PM +0800, Chao Yu wrote:
> Test that we will simulate sqlite atomic write logic w/ below steps:
> 1. create a regular file, and initialize it w/ 0xff data
> 2. start transaction (via F2FS_IOC_START_ATOMIC_WRITE) on it
> 3. write transaction data
> 4. trigger foregrou
On Fri, Jul 26, 2024 at 07:04:35AM -0700, Christoph Hellwig wrote:
> On Fri, Jul 26, 2024 at 04:54:59PM +0800, Youling Tang wrote:
> > Based on this patch, we may need to do these things with this
> >
> >
> > 1. Change the order of *.o in the Makefile (the same order as before the
> > change)
>
>
syzbot has bisected this issue to:
commit b62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5
Author: Chao Yu
Date: Sun Apr 23 15:49:15 2023 +
f2fs: support errors=remount-ro|continue|panic mountoption
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=119745f198
start commit: 17
On Fri, Jul 26, 2024 at 04:54:59PM +0800, Youling Tang wrote:
> Based on this patch, we may need to do these things with this
>
>
> 1. Change the order of *.o in the Makefile (the same order as before the
> change)
While we'll need to be careful, we don't need to match the exact
order. Most of th
On 2024/7/26 14:27, Zhiguo Niu wrote:
This is a supplement to commit 6d1451bf7f84 ("f2fs: fix to use per-inode
maxbytes")
for some missed cases, also cleanup redundant code in f2fs_llseek.
Cc: Chengguang Xu
Signed-off-by: Zhiguo Niu
Reviewed-by: Chao Yu
Thanks,
_
On 2024/7/26 10:25, Wu Bo wrote:
The cp_ver of node footer is useful when analyzing data corruption
issues.
Signed-off-by: Wu Bo
Reviewed-by: Chao Yu
Thanks,
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.
On 26/07/2024 03:46, Christoph Hellwig wrote:
On Thu, Jul 25, 2024 at 07:14:14PM +0200, Goffredo Baroncelli wrote:
Instead of relying to the "expected" order of the compiler/linker,
why doesn't manage the chain explicitly ? Something like:
Because that doesn't actually solve anything over simpl
Hello,
syzbot found the following issue on:
HEAD commit:1722389b0d86 Merge tag 'net-6.11-rc1' of git://git.kernel...
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1495542398
kernel config: https://syzkaller.appspot.com/x/.config?x=b698a1b2fcd7ef5f
das
16 matches
Mail list logo
