diff options
author | Ralph Campbell <rcampbell@nvidia.com> | 2018-01-31 16:20:30 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2018-01-31 17:18:40 -0800 |
commit | 8d63e4cd62b2583c7efe64f2ede406b3f44983f6 (patch) | |
tree | 9db2787ac3a37bd5ab9f08c5020158a8fc02d1b6 | |
parent | def9b71ee651a6fee93a10734b94f93a69cdb2d4 (diff) | |
download | linux-stable-8d63e4cd62b2583c7efe64f2ede406b3f44983f6.tar.gz linux-stable-8d63e4cd62b2583c7efe64f2ede406b3f44983f6.tar.bz2 linux-stable-8d63e4cd62b2583c7efe64f2ede406b3f44983f6.zip |
mm/hmm: fix uninitialized use of 'entry' in hmm_vma_walk_pmd()
The variable 'entry' is used before being initialized in
hmm_vma_walk_pmd().
No bad effect (beside performance hit) so !non_swap_entry(0) evaluate to
true which trigger a fault as if CPU was trying to access migrated
memory and migrate memory back from device memory to regular memory.
This function (hmm_vma_walk_pmd()) is called when a device driver tries
to populate its own page table. For migrated memory it should not
happen as the device driver should already have populated its page table
correctly during the migration.
Only case I can think of is multi-GPU where a second GPU triggers
migration back to regular memory. Again this would just result in a
performance hit, nothing bad would happen.
Link: http://lkml.kernel.org/r/20180122185759.26286-1-jglisse@redhat.com
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-rw-r--r-- | mm/hmm.c | 4 |
1 files changed, 1 insertions, 3 deletions
@@ -418,7 +418,7 @@ again: } if (!pte_present(pte)) { - swp_entry_t entry; + swp_entry_t entry = pte_to_swp_entry(pte); if (!non_swap_entry(entry)) { if (hmm_vma_walk->fault) @@ -426,8 +426,6 @@ again: continue; } - entry = pte_to_swp_entry(pte); - /* * This is a special swap entry, ignore migration, use * device and report anything else as error. |