X-Git-Url: http://git.monstr.eu/?a=blobdiff_plain;f=mm%2Fmremap.c;h=47c255b60150b3121c5957c302afd0051d27e3c1;hb=1ad77a05cfaed42cba301368350817333ac69b6a;hp=d22629ff8f3c071a62b73e2b6891f3a6fce728c5;hpb=af120709b1fb7227f18653a95c457b36d8a5e4d8;p=linux-2.6-microblaze.git

diff --git a/mm/mremap.c b/mm/mremap.c
index d22629ff8f3c..47c255b60150 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -730,7 +730,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
 	 * So, to avoid such scenario we can pre-compute if the whole
 	 * operation has high chances to success map-wise.
 	 * Worst-scenario case is when both vma's (new_addr and old_addr) get
-	 * split in 3 before unmaping it.
+	 * split in 3 before unmapping it.
 	 * That means 2 more maps (1 for each) to the ones we already hold.
 	 * Check whether current map count plus 2 still leads us to 4 maps below
 	 * the threshold, otherwise return -ENOMEM here to be more safe.