Linux-ext4 Archive on lore.kernel.org
 help / color / Atom feed
* More KCSAN data-race Reports
@ 2021-04-11  3:42 Hao Sun
  2021-04-12  9:02 ` Jan Kara
  0 siblings, 1 reply; 4+ messages in thread
From: Hao Sun @ 2021-04-11  3:42 UTC (permalink / raw)
  To: linux-kernel; +Cc: jack, linux-ext4, tytso


[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

Hi

Since the last KCSAN report[1], I found two more KCSAN reports that
Syzbot had not reported.
Not sure if they are valid bugs, I hope the stack information in
reports can help you locate the problem.
Kernel config can be found in the attachment.

Here is the detailed information:
commit:   3b9cdafb5358eb9f3790de2f728f765fef100731
version:   linux 5.11
git tree:    upstream

Report-1
==================================================================
BUG: KCSAN: data-race in ext4_mark_iloc_dirty / jbd2_journal_commit_transaction

read-write to 0xffff88804451d800 of 8 bytes by task 4821 on cpu 1:
 jbd2_journal_commit_transaction+0x222/0x3200
 kjournald2+0x253/0x470
 kthread+0x1f0/0x220
 ret_from_fork+0x1f/0x30

read to 0xffff88804451d800 of 8 bytes by task 8418 on cpu 0:
 ext4_mark_iloc_dirty+0x14ec/0x16e0
 __ext4_mark_inode_dirty+0x4d2/0x5d0
 ext4_evict_inode+0xb9f/0xed0
 evict+0x1a6/0x410
 iput+0x3fc/0x510
 do_unlinkat+0x2c9/0x4d0
 __x64_sys_unlink+0x2c/0x30
 do_syscall_64+0x39/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Report-2
==================================================================
BUG: KCSAN: data-race in __ext4_handle_dirty_metadata /
jbd2_journal_commit_transaction

read-write to 0xffff88800e142800 of 8 bytes by task 4823 on cpu 0:
 jbd2_journal_commit_transaction+0x222/0x3200
 kjournald2+0x253/0x470
 kthread+0x1f0/0x220
 ret_from_fork+0x1f/0x30

read to 0xffff88800e142800 of 8 bytes by task 7925 on cpu 1:
 __ext4_handle_dirty_metadata+0x11a/0x590
 ext4_mark_iloc_dirty+0x12dd/0x16e0
 __ext4_mark_inode_dirty+0x4d2/0x5d0
 ext4_dirty_inode+0x86/0xa0
 __mark_inode_dirty+0x70/0x6b0
 file_update_time+0x3ab/0x3f0
 file_modified+0x62/0x80
 ext4_buffered_write_iter+0x1f9/0x3d0
 ext4_file_write_iter+0x45e/0x10d0
 vfs_write+0x6db/0x7c0
 ksys_write+0xce/0x180
 __x64_sys_write+0x3e/0x50
 do_syscall_64+0x39/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae


[1] https://lore.kernel.org/lkml/CACkBjsZW5Sp4jB51+C5mrMssgq73x8iEko_EV6CTXVvtVa7KPQ@mail.gmail.com/

[-- Attachment #2: config --]
[-- Type: application/octet-stream, Size: 220871 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: More KCSAN data-race Reports
  2021-04-11  3:42 More KCSAN data-race Reports Hao Sun
@ 2021-04-12  9:02 ` Jan Kara
  2021-04-12 10:42   ` Hao Sun
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Kara @ 2021-04-12  9:02 UTC (permalink / raw)
  To: Hao Sun; +Cc: linux-kernel, jack, linux-ext4, tytso

Hello,

On Sun 11-04-21 11:42:05, Hao Sun wrote:
> Since the last KCSAN report[1], I found two more KCSAN reports that
> Syzbot had not reported.
> Not sure if they are valid bugs, I hope the stack information in
> reports can help you locate the problem.
> Kernel config can be found in the attachment.

Do we have symbolic decoding of the traces below? Because involved
functions are really big so it's difficult to guess what KCSAN is
complaining about... At least I wasn't able to guess it after looking into
the stacktraces for a while.

								Honza

> 
> Here is the detailed information:
> commit:   3b9cdafb5358eb9f3790de2f728f765fef100731
> version:   linux 5.11
> git tree:    upstream
> 
> Report-1
> ==================================================================
> BUG: KCSAN: data-race in ext4_mark_iloc_dirty / jbd2_journal_commit_transaction
> 
> read-write to 0xffff88804451d800 of 8 bytes by task 4821 on cpu 1:
>  jbd2_journal_commit_transaction+0x222/0x3200
>  kjournald2+0x253/0x470
>  kthread+0x1f0/0x220
>  ret_from_fork+0x1f/0x30
> 
> read to 0xffff88804451d800 of 8 bytes by task 8418 on cpu 0:
>  ext4_mark_iloc_dirty+0x14ec/0x16e0
>  __ext4_mark_inode_dirty+0x4d2/0x5d0
>  ext4_evict_inode+0xb9f/0xed0
>  evict+0x1a6/0x410
>  iput+0x3fc/0x510
>  do_unlinkat+0x2c9/0x4d0
>  __x64_sys_unlink+0x2c/0x30
>  do_syscall_64+0x39/0x80
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> 
> Report-2
> ==================================================================
> BUG: KCSAN: data-race in __ext4_handle_dirty_metadata /
> jbd2_journal_commit_transaction
> 
> read-write to 0xffff88800e142800 of 8 bytes by task 4823 on cpu 0:
>  jbd2_journal_commit_transaction+0x222/0x3200
>  kjournald2+0x253/0x470
>  kthread+0x1f0/0x220
>  ret_from_fork+0x1f/0x30
> 
> read to 0xffff88800e142800 of 8 bytes by task 7925 on cpu 1:
>  __ext4_handle_dirty_metadata+0x11a/0x590
>  ext4_mark_iloc_dirty+0x12dd/0x16e0
>  __ext4_mark_inode_dirty+0x4d2/0x5d0
>  ext4_dirty_inode+0x86/0xa0
>  __mark_inode_dirty+0x70/0x6b0
>  file_update_time+0x3ab/0x3f0
>  file_modified+0x62/0x80
>  ext4_buffered_write_iter+0x1f9/0x3d0
>  ext4_file_write_iter+0x45e/0x10d0
>  vfs_write+0x6db/0x7c0
>  ksys_write+0xce/0x180
>  __x64_sys_write+0x3e/0x50
>  do_syscall_64+0x39/0x80
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> 
> 
> [1] https://lore.kernel.org/lkml/CACkBjsZW5Sp4jB51+C5mrMssgq73x8iEko_EV6CTXVvtVa7KPQ@mail.gmail.com/


-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: More KCSAN data-race Reports
  2021-04-12  9:02 ` Jan Kara
