From: Mateusz Guzik <mjguzik@gmail.com>
To: kernel test robot <oliver.sang@intel.com>
Cc: Hugh Dickins <hughd@google.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>, Tim Chen <tim.c.chen@intel.com>,
Dave Chinner <dchinner@redhat.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Carlos Maiolino <cem@kernel.org>,
Christian Brauner <brauner@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org
Subject: Re: [linus:master] [shmem,percpu_counter] beb9868628: BUG:KCSAN:data-race_in__percpu_counter_limited_add/__percpu_counter_limited_add
Date: Fri, 31 May 2024 12:29:21 +0200 [thread overview]
Message-ID: <pw76mywfp3o6j3oleqlujejnptd465deydcigypppweqim5uam@nswbchgueaz3> (raw)
In-Reply-To: <202405311100.d46f2cc1-lkp@intel.com>
On Fri, May 31, 2024 at 01:52:40PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed "BUG:KCSAN:data-race_in__percpu_counter_limited_add/__percpu_counter_limited_add" on:
>
> commit: beb9868628445306958fd7b2da1cd369a4a381cc ("shmem,percpu_counter: add _limited_add(fbc, limit, amount)")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> [test failed on linus/master 2bfcfd584ff5ccc8bb7acde19b42570414bf880b]
> [test failed on linux-next/master 6dc544b66971c7f9909ff038b62149105272d26a]
>
> in testcase: trinity
> version:
> with following parameters:
>
> runtime: 300s
> group: group-01
> nr_groups: 5
>
>
>
> compiler: gcc-12
> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
> in our tests,
> dmesg.BUG:KCSAN:data-race_in__percpu_counter_limited_add/__percpu_counter_limited_add
> does not always happen, 88 times out of 150 runs as below.
>
>
> 3022fd7af9604d44 beb9868628445306958fd7b2da1
> ---------------- ---------------------------
> fail:runs %reproduction fail:runs
> | | |
> :60 147% 88:150 dmesg.BUG:KCSAN:data-race_in__percpu_counter_limited_add/__percpu_counter_limited_add
>
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202405311100.d46f2cc1-lkp@intel.com
>
>
>
> [ 301.127451][ T4651] ==================================================================
> [ 301.128485][ T4651] BUG: KCSAN: data-race in __percpu_counter_limited_add / __percpu_counter_limited_add
> [ 301.129715][ T4651]
> [ 301.130014][ T4651] write to 0xffff88810ffc3450 of 8 bytes by task 4674 on cpu 0:
> [ 301.130981][ T4651] __percpu_counter_limited_add (lib/percpu_counter.c:325)
> [ 301.131692][ T4651] shmem_inode_acct_blocks (mm/shmem.c:220)
> [ 301.132319][ T4651] shmem_get_folio_gfp+0x3a9/0x750
> [ 301.133054][ T4651] shmem_write_begin (mm/shmem.c:2135 mm/shmem.c:2692)
> [ 301.133690][ T4651] generic_perform_write (mm/filemap.c:3962)
> [ 301.134347][ T4651] shmem_file_write_iter (mm/shmem.c:2868)
> [ 301.134956][ T4651] do_iter_readv_writev (include/linux/fs.h:1956 fs/read_write.c:735)
> [ 301.135628][ T4651] do_iter_write (fs/read_write.c:860)
> [ 301.136178][ T4651] vfs_writev (fs/read_write.c:933)
> [ 301.136716][ T4651] __x64_sys_pwritev2 (fs/read_write.c:1030 fs/read_write.c:1089 fs/read_write.c:1080 fs/read_write.c:1080)
> [ 301.139719][ T4651] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
> [ 301.140316][ T4651] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
> [ 301.141129][ T4651]
> [ 301.141465][ T4651] read to 0xffff88810ffc3450 of 8 bytes by task 4651 on cpu 1:
> [ 301.142436][ T4651] __percpu_counter_limited_add (lib/percpu_counter.c:302 (discriminator 1))
> [ 301.143222][ T4651] shmem_inode_acct_blocks (mm/shmem.c:220)
> [ 301.143931][ T4651] shmem_get_folio_gfp+0x3a9/0x750
> [ 301.144696][ T4651] shmem_write_begin (mm/shmem.c:2135 mm/shmem.c:2692)
> [ 301.145370][ T4651] generic_perform_write (mm/filemap.c:3962)
> [ 301.146112][ T4651] shmem_file_write_iter (mm/shmem.c:2868)
> [ 301.146697][ T4651] do_iter_readv_writev (include/linux/fs.h:1956 fs/read_write.c:735)
> [ 301.147330][ T4651] do_iter_write (fs/read_write.c:860)
> [ 301.147918][ T4651] vfs_writev (fs/read_write.c:933)
> [ 301.148480][ T4651] __x64_sys_pwritev2 (fs/read_write.c:1030 fs/read_write.c:1089 fs/read_write.c:1080 fs/read_write.c:1080)
> [ 301.149047][ T4651] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
> [ 301.149629][ T4651] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
> [ 301.150358][ T4651]
> [ 301.150643][ T4651] value changed: 0x0000000000059e35 -> 0x0000000000059e56
> [ 301.151483][ T4651]
> [ 301.151778][ T4651] Reported by Kernel Concurrency Sanitizer on:
> [ 301.152559][ T4651] CPU: 1 PID: 4651 Comm: trinity-c7 Not tainted 6.6.0-rc4-00235-gbeb986862844 #1
> [ 301.153676][ T4651] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> [ 301.154962][ T4651] ==================================================================
>
This is the bug I described in my mail:
https://lore.kernel.org/linux-mm/5eemkb4lo5eefp7ijgncgogwmadyzmvjfjmmmvfiki6cwdskfs@hi2z4drqeuz6/
write side:
if (good) {
count = __this_cpu_read(*fbc->counters);
fbc->count += count + amount; <---- line 325
__this_cpu_sub(*fbc->counters, count);
}
read side:
/* Skip taking the lock when safe */
if (abs(count + amount) <= batch &&
fbc->count + unknown <= limit) { <---- line 302
this_cpu_add(*fbc->counters, amount);
local_irq_restore(flags);
return true;
}
As described in the e-mail I don't believe the existence of the routine
is warranted to begin with.
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20240531/202405311100.d46f2cc1-lkp@intel.com
>
>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
prev parent reply other threads:[~2024-05-31 10:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 5:52 kernel test robot
2024-05-31 10:29 ` Mateusz Guzik [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pw76mywfp3o6j3oleqlujejnptd465deydcigypppweqim5uam@nswbchgueaz3 \
--to=mjguzik@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=tim.c.chen@intel.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox