> On 9 May 2018, at 11:27, Daniel Danzberger wrote:
>
> On 05/
>>
>>
>> So that smells more of a race condition between the writer filling with 0xFF
>> and the reader catching up.
> The open() syscall does the memset(0xff) and blocks. This ensures the memory
> is
>
On 05/08/2018 10:33 PM, Kevin Darbyshire-Bryant wrote:
>
>
>> On 8 May 2018, at 21:11, Rosen Penev wrote:
>>
>>>
>>> So out of curiosity I built this for my Archer C7 v2 ar71xx device. I also
>>> modified the code to not give up on ‘OK’, so it always iterated 10 times.
>>>
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> On 8 May 2018, at 21:11,
<ke...@darbyshire-bryant.me.uk>
>> To: Daniel Danzberger <dan...@dd-wrt.com>
>> Cc: Rosen Penev <ros...@gmail.com>, "lede-dev@lists.infradead.org"
>> <lede-dev@lists.infradead.org>
>> Bcc:
>> Date: Tue, 8 May 2018 20:07:56 +
>>
os...@gmail.com>, "lede-dev@lists.infradead.org"
> <lede-dev@lists.infradead.org>
> Bcc:
> Date: Tue, 8 May 2018 20:07:56 +
> Subject: Re: [LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices)
> board.
>
>
>> On 8 May 2018, at 11:16, Daniel
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> On 8 May 2018, at 11:16,
On 05/07/2018 01:16 PM, Daniel Danzberger wrote:
> On 05/06/2018 09:00 PM, Rosen Penev wrote:
>> On Sun, May 6, 2018 at 10:08 AM, Rosen Penev wrote:
>>> On Sun, May 6, 2018 at 3:52 AM, Daniel Danzberger wrote:
MMAP'ed memory that has been allocated via
On 05/06/2018 09:00 PM, Rosen Penev wrote:
> On Sun, May 6, 2018 at 10:08 AM, Rosen Penev wrote:
>> On Sun, May 6, 2018 at 3:52 AM, Daniel Danzberger wrote:
>>> MMAP'ed memory that has been allocated via 'get_zeroed_page(GFP_KERNEL)' or
>>> 'vmalloc()'
On Sun, May 6, 2018 at 3:52 AM, Daniel Danzberger 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