diff options
author | Jason Gunthorpe <jgg@mellanox.com> | 2019-08-06 20:15:39 -0300 |
---|---|---|
committer | Jason Gunthorpe <jgg@mellanox.com> | 2019-08-16 11:44:48 -0300 |
commit | 70df291bf81ffda47ff84e6e2da4fbe21f95a861 (patch) | |
tree | fe19e393dfc9d17b06eb0324999ffc1a90b99f99 /security | |
parent | 56c57103db17db9ecdad0507a3f0e3eea747fabe (diff) | |
download | linux-70df291bf81ffda47ff84e6e2da4fbe21f95a861.tar.bz2 |
mm/mmu_notifiers: do not speculatively allocate a mmu_notifier_mm
A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary")
made an attempt at doing this, but had to be reverted as calling
the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see
commit 35cfa2b0b491 ("mm/mmu_notifier: allocate mmu_notifier in advance").
However, we can avoid that problem by doing the allocation only under
the mmap_sem, which is already happening.
Since all writers to mm->mmu_notifier_mm hold the write side of the
mmap_sem reading it under that sem is deterministic and we can use that to
decide if the allocation path is required, without speculation.
The actual update to mmu_notifier_mm must still be done under the
mm_take_all_locks() to ensure read-side coherency.
Link: https://lore.kernel.org/r/20190806231548.25242-3-jgg@ziepe.ca
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ralph Campbell <rcampbell@nvidia.com>
Tested-by: Ralph Campbell <rcampbell@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions