diff for duplicates of <979dd0561001251701y76f35b8as545c390135b34da2@mail.gmail.com> diff --git a/a/1.txt b/N1/1.txt index e714e63..5e145fb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -8,31 +8,31 @@ On Tue, Jan 26, 2010 at 3:58 AM, Andrew Morton >> > The cache alias problem will happen if the changes of user shared mapping >> > is not flushed before copying, then user and kernel mapping may be mapped >> > into two different cache line, it is impossible to guarantee the coherence ->> > after iov_iter_copy_from_user_atomic. ?So the right steps should be: ->> > ? ? flush_dcache_page(page); ->> > ? ? kmap_atomic(page); ->> > ? ? write to page; ->> > ? ? kunmap_atomic(page); ->> > ? ? flush_dcache_page(page); +>> > after iov_iter_copy_from_user_atomic. So the right steps should be: +>> > flush_dcache_page(page); +>> > kmap_atomic(page); +>> > write to page; +>> > kunmap_atomic(page); +>> > flush_dcache_page(page); >> > More precisely, we might create two new APIs flush_dcache_user_page and >> > flush_dcache_kern_page to replace the two flush_dcache_page accordingly. >> > >> > Here is a snippet tested on omap2430 with VIPT cache, and I think it is >> > not ARM-specific: ->> > ? ? int val = 0x11111111; ->> > ? ? fd = open("abc", O_RDWR); ->> > ? ? addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); ->> > ? ? *(addr+0) = 0x44444444; ->> > ? ? tmp = *(addr+0); ->> > ? ? *(addr+1) = 0x77777777; ->> > ? ? write(fd, &val, sizeof(int)); ->> > ? ? close(fd); +>> > int val = 0x11111111; +>> > fd = open("abc", O_RDWR); +>> > addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); +>> > *(addr+0) = 0x44444444; +>> > tmp = *(addr+0); +>> > *(addr+1) = 0x77777777; +>> > write(fd, &val, sizeof(int)); +>> > close(fd); >> > The results are not always 0x11111111 0x77777777 at the beginning as expected. >> > >> Is this a real bug or not necessary to support? > -> Bug. ?If variable `addr' has type int* then the contents of that file -> should be 0x11111111 0x77777777. ?You didn't tell us what the contents +> Bug. If variable `addr' has type int* then the contents of that file +> should be 0x11111111 0x77777777. You didn't tell us what the contents > were in the incorrect case, but I guess it doesn't matter. > Sorry, I didn't give the details, here is the old thread with more details: diff --git a/a/content_digest b/N1/content_digest index 2fdb86d..fa74c41 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,10 +1,16 @@ "ref\0979dd0561001202107v4ddc1eb7xa59a7c16c452f7a2@mail.gmail.com\0" "ref\020100125133308.GA26799@desktop\0" "ref\020100125115814.156d401d.akpm@linux-foundation.org\0" - "From\0anfei.zhou@gmail.com (anfei zhou)\0" - "Subject\0[PATCH] Flush dcache before writing into page to avoid alias\0" + "From\0anfei zhou <anfei.zhou@gmail.com>\0" + "Subject\0Re: [PATCH] Flush dcache before writing into page to avoid alias\0" "Date\0Tue, 26 Jan 2010 09:01:10 +0800\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Andrew Morton <akpm@linux-foundation.org>\0" + "Cc\0linux-mm@kvack.org" + linux-kernel@vger.kernel.org + KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> + linux@arm.linux.org.uk + Jamie Lokier <jamie@shareable.org> + " linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Tue, Jan 26, 2010 at 3:58 AM, Andrew Morton\n" @@ -17,31 +23,31 @@ ">> > The cache alias problem will happen if the changes of user shared mapping\n" ">> > is not flushed before copying, then user and kernel mapping may be mapped\n" ">> > into two different cache line, it is impossible to guarantee the coherence\n" - ">> > after iov_iter_copy_from_user_atomic. ?So the right steps should be:\n" - ">> > ? ? flush_dcache_page(page);\n" - ">> > ? ? kmap_atomic(page);\n" - ">> > ? ? write to page;\n" - ">> > ? ? kunmap_atomic(page);\n" - ">> > ? ? flush_dcache_page(page);\n" + ">> > after iov_iter_copy_from_user_atomic. \302\240So the right steps should be:\n" + ">> > \302\240 \302\240 flush_dcache_page(page);\n" + ">> > \302\240 \302\240 kmap_atomic(page);\n" + ">> > \302\240 \302\240 write to page;\n" + ">> > \302\240 \302\240 kunmap_atomic(page);\n" + ">> > \302\240 \302\240 flush_dcache_page(page);\n" ">> > More precisely, we might create two new APIs flush_dcache_user_page and\n" ">> > flush_dcache_kern_page to replace the two flush_dcache_page accordingly.\n" ">> >\n" ">> > Here is a snippet tested on omap2430 with VIPT cache, and I think it is\n" ">> > not ARM-specific:\n" - ">> > ? ? int val = 0x11111111;\n" - ">> > ? ? fd = open(\"abc\", O_RDWR);\n" - ">> > ? ? addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);\n" - ">> > ? ? *(addr+0) = 0x44444444;\n" - ">> > ? ? tmp = *(addr+0);\n" - ">> > ? ? *(addr+1) = 0x77777777;\n" - ">> > ? ? write(fd, &val, sizeof(int));\n" - ">> > ? ? close(fd);\n" + ">> > \302\240 \302\240 int val = 0x11111111;\n" + ">> > \302\240 \302\240 fd = open(\"abc\", O_RDWR);\n" + ">> > \302\240 \302\240 addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);\n" + ">> > \302\240 \302\240 *(addr+0) = 0x44444444;\n" + ">> > \302\240 \302\240 tmp = *(addr+0);\n" + ">> > \302\240 \302\240 *(addr+1) = 0x77777777;\n" + ">> > \302\240 \302\240 write(fd, &val, sizeof(int));\n" + ">> > \302\240 \302\240 close(fd);\n" ">> > The results are not always 0x11111111 0x77777777 at the beginning as expected.\n" ">> >\n" ">> Is this a real bug or not necessary to support?\n" ">\n" - "> Bug. ?If variable `addr' has type int* then the contents of that file\n" - "> should be 0x11111111 0x77777777. ?You didn't tell us what the contents\n" + "> Bug. \302\240If variable `addr' has type int* then the contents of that file\n" + "> should be 0x11111111 0x77777777. \302\240You didn't tell us what the contents\n" "> were in the incorrect case, but I guess it doesn't matter.\n" ">\n" "Sorry, I didn't give the details, here is the old thread with more details:\n" @@ -52,4 +58,4 @@ ">\n" > -694503267f78427939ba16a79c6b4bae3f8b39e88f45cc31f341f0ea77c4d501 +5b4c15b1d23257894f5ef2e88676206797a985dc525b3500be8c4046b1b5431f
diff --git a/a/1.txt b/N2/1.txt index e714e63..b54c2f1 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -8,31 +8,31 @@ On Tue, Jan 26, 2010 at 3:58 AM, Andrew Morton >> > The cache alias problem will happen if the changes of user shared mapping >> > is not flushed before copying, then user and kernel mapping may be mapped >> > into two different cache line, it is impossible to guarantee the coherence ->> > after iov_iter_copy_from_user_atomic. ?So the right steps should be: ->> > ? ? flush_dcache_page(page); ->> > ? ? kmap_atomic(page); ->> > ? ? write to page; ->> > ? ? kunmap_atomic(page); ->> > ? ? flush_dcache_page(page); +>> > after iov_iter_copy_from_user_atomic. So the right steps should be: +>> > flush_dcache_page(page); +>> > kmap_atomic(page); +>> > write to page; +>> > kunmap_atomic(page); +>> > flush_dcache_page(page); >> > More precisely, we might create two new APIs flush_dcache_user_page and >> > flush_dcache_kern_page to replace the two flush_dcache_page accordingly. >> > >> > Here is a snippet tested on omap2430 with VIPT cache, and I think it is >> > not ARM-specific: ->> > ? ? int val = 0x11111111; ->> > ? ? fd = open("abc", O_RDWR); ->> > ? ? addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); ->> > ? ? *(addr+0) = 0x44444444; ->> > ? ? tmp = *(addr+0); ->> > ? ? *(addr+1) = 0x77777777; ->> > ? ? write(fd, &val, sizeof(int)); ->> > ? ? close(fd); +>> > int val = 0x11111111; +>> > fd = open("abc", O_RDWR); +>> > addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); +>> > *(addr+0) = 0x44444444; +>> > tmp = *(addr+0); +>> > *(addr+1) = 0x77777777; +>> > write(fd, &val, sizeof(int)); +>> > close(fd); >> > The results are not always 0x11111111 0x77777777 at the beginning as expected. >> > >> Is this a real bug or not necessary to support? > -> Bug. ?If variable `addr' has type int* then the contents of that file -> should be 0x11111111 0x77777777. ?You didn't tell us what the contents +> Bug. If variable `addr' has type int* then the contents of that file +> should be 0x11111111 0x77777777. You didn't tell us what the contents > were in the incorrect case, but I guess it doesn't matter. > Sorry, I didn't give the details, here is the old thread with more details: @@ -42,3 +42,9 @@ Regards, Anfei. > > + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N2/content_digest index 2fdb86d..3c6ee2a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,10 +1,16 @@ "ref\0979dd0561001202107v4ddc1eb7xa59a7c16c452f7a2@mail.gmail.com\0" "ref\020100125133308.GA26799@desktop\0" "ref\020100125115814.156d401d.akpm@linux-foundation.org\0" - "From\0anfei.zhou@gmail.com (anfei zhou)\0" - "Subject\0[PATCH] Flush dcache before writing into page to avoid alias\0" + "From\0anfei zhou <anfei.zhou@gmail.com>\0" + "Subject\0Re: [PATCH] Flush dcache before writing into page to avoid alias\0" "Date\0Tue, 26 Jan 2010 09:01:10 +0800\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Andrew Morton <akpm@linux-foundation.org>\0" + "Cc\0linux-mm@kvack.org" + linux-kernel@vger.kernel.org + KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> + linux@arm.linux.org.uk + Jamie Lokier <jamie@shareable.org> + " linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Tue, Jan 26, 2010 at 3:58 AM, Andrew Morton\n" @@ -17,31 +23,31 @@ ">> > The cache alias problem will happen if the changes of user shared mapping\n" ">> > is not flushed before copying, then user and kernel mapping may be mapped\n" ">> > into two different cache line, it is impossible to guarantee the coherence\n" - ">> > after iov_iter_copy_from_user_atomic. ?So the right steps should be:\n" - ">> > ? ? flush_dcache_page(page);\n" - ">> > ? ? kmap_atomic(page);\n" - ">> > ? ? write to page;\n" - ">> > ? ? kunmap_atomic(page);\n" - ">> > ? ? flush_dcache_page(page);\n" + ">> > after iov_iter_copy_from_user_atomic. \302\240So the right steps should be:\n" + ">> > \302\240 \302\240 flush_dcache_page(page);\n" + ">> > \302\240 \302\240 kmap_atomic(page);\n" + ">> > \302\240 \302\240 write to page;\n" + ">> > \302\240 \302\240 kunmap_atomic(page);\n" + ">> > \302\240 \302\240 flush_dcache_page(page);\n" ">> > More precisely, we might create two new APIs flush_dcache_user_page and\n" ">> > flush_dcache_kern_page to replace the two flush_dcache_page accordingly.\n" ">> >\n" ">> > Here is a snippet tested on omap2430 with VIPT cache, and I think it is\n" ">> > not ARM-specific:\n" - ">> > ? ? int val = 0x11111111;\n" - ">> > ? ? fd = open(\"abc\", O_RDWR);\n" - ">> > ? ? addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);\n" - ">> > ? ? *(addr+0) = 0x44444444;\n" - ">> > ? ? tmp = *(addr+0);\n" - ">> > ? ? *(addr+1) = 0x77777777;\n" - ">> > ? ? write(fd, &val, sizeof(int));\n" - ">> > ? ? close(fd);\n" + ">> > \302\240 \302\240 int val = 0x11111111;\n" + ">> > \302\240 \302\240 fd = open(\"abc\", O_RDWR);\n" + ">> > \302\240 \302\240 addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);\n" + ">> > \302\240 \302\240 *(addr+0) = 0x44444444;\n" + ">> > \302\240 \302\240 tmp = *(addr+0);\n" + ">> > \302\240 \302\240 *(addr+1) = 0x77777777;\n" + ">> > \302\240 \302\240 write(fd, &val, sizeof(int));\n" + ">> > \302\240 \302\240 close(fd);\n" ">> > The results are not always 0x11111111 0x77777777 at the beginning as expected.\n" ">> >\n" ">> Is this a real bug or not necessary to support?\n" ">\n" - "> Bug. ?If variable `addr' has type int* then the contents of that file\n" - "> should be 0x11111111 0x77777777. ?You didn't tell us what the contents\n" + "> Bug. \302\240If variable `addr' has type int* then the contents of that file\n" + "> should be 0x11111111 0x77777777. \302\240You didn't tell us what the contents\n" "> were in the incorrect case, but I guess it doesn't matter.\n" ">\n" "Sorry, I didn't give the details, here is the old thread with more details:\n" @@ -50,6 +56,12 @@ "Regards,\n" "Anfei.\n" ">\n" - > + ">\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -694503267f78427939ba16a79c6b4bae3f8b39e88f45cc31f341f0ea77c4d501 +ea9e6c274246c7f906398bef57ee3daeb46bcfe6b3a79c61d258d472c3879281
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.