@ 2021-04-12 10:42   ` Hao Sun
  2021-04-12 11:31     ` Jan Kara
  0 siblings, 1 reply; 4+ messages in thread
From: Hao Sun @ 2021-04-12 10:42 UTC (permalink / raw)
  To: Jan Kara; +Cc: linux-kernel, jack, linux-ext4, tytso

Jan Kara <jack@suse.cz> 于2021年4月12日周一 下午5:02写道:
>
> Hello,
>
> On Sun 11-04-21 11:42:05, Hao Sun wrote:
> > Since the last KCSAN report[1], I found two more KCSAN reports that
> > Syzbot had not reported.
> > Not sure if they are valid bugs, I hope the stack information in
> > reports can help you locate the problem.
> > Kernel config can be found in the attachment.
>
> Do we have symbolic decoding of the traces below? Because involved
> functions are really big so it's difficult to guess what KCSAN is
> complaining about... At least I wasn't able to guess it after looking into
> the stacktraces for a while.
>
Sorry, the log processing module of Fuzzer still has some logic bugs,
only some of the symbolized reports are stored in the disk.
Interestingly, however, the read-write end that causes data racing in
both reports are in the same location (fs/jbd2/commit.c:443), and this
information should help locate the problem.

Partial symbolized report 1:
==================================================================
BUG: KCSAN: data-race in ext4_mark_iloc_dirty / jbd2_journal_commit_transaction
read-write to 0xffff88804451d800 of 8 bytes by task 4821 on cpu 1:
 jbd2_journal_commit_transaction+0x222/0x3200 fs/jbd2/commit.c:443
 kjournald2+0x253/0x470 fs/jbd2/journal.c:213
 kthread+0x1f0/0x220 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

Partial symbolized report 2:
==================================================================
BUG: KCSAN: data-race in __ext4_handle_dirty_metadata /
jbd2_journal_commit_transaction
read-write to 0xffff88800e142800 of 8 bytes by task 4823 on cpu 0:
 jbd2_journal_commit_transaction+0x222/0x3200 fs/jbd2/commit.c:443
 kjournald2+0x253/0x470 fs/jbd2/journal.c:213
 kthread+0x1f0/0x220 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

