aboutsummaryrefslogtreecommitdiff
path: root/scripts/gcc-plugins/cyc_complexity_plugin.c
diff options
context:
space:
mode:
authorSuren Baghdasaryan <[email protected]>2020-07-30 12:26:32 -0700
committerGreg Kroah-Hartman <[email protected]>2020-07-31 14:41:43 +0200
commit3e338d3c95c735dc3265a86016bb4c022ec7cadc (patch)
tree3c1222a64fc7c3a9a9157da7daac1d36b22559c6 /scripts/gcc-plugins/cyc_complexity_plugin.c
parent97a6f772f36b7f52bcfa56a581bbd2470cffe23d (diff)
staging: android: ashmem: Fix lockdep warning for write operation
syzbot report [1] describes a deadlock when write operation against an ashmem fd executed at the time when ashmem is shrinking its cache results in the following lock sequence: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); kswapd takes fs_reclaim and then inode_lock while generic_perform_write takes inode_lock and then fs_reclaim. However ashmem does not support writing into backing shmem with a write syscall. The only way to change its content is to mmap it and operate on mapped memory. Therefore the race that lockdep is warning about is not valid. Resolve this by introducing a separate lockdep class for the backing shmem inodes. [1]: https://lkml.kernel.org/lkml/[email protected]/ Reported-by: [email protected] Signed-off-by: Suren Baghdasaryan <[email protected]> Cc: stable <[email protected]> Reviewed-by: Joel Fernandes (Google) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'scripts/gcc-plugins/cyc_complexity_plugin.c')
0 files changed, 0 insertions, 0 deletions