lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] LWIP_MPU_COMPATIBLE set to 1, but still get memory mana


From: David Lockyer
Subject: Re: [lwip-users] LWIP_MPU_COMPATIBLE set to 1, but still get memory management fault in lwip_select.
Date: Mon, 11 Sep 2017 11:01:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

Hi Joel,

I raised the bug & created the patchset, attached here as well. It's against the STABLE-2_0_0 branch.

BR,

David


On 08/09/17 20:32, Joel Cunningham wrote:
David,

Would you mind opening a bug report at https://savannah.nongnu.org/bugs/?func=additem&group=lwip and attaching the patches so we can do the review there?

Also, it would be preferable to have the changes in a git patchset that can be applied to the repo (easier to review than looking at individual patch files)

Thanks

Joel


On Sep 8, 2017, at 9:50 AM, David Lockyer <address@hidden> wrote:

So something like attached?

I removed my raise/reset macro's.

It appears to work for me, I added a new private pool, not sure if this was what you intended or not.

Let me know what you think.

BR
David

On 07/09/17 19:40, address@hidden wrote:
David Lockyer wrote:
Okay, thank you for the suggestion. Just to be clear are you suggesting modifying lwip_select() to allocate select_cb from a pool & free prior to return?

Via a define, like Joel wrote, yes. This might need a new memp pool though...
We don't have an abstraction for your priviledge raising macro yet, and I'm not sure it's the best solution for everyone using this mode, either.

I will have to investigate the speed impact of this, as I have MEM_LIBC_MALLOC and MAEP_MEM_MALLOC both defined as 1.


Well, you have this pool allocation at some other places already when socket threads communicate with the tcpip thread for asynchronous things.
Having those 2 defines combined with a possibly slow libc malloc() (heap) is probabably not the fastest solution, anyway.

The best thing to get this fixed would be

Simon
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
<src_api_sockets_c.patch><src_include_lwip_opt_h.patch><src_include_lwip_priv_memp_std_h.patch><src_include_lwip_sockets_h.patch>_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

Attachment: mpu_lwip_select.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]