* [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize
@ 2020-02-07 14:29 Qian Cai
2020-02-07 15:12 ` Marco Elver
2020-02-20 4:16 ` Theodore Y. Ts'o
0 siblings, 2 replies; 6+ messages in thread
From: Qian Cai @ 2020-02-07 14:29 UTC (permalink / raw)
To: tytso; +Cc: adilger.kernel, elver, linux-ext4, linux-kernel, Qian Cai
EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
KCSAN,
BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
ext4_write_end+0x4e3/0x750 [ext4]
ext4_update_i_disksize at fs/ext4/ext4.h:3032
(inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
(inlined by) ext4_write_end at fs/ext4/inode.c:1287
generic_perform_write+0x208/0x2a0
ext4_buffered_write_iter+0x11f/0x210 [ext4]
ext4_file_write_iter+0xce/0x9e0 [ext4]
new_sync_write+0x29c/0x3b0
__vfs_write+0x92/0xa0
vfs_write+0x103/0x260
ksys_write+0x9d/0x130
__x64_sys_write+0x4c/0x60
do_syscall_64+0x91/0xb47
entry_SYSCALL_64_after_hwframe+0x49/0xbe
read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
ext4_writepages+0x10ac/0x1d00 [ext4]
mpage_map_and_submit_extent at fs/ext4/inode.c:2468
(inlined by) ext4_writepages at fs/ext4/inode.c:2772
do_writepages+0x5e/0x130
__writeback_single_inode+0xeb/0xb20
writeback_sb_inodes+0x429/0x900
__writeback_inodes_wb+0xc4/0x150
wb_writeback+0x4bd/0x870
wb_workfn+0x6b4/0x960
process_one_work+0x54c/0xbe0
worker_thread+0x80/0x650
kthread+0x1e0/0x200
ret_from_fork+0x27/0x50
Reported by Kernel Concurrency Sanitizer on:
CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G W O L 5.5.0-next-20200204+ #5
Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
Workqueue: writeback wb_workfn (flush-7:0)
Since only the read is operating as lockless (outside of the
"i_data_sem"), load tearing could introduce a logic bug. Fix it by
adding READ_ONCE() for the read and WRITE_ONCE() for the write.
Signed-off-by: Qian Cai <cai@lca.pw>
---
v2: also add WRITE_ONCE() which is recommended even for fixing load tearing.
fs/ext4/ext4.h | 2 +-
fs/ext4/inode.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 9a2ee2428ecc..8329ccc82fa9 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -3029,7 +3029,7 @@ static inline void ext4_update_i_disksize(struct inode *inode, loff_t newsize)
!inode_is_locked(inode));
down_write(&EXT4_I(inode)->i_data_sem);
if (newsize > EXT4_I(inode)->i_disksize)
- EXT4_I(inode)->i_disksize = newsize;
+ WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize);
up_write(&EXT4_I(inode)->i_data_sem);
}
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3313168b680f..6f9862bf63f1 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2465,7 +2465,7 @@ static int mpage_map_and_submit_extent(handle_t *handle,
* truncate are avoided by checking i_size under i_data_sem.
*/
disksize = ((loff_t)mpd->first_page) << PAGE_SHIFT;
- if (disksize > EXT4_I(inode)->i_disksize) {
+ if (disksize > READ_ONCE(EXT4_I(inode)->i_disksize)) {
int err2;
loff_t i_size;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize
2020-02-07 14:29 [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize Qian Cai
@ 2020-02-07 15:12 ` Marco Elver
2020-02-07 15:25 ` Qian Cai
2020-02-07 15:38 ` Qian Cai
2020-02-20 4:16 ` Theodore Y. Ts'o
1 sibling, 2 replies; 6+ messages in thread
From: Marco Elver @ 2020-02-07 15:12 UTC (permalink / raw)
To: Qian Cai; +Cc: Theodore Ts'o, Andreas Dilger, linux-ext4, LKML
On Fri, 7 Feb 2020 at 15:29, Qian Cai <cai@lca.pw> wrote:
>
> EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
> KCSAN,
>
> BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
>
> write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
> ext4_write_end+0x4e3/0x750 [ext4]
> ext4_update_i_disksize at fs/ext4/ext4.h:3032
> (inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
> (inlined by) ext4_write_end at fs/ext4/inode.c:1287
> generic_perform_write+0x208/0x2a0
> ext4_buffered_write_iter+0x11f/0x210 [ext4]
> ext4_file_write_iter+0xce/0x9e0 [ext4]
> new_sync_write+0x29c/0x3b0
> __vfs_write+0x92/0xa0
> vfs_write+0x103/0x260
> ksys_write+0x9d/0x130
> __x64_sys_write+0x4c/0x60
> do_syscall_64+0x91/0xb47
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
> ext4_writepages+0x10ac/0x1d00 [ext4]
> mpage_map_and_submit_extent at fs/ext4/inode.c:2468
> (inlined by) ext4_writepages at fs/ext4/inode.c:2772
> do_writepages+0x5e/0x130
> __writeback_single_inode+0xeb/0xb20
> writeback_sb_inodes+0x429/0x900
> __writeback_inodes_wb+0xc4/0x150
> wb_writeback+0x4bd/0x870
> wb_workfn+0x6b4/0x960
> process_one_work+0x54c/0xbe0
> worker_thread+0x80/0x650
> kthread+0x1e0/0x200
> ret_from_fork+0x27/0x50
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G W O L 5.5.0-next-20200204+ #5
> Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
> Workqueue: writeback wb_workfn (flush-7:0)
>
> Since only the read is operating as lockless (outside of the
> "i_data_sem"), load tearing could introduce a logic bug. Fix it by
> adding READ_ONCE() for the read and WRITE_ONCE() for the write.
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
>
> v2: also add WRITE_ONCE() which is recommended even for fixing load tearing.
Just a note: I keep seeing 'load tearing' mentioned as the only reason:
- The WRITE_ONCE avoids store-tearing (and other optimizations).
- We're not only interested in avoiding load/store tearing. There
are plenty other compiler optimizations that can break concurrent
code: https://lwn.net/Articles/793253/
Thanks,
-- Marco
> fs/ext4/ext4.h | 2 +-
> fs/ext4/inode.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 9a2ee2428ecc..8329ccc82fa9 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -3029,7 +3029,7 @@ static inline void ext4_update_i_disksize(struct inode *inode, loff_t newsize)
> !inode_is_locked(inode));
> down_write(&EXT4_I(inode)->i_data_sem);
> if (newsize > EXT4_I(inode)->i_disksize)
> - EXT4_I(inode)->i_disksize = newsize;
> + WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize);
> up_write(&EXT4_I(inode)->i_data_sem);
> }
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 3313168b680f..6f9862bf63f1 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -2465,7 +2465,7 @@ static int mpage_map_and_submit_extent(handle_t *handle,
> * truncate are avoided by checking i_size under i_data_sem.
> */
> disksize = ((loff_t)mpd->first_page) << PAGE_SHIFT;
> - if (disksize > EXT4_I(inode)->i_disksize) {
> + if (disksize > READ_ONCE(EXT4_I(inode)->i_disksize)) {
> int err2;
> loff_t i_size;
>
> --
> 1.8.3.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize
2020-02-07 15:12 ` Marco Elver
@ 2020-02-07 15:25 ` Qian Cai
2020-02-07 15:38 ` Qian Cai
1 sibling, 0 replies; 6+ messages in thread
From: Qian Cai @ 2020-02-07 15:25 UTC (permalink / raw)
To: Marco Elver; +Cc: Theodore Ts'o, Andreas Dilger, linux-ext4, LKML
On Fri, 2020-02-07 at 16:12 +0100, Marco Elver wrote:
> On Fri, 7 Feb 2020 at 15:29, Qian Cai <cai@lca.pw> wrote:
> >
> > EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
> > KCSAN,
> >
> > BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
> >
> > write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
> > ext4_write_end+0x4e3/0x750 [ext4]
> > ext4_update_i_disksize at fs/ext4/ext4.h:3032
> > (inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
> > (inlined by) ext4_write_end at fs/ext4/inode.c:1287
> > generic_perform_write+0x208/0x2a0
> > ext4_buffered_write_iter+0x11f/0x210 [ext4]
> > ext4_file_write_iter+0xce/0x9e0 [ext4]
> > new_sync_write+0x29c/0x3b0
> > __vfs_write+0x92/0xa0
> > vfs_write+0x103/0x260
> > ksys_write+0x9d/0x130
> > __x64_sys_write+0x4c/0x60
> > do_syscall_64+0x91/0xb47
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
> > ext4_writepages+0x10ac/0x1d00 [ext4]
> > mpage_map_and_submit_extent at fs/ext4/inode.c:2468
> > (inlined by) ext4_writepages at fs/ext4/inode.c:2772
> > do_writepages+0x5e/0x130
> > __writeback_single_inode+0xeb/0xb20
> > writeback_sb_inodes+0x429/0x900
> > __writeback_inodes_wb+0xc4/0x150
> > wb_writeback+0x4bd/0x870
> > wb_workfn+0x6b4/0x960
> > process_one_work+0x54c/0xbe0
> > worker_thread+0x80/0x650
> > kthread+0x1e0/0x200
> > ret_from_fork+0x27/0x50
> >
> > Reported by Kernel Concurrency Sanitizer on:
> > CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G W O L 5.5.0-next-20200204+ #5
> > Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
> > Workqueue: writeback wb_workfn (flush-7:0)
> >
> > Since only the read is operating as lockless (outside of the
> > "i_data_sem"), load tearing could introduce a logic bug. Fix it by
> > adding READ_ONCE() for the read and WRITE_ONCE() for the write.
> >
> > Signed-off-by: Qian Cai <cai@lca.pw>
> > ---
> >
> > v2: also add WRITE_ONCE() which is recommended even for fixing load tearing.
>
> Just a note: I keep seeing 'load tearing' mentioned as the only reason:
>
> - The WRITE_ONCE avoids store-tearing (and other optimizations).
In general, yes, but in this case, store tearing can't happen because those
concurrent writers are protected by "i_data_sem", i.e.,
down_write(&EXT4_I(inode)->i_data_sem);
>
> - We're not only interested in avoiding load/store tearing. There
> are plenty other compiler optimizations that can break concurrent
> code: https://lwn.net/Articles/793253/
>
> Thanks,
> -- Marco
>
>
> > fs/ext4/ext4.h | 2 +-
> > fs/ext4/inode.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > index 9a2ee2428ecc..8329ccc82fa9 100644
> > --- a/fs/ext4/ext4.h
> > +++ b/fs/ext4/ext4.h
> > @@ -3029,7 +3029,7 @@ static inline void ext4_update_i_disksize(struct inode *inode, loff_t newsize)
> > !inode_is_locked(inode));
> > down_write(&EXT4_I(inode)->i_data_sem);
> > if (newsize > EXT4_I(inode)->i_disksize)
> > - EXT4_I(inode)->i_disksize = newsize;
> > + WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize);
> > up_write(&EXT4_I(inode)->i_data_sem);
> > }
> >
> > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> > index 3313168b680f..6f9862bf63f1 100644
> > --- a/fs/ext4/inode.c
> > +++ b/fs/ext4/inode.c
> > @@ -2465,7 +2465,7 @@ static int mpage_map_and_submit_extent(handle_t *handle,
> > * truncate are avoided by checking i_size under i_data_sem.
> > */
> > disksize = ((loff_t)mpd->first_page) << PAGE_SHIFT;
> > - if (disksize > EXT4_I(inode)->i_disksize) {
> > + if (disksize > READ_ONCE(EXT4_I(inode)->i_disksize)) {
> > int err2;
> > loff_t i_size;
> >
> > --
> > 1.8.3.1
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize
2020-02-07 15:12 ` Marco Elver
2020-02-07 15:25 ` Qian Cai
@ 2020-02-07 15:38 ` Qian Cai
2020-02-07 16:08 ` Marco Elver
1 sibling, 1 reply; 6+ messages in thread
From: Qian Cai @ 2020-02-07 15:38 UTC (permalink / raw)
To: Marco Elver; +Cc: Theodore Ts'o, Andreas Dilger, linux-ext4, LKML
On Fri, 2020-02-07 at 16:12 +0100, Marco Elver wrote:
> On Fri, 7 Feb 2020 at 15:29, Qian Cai <cai@lca.pw> wrote:
> >
> > EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
> > KCSAN,
> >
> > BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
> >
> > write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
> > ext4_write_end+0x4e3/0x750 [ext4]
> > ext4_update_i_disksize at fs/ext4/ext4.h:3032
> > (inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
> > (inlined by) ext4_write_end at fs/ext4/inode.c:1287
> > generic_perform_write+0x208/0x2a0
> > ext4_buffered_write_iter+0x11f/0x210 [ext4]
> > ext4_file_write_iter+0xce/0x9e0 [ext4]
> > new_sync_write+0x29c/0x3b0
> > __vfs_write+0x92/0xa0
> > vfs_write+0x103/0x260
> > ksys_write+0x9d/0x130
> > __x64_sys_write+0x4c/0x60
> > do_syscall_64+0x91/0xb47
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
> > ext4_writepages+0x10ac/0x1d00 [ext4]
> > mpage_map_and_submit_extent at fs/ext4/inode.c:2468
> > (inlined by) ext4_writepages at fs/ext4/inode.c:2772
> > do_writepages+0x5e/0x130
> > __writeback_single_inode+0xeb/0xb20
> > writeback_sb_inodes+0x429/0x900
> > __writeback_inodes_wb+0xc4/0x150
> > wb_writeback+0x4bd/0x870
> > wb_workfn+0x6b4/0x960
> > process_one_work+0x54c/0xbe0
> > worker_thread+0x80/0x650
> > kthread+0x1e0/0x200
> > ret_from_fork+0x27/0x50
> >
> > Reported by Kernel Concurrency Sanitizer on:
> > CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G W O L 5.5.0-next-20200204+ #5
> > Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
> > Workqueue: writeback wb_workfn (flush-7:0)
> >
> > Since only the read is operating as lockless (outside of the
> > "i_data_sem"), load tearing could introduce a logic bug. Fix it by
> > adding READ_ONCE() for the read and WRITE_ONCE() for the write.
> >
> > Signed-off-by: Qian Cai <cai@lca.pw>
> > ---
> >
> > v2: also add WRITE_ONCE() which is recommended even for fixing load tearing.
>
> Just a note: I keep seeing 'load tearing' mentioned as the only reason:
>
> - The WRITE_ONCE avoids store-tearing (and other optimizations).
>
> - We're not only interested in avoiding load/store tearing. There
> are plenty other compiler optimizations that can break concurrent
> code: https://lwn.net/Articles/793253/
I also realized that from that article, store tearing is strictly from multiple
concurrent writers. However, in the sense of without the WRITE_ONCE() here,
compilers could still have 2 store instructions, so
CPU0: CPU1:
store #1
read
store #2
which was not mentioned in that article. I called it also load tearing, but
maybe you will call that store tearing. Do I understand correctly?
>
> Thanks,
> -- Marco
>
>
> > fs/ext4/ext4.h | 2 +-
> > fs/ext4/inode.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > index 9a2ee2428ecc..8329ccc82fa9 100644
> > --- a/fs/ext4/ext4.h
> > +++ b/fs/ext4/ext4.h
> > @@ -3029,7 +3029,7 @@ static inline void ext4_update_i_disksize(struct inode *inode, loff_t newsize)
> > !inode_is_locked(inode));
> > down_write(&EXT4_I(inode)->i_data_sem);
> > if (newsize > EXT4_I(inode)->i_disksize)
> > - EXT4_I(inode)->i_disksize = newsize;
> > + WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize);
> > up_write(&EXT4_I(inode)->i_data_sem);
> > }
> >
> > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> > index 3313168b680f..6f9862bf63f1 100644
> > --- a/fs/ext4/inode.c
> > +++ b/fs/ext4/inode.c
> > @@ -2465,7 +2465,7 @@ static int mpage_map_and_submit_extent(handle_t *handle,
> > * truncate are avoided by checking i_size under i_data_sem.
> > */
> > disksize = ((loff_t)mpd->first_page) << PAGE_SHIFT;
> > - if (disksize > EXT4_I(inode)->i_disksize) {
> > + if (disksize > READ_ONCE(EXT4_I(inode)->i_disksize)) {
> > int err2;
> > loff_t i_size;
> >
> > --
> > 1.8.3.1
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize
2020-02-07 15:38 ` Qian Cai
@ 2020-02-07 16:08 ` Marco Elver
0 siblings, 0 replies; 6+ messages in thread
From: Marco Elver @ 2020-02-07 16:08 UTC (permalink / raw)
To: Qian Cai; +Cc: Theodore Ts'o, Andreas Dilger, linux-ext4, LKML
On Fri, 7 Feb 2020 at 16:38, Qian Cai <cai@lca.pw> wrote:
>
> On Fri, 2020-02-07 at 16:12 +0100, Marco Elver wrote:
> > On Fri, 7 Feb 2020 at 15:29, Qian Cai <cai@lca.pw> wrote:
> > >
> > > EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
> > > KCSAN,
> > >
> > > BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
> > >
> > > write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
> > > ext4_write_end+0x4e3/0x750 [ext4]
> > > ext4_update_i_disksize at fs/ext4/ext4.h:3032
> > > (inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
> > > (inlined by) ext4_write_end at fs/ext4/inode.c:1287
> > > generic_perform_write+0x208/0x2a0
> > > ext4_buffered_write_iter+0x11f/0x210 [ext4]
> > > ext4_file_write_iter+0xce/0x9e0 [ext4]
> > > new_sync_write+0x29c/0x3b0
> > > __vfs_write+0x92/0xa0
> > > vfs_write+0x103/0x260
> > > ksys_write+0x9d/0x130
> > > __x64_sys_write+0x4c/0x60
> > > do_syscall_64+0x91/0xb47
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
> > > ext4_writepages+0x10ac/0x1d00 [ext4]
> > > mpage_map_and_submit_extent at fs/ext4/inode.c:2468
> > > (inlined by) ext4_writepages at fs/ext4/inode.c:2772
> > > do_writepages+0x5e/0x130
> > > __writeback_single_inode+0xeb/0xb20
> > > writeback_sb_inodes+0x429/0x900
> > > __writeback_inodes_wb+0xc4/0x150
> > > wb_writeback+0x4bd/0x870
> > > wb_workfn+0x6b4/0x960
> > > process_one_work+0x54c/0xbe0
> > > worker_thread+0x80/0x650
> > > kthread+0x1e0/0x200
> > > ret_from_fork+0x27/0x50
> > >
> > > Reported by Kernel Concurrency Sanitizer on:
> > > CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G W O L 5.5.0-next-20200204+ #5
> > > Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
> > > Workqueue: writeback wb_workfn (flush-7:0)
> > >
> > > Since only the read is operating as lockless (outside of the
> > > "i_data_sem"), load tearing could introduce a logic bug. Fix it by
> > > adding READ_ONCE() for the read and WRITE_ONCE() for the write.
> > >
> > > Signed-off-by: Qian Cai <cai@lca.pw>
> > > ---
> > >
> > > v2: also add WRITE_ONCE() which is recommended even for fixing load tearing.
> >
> > Just a note: I keep seeing 'load tearing' mentioned as the only reason:
> >
> > - The WRITE_ONCE avoids store-tearing (and other optimizations).
> >
> > - We're not only interested in avoiding load/store tearing. There
> > are plenty other compiler optimizations that can break concurrent
> > code: https://lwn.net/Articles/793253/
>
> I also realized that from that article, store tearing is strictly from multiple
> concurrent writers. However, in the sense of without the WRITE_ONCE() here,
> compilers could still have 2 store instructions, so
>
> CPU0: CPU1:
> store #1
> read
> store #2
>
> which was not mentioned in that article. I called it also load tearing, but
> maybe you will call that store tearing. Do I understand correctly?
The effect is the same, so yes. If you have the writer side split the
write, but have a concurrent load, the observed value will appear
"teared". Similar if the reader side splits the reads (the more
obvious case).
> >
> > Thanks,
> > -- Marco
> >
> >
> > > fs/ext4/ext4.h | 2 +-
> > > fs/ext4/inode.c | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > > index 9a2ee2428ecc..8329ccc82fa9 100644
> > > --- a/fs/ext4/ext4.h
> > > +++ b/fs/ext4/ext4.h
> > > @@ -3029,7 +3029,7 @@ static inline void ext4_update_i_disksize(struct inode *inode, loff_t newsize)
> > > !inode_is_locked(inode));
> > > down_write(&EXT4_I(inode)->i_data_sem);
> > > if (newsize > EXT4_I(inode)->i_disksize)
> > > - EXT4_I(inode)->i_disksize = newsize;
> > > + WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize);
> > > up_write(&EXT4_I(inode)->i_data_sem);
> > > }
> > >
> > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> > > index 3313168b680f..6f9862bf63f1 100644
> > > --- a/fs/ext4/inode.c
> > > +++ b/fs/ext4/inode.c
> > > @@ -2465,7 +2465,7 @@ static int mpage_map_and_submit_extent(handle_t *handle,
> > > * truncate are avoided by checking i_size under i_data_sem.
> > > */
> > > disksize = ((loff_t)mpd->first_page) << PAGE_SHIFT;
> > > - if (disksize > EXT4_I(inode)->i_disksize) {
> > > + if (disksize > READ_ONCE(EXT4_I(inode)->i_disksize)) {
> > > int err2;
> > > loff_t i_size;
> > >
> > > --
> > > 1.8.3.1
> > >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize
2020-02-07 14:29 [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize Qian Cai
2020-02-07 15:12 ` Marco Elver
@ 2020-02-20 4:16 ` Theodore Y. Ts'o
1 sibling, 0 replies; 6+ messages in thread
From: Theodore Y. Ts'o @ 2020-02-20 4:16 UTC (permalink / raw)
To: Qian Cai; +Cc: adilger.kernel, elver, linux-ext4, linux-kernel
On Fri, Feb 07, 2020 at 09:29:11AM -0500, Qian Cai wrote:
> EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
> KCSAN,
>
> BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
>
> write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
> ext4_write_end+0x4e3/0x750 [ext4]
> ext4_update_i_disksize at fs/ext4/ext4.h:3032
> (inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
> (inlined by) ext4_write_end at fs/ext4/inode.c:1287
> generic_perform_write+0x208/0x2a0
> ext4_buffered_write_iter+0x11f/0x210 [ext4]
> ext4_file_write_iter+0xce/0x9e0 [ext4]
> new_sync_write+0x29c/0x3b0
> __vfs_write+0x92/0xa0
> vfs_write+0x103/0x260
> ksys_write+0x9d/0x130
> __x64_sys_write+0x4c/0x60
> do_syscall_64+0x91/0xb47
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
> ext4_writepages+0x10ac/0x1d00 [ext4]
> mpage_map_and_submit_extent at fs/ext4/inode.c:2468
> (inlined by) ext4_writepages at fs/ext4/inode.c:2772
> do_writepages+0x5e/0x130
> __writeback_single_inode+0xeb/0xb20
> writeback_sb_inodes+0x429/0x900
> __writeback_inodes_wb+0xc4/0x150
> wb_writeback+0x4bd/0x870
> wb_workfn+0x6b4/0x960
> process_one_work+0x54c/0xbe0
> worker_thread+0x80/0x650
> kthread+0x1e0/0x200
> ret_from_fork+0x27/0x50
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G W O L 5.5.0-next-20200204+ #5
> Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
> Workqueue: writeback wb_workfn (flush-7:0)
>
> Since only the read is operating as lockless (outside of the
> "i_data_sem"), load tearing could introduce a logic bug. Fix it by
> adding READ_ONCE() for the read and WRITE_ONCE() for the write.
>
> Signed-off-by: Qian Cai <cai@lca.pw>
Thanks, applied.
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-20 4:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-07 14:29 [PATCH v2] ext4: fix a data race in EXT4_I(inode)->i_disksize Qian Cai
2020-02-07 15:12 ` Marco Elver
2020-02-07 15:25 ` Qian Cai
2020-02-07 15:38 ` Qian Cai
2020-02-07 16:08 ` Marco Elver
2020-02-20 4:16 ` Theodore Y. Ts'o
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.