>
> >
> > Here is the detailed information:
> > commit:   3b9cdafb5358eb9f3790de2f728f765fef100731
> > version:   linux 5.11
> > git tree:    upstream
> >
> > Report-1
> > ==================================================================
> > BUG: KCSAN: data-race in ext4_mark_iloc_dirty / jbd2_journal_commit_transaction
> >
> > read-write to 0xffff88804451d800 of 8 bytes by task 4821 on cpu 1:
> >  jbd2_journal_commit_transaction+0x222/0x3200
> >  kjournald2+0x253/0x470
> >  kthread+0x1f0/0x220
> >  ret_from_fork+0x1f/0x30
> >
> > read to 0xffff88804451d800 of 8 bytes by task 8418 on cpu 0:
> >  ext4_mark_iloc_dirty+0x14ec/0x16e0
> >  __ext4_mark_inode_dirty+0x4d2/0x5d0
> >  ext4_evict_inode+0xb9f/0xed0
> >  evict+0x1a6/0x410
> >  iput+0x3fc/0x510
> >  do_unlinkat+0x2c9/0x4d0
> >  __x64_sys_unlink+0x2c/0x30
> >  do_syscall_64+0x39/0x80
> >  entry_SYSCALL_64_after_hwframe+0x44/0xae
> >
> > Report-2
> > ==================================================================
> > BUG: KCSAN: data-race in __ext4_handle_dirty_metadata /
> > jbd2_journal_commit_transaction
> >
> > read-write to 0xffff88800e142800 of 8 bytes by task 4823 on cpu 0:
> >  jbd2_journal_commit_transaction+0x222/0x3200
> >  kjournald2+0x253/0x470
> >  kthread+0x1f0/0x220
> >  ret_from_fork+0x1f/0x30
> >
> > read to 0xffff88800e142800 of 8 bytes by task 7925 on cpu 1:
> >  __ext4_handle_dirty_metadata+0x11a/0x590
> >  ext4_mark_iloc_dirty+0x12dd/0x16e0
> >  __ext4_mark_inode_dirty+0x4d2/0x5d0
> >  ext4_dirty_inode+0x86/0xa0
> >  __mark_inode_dirty+0x70/0x6b0
> >  file_update_time+0x3ab/0x3f0
> >  file_modified+0x62/0x80
> >  ext4_buffered_write_iter+0x1f9/0x3d0
> >  ext4_file_write_iter+0x45e/0x10d0
> >  vfs_write+0x6db/0x7c0
> >  ksys_write+0xce/0x180
> >  __x64_sys_write+0x3e/0x50
> >  do_syscall_64+0x39/0x80
> >  entry_SYSCALL_64_after_hwframe+0x44/0xae
> >
> >
> > [1] https://lore.kernel.org/lkml/CACkBjsZW5Sp4jB51+C5mrMssgq73x8iEko_EV6CTXVvtVa7KPQ@mail.gmail.com/
>
>
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: More KCSAN data-race Reports
  2021-04-12 10:42   ` Hao Sun
@ 2021-04-12 11:31     ` Jan Kara
  0 siblings, 0 replies; 4+ messages in thread
From: Jan Kara @ 2021-04-12 11:31 UTC (permalink / raw)
  To: Hao Sun; +Cc: Jan Kara, linux-kernel, jack, linux-ext4, tytso

On Mon 12-04-21 18:42:58, Hao Sun wrote:
> Jan Kara <jack@suse.cz> 于2021年4月12日周一 下午5:02写道:
> >
> > Hello,
> >
> > On Sun 11-04-21 11:42:05, Hao Sun wrote:
> > > Since the last KCSAN report[1], I found two more KCSAN reports that
> > > Syzbot had not reported.
> > > Not sure if they are valid bugs, I hope the stack information in
> > > reports can help you locate the problem.
> > > Kernel config can be found in the attachment.
> >
> > Do we have symbolic decoding of the traces below? Because involved
> > functions are really big so it's difficult to guess what KCSAN is
> > complaining about... At least I wasn't able to guess it after looking into
> > the stacktraces for a while.
> >
> Sorry, the log processing module of Fuzzer still has some logic bugs,
> only some of the symbolized reports are stored in the disk.
> Interestingly, however, the read-write end that causes data racing in
> both reports are in the same location (fs/jbd2/commit.c:443), and this
> information should help locate the problem.
> 
> Partial symbolized report 1:
> ==================================================================
> BUG: KCSAN: data-race in ext4_mark_iloc_dirty / jbd2_journal_commit_transaction
> read-write to 0xffff88804451d800 of 8 bytes by task 4821 on cpu 1:
>  jbd2_journal_commit_transaction+0x222/0x3200 fs/jbd2/commit.c:443
>  kjournald2+0x253/0x470 fs/jbd2/journal.c:213
>  kthread+0x1f0/0x220 kernel/kthread.c:292
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

OK, that is:
	journal->j_flags |= JBD2_FULL_COMMIT_ONGOING;

So likely this is a complaint about j_flags update vs j_flags check race
(we check for JBD2_ABORT flag) all around the code.

So again this is harmless unless the compiler plays some devilish tricks
and doesn't store bogus intermediate values in j_flags during RMW
operations. Not sure how to deal with this one. Just putting data_race()
here doesn't seem right - if the compiler does something unexpected, we are
indeed in trouble. Maybe using bitops for j_flags would be beneficial for
other reasons as well as silencing KCSAN. But it needs more thought.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-11  3:42 More KCSAN data-race Reports Hao Sun
2021-04-12  9:02 ` Jan Kara
2021-04-12 10:42   ` Hao Sun
2021-04-12 11:31     ` Jan Kara

Linux-ext4 Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-ext4/0 linux-ext4/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-ext4 linux-ext4/ https://lore.kernel.org/linux-ext4 \
		linux-ext4@vger.kernel.org
	public-inbox-index linux-ext4

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-ext4


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git