linux.git/drivers/staging/android/ashmem.c, branch v5.13

driver: staging: count ashmem_range into SLAB_RECLAIMBLE

2020-12-28T14:06:06+00:00

Add SLAB_RECLAIM_ACCOUNT to ashmem_range cache since it has registered
shrinker, which make memAvailable more presiced.

Acked-by: Todd Kjos 
Signed-off-by: Zhaoyang Huang 
Link: https://lore.kernel.org/r/1608277668-3740-1-git-send-email-huangzhaoyang@gmail.com
Signed-off-by: Greg Kroah-Hartman

mm: introduce vma_set_file function v5

2020-11-19T09:36:36+00:00

Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.

v2: add more users of this.
v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup,
    add comments why we drop the reference on two occasions.
v4: make it clear that changing an anonymous vma is illegal.
v5: move vma_set_file to mm/util.c

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter  (v2)
Reviewed-by: Jason Gunthorpe 
Acked-by: Andrew Morton 
Link: https://patchwork.freedesktop.org/patch/399360/

Revert "mm: introduce vma_set_file function v4"

2020-11-05T16:08:43+00:00

The kernel test robot is not happy with that.

This reverts commit 2b5b95b1ff3d70a95013a45e3b5b90f1daf42348.

Signed-off-by: Christian König 
Acked-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/394773/

mm: introduce vma_set_file function v4

2020-11-05T12:03:52+00:00

Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.

v2: add more users of this.
v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup,
    add comments why we drop the reference on two occasions.
v4: make it clear that changing an anonymous vma is illegal.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter  (v2)
Reviewed-by: Jason Gunthorpe 
Link: https://patchwork.freedesktop.org/patch/394773/

staging: android: ashmem: Fix lockdep warning for write operation

2020-07-31T12:41:43+00:00

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/0000000000000b5f9d059aa2037f@google.com/

Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com
Signed-off-by: Suren Baghdasaryan 
Cc: stable 
Reviewed-by: Joel Fernandes (Google) 
Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com
Signed-off-by: Greg Kroah-Hartman

mmap locking API: convert mmap_sem comments

2020-06-09T16:39:14+00:00

Convert comments that reference mmap_sem to reference mmap_lock instead.

[akpm@linux-foundation.org: fix up linux-next leftovers]
[akpm@linux-foundation.org: s/lockaphore/lock/, per Vlastimil]
[akpm@linux-foundation.org: more linux-next fixups, per Michel]

Signed-off-by: Michel Lespinasse 
Signed-off-by: Andrew Morton 
Reviewed-by: Vlastimil Babka 
Reviewed-by: Daniel Jordan 
Cc: Davidlohr Bueso 
Cc: David Rientjes 
Cc: Hugh Dickins 
Cc: Jason Gunthorpe 
Cc: Jerome Glisse 
Cc: John Hubbard 
Cc: Laurent Dufour 
Cc: Liam Howlett 
Cc: Matthew Wilcox 
Cc: Peter Zijlstra 
Cc: Ying Han 
Link: http://lkml.kernel.org/r/20200520052908.204642-13-walken@google.com
Signed-off-by: Linus Torvalds

staging: android: ashmem: Disallow ashmem memory from being remapped

2020-02-10T16:49:11+00:00

When ashmem file is mmapped, the resulting vma->vm_file points to the
backing shmem file with the generic fops that do not check ashmem
permissions like fops of ashmem do. If an mremap is done on the ashmem
region, then the permission checks will be skipped. Fix that by disallowing
mapping operation on the backing shmem file.

Reported-by: Jann Horn 
Signed-off-by: Suren Baghdasaryan 
Cc: stable  # 4.4,4.9,4.14,4.18,5.4
Signed-off-by: Todd Kjos 
Reviewed-by: Joel Fernandes (Google) 
Link: https://lore.kernel.org/r/20200127235616.48920-1-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Replace strcpy with strscpy

2020-01-14T15:17:11+00:00

Replaced strcpy call with safer strscpy call with given length.
This elimates the need to manually null-terminate the given string,
since strscpy will null terminate the destination anyway.:

Signed-off-by: Ole Wiedemann 
Co-developed-by: Sebastian Scherbel 
Signed-off-by: Sebastian Scherbel 
Acked-by: Christian Brauner 
Acked-by: Joel Fernandes (Google) 
Acked-by: Todd Kjos 
Link: https://lore.kernel.org/r/20191213131032.22579-1-ole.wiedemann@fau.de
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Avoid range_alloc() allocation with ashmem_mutex held.

2019-02-26T10:50:17+00:00

ashmem_pin() is calling range_shrink() without checking whether
range_alloc() succeeded. Also, doing memory allocation with ashmem_mutex
held should be avoided because ashmem_shrink_scan() tries to hold it.

Therefore, move memory allocation for range_alloc() to ashmem_pin_unpin()
and make range_alloc() not to fail.

This patch is mostly meant for backporting purpose for fuzz testing on
stable/distributor kernels, for there is a plan to remove this code in
near future.

Signed-off-by: Tetsuo Handa 
Cc: stable@vger.kernel.org
Reviewed-by: Joel Fernandes 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Don't call fallocate() with ashmem_mutex held.

2019-02-19T10:28:43+00:00

syzbot is hitting lockdep warnings [1][2][3]. This patch tries to fix
the warning by eliminating ashmem_shrink_scan() => {shmem|vfs}_fallocate()
sequence.

[1] https://syzkaller.appspot.com/bug?id=87c399f6fa6955006080b24142e2ce7680295ad4
[2] https://syzkaller.appspot.com/bug?id=7ebea492de7521048355fc84210220e1038a7908
[3] https://syzkaller.appspot.com/bug?id=e02419c12131c24e2a957ea050c2ab6dcbbc3270

Reported-by: syzbot 
Reported-by: syzbot 
Reported-by: syzbot 
Signed-off-by: Tetsuo Handa 
Cc: stable@vger.kernel.org
Acked-by: Joel Fernandes (Google) 
Signed-off-by: Greg Kroah-Hartman