On 05/06/2018 09:00 PM, Rosen Penev wrote: > On Sun, May 6, 2018 at 10:08 AM, Rosen Penev <ros...@gmail.com> wrote: >> On Sun, May 6, 2018 at 3:52 AM, Daniel Danzberger <dan...@dd-wrt.com> wrote: >>> MMAP'ed memory that has been allocated via 'get_zeroed_page(GFP_KERNEL)' or >>> 'vmalloc()' doesn't always contain the same data when accessed from >>> userspace. >>> >>> This means all userspace programs using mmap to access kernel memory aren't >>> always working properly on the Rambutan board. I am currently testing if >>> other >>> ar71xx devices are affected as well. >>> >>> I first noticed this when using ALSA's mmap api to capture audio. >>> >>> Here is the feed for a kmod + userpace util to reproduce the issue: >>> g...@github.com:dddaniel/mmaptest.git >>> >>> The kernel module simply allocates a page and initializes it with 0xff. >>> The userspace application then mmap's and reads this page 10 times with a >>> 500ms >>> delay an checks if all data is 0xff. >>> >>> --- >>> root@OpenWrt:/# mmaptest-user >>> mmap addr: 0x77a04000 >>> [ 760.464968] mmap page 7573000 at va 87573000 >>> check memory ...FAIL (at byte 0) >>> check memory ...FAIL (at byte 96) >>> check memory ...FAIL (at byte 96) >>> check memory ...FAIL (at byte 96) >>> check memory ...FAIL (at byte 128) >>> --- >>> >>> I have no idea whats causing it. Does anybody have a hint on how to fix >>> this ? >>> >> Try reverting >> https://github.com/torvalds/linux/commit/c00ab4896ed5f7d89af6f90b809e2c0197c6d170 > Disregard that. That commit should have no impact. > > I just tested it on an Archer C7v4 and the issue is present as well. > This was probably causing data corruption for me when I used an > external hard drive... > > Strange that sometimes it works and sometimes not.Yes, the same in my tests. > Look's like this issue appears on all ar71xx devices. > > Did you encounter this issue with kernel 4.9? For me, 4.4 caused no > data corruption on my external hard drive. I can't tell right now. I was trying to use an older version with kernel 4.4, but it fails to build. > > There seems to be a pattern with kernel 4.9 breaking various MIPS devices...
>>> -- >>> Regards >>> >>> Daniel Danzberger >>> embeDD GmbH, Alter Postplatz 2, CH-6370 Stans >>> >>> _______________________________________________ >>> Lede-dev mailing list >>> Lede-dev@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/lede-dev > -- Regards Daniel Danzberger embeDD GmbH, Alter Postplatz 2, CH-6370 Stans _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
