[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)
From: |
Krzysztof Wesołowski |
Subject: |
Re: [lwip-users] lwip and MPU (FreeRTOS-MPU) |
Date: |
Thu, 30 Aug 2012 10:23:58 +0200 |
I would like to add, that in my opinion if LwIP is considered unsafe,
all threads using it should be treated this way.
So for example, you should have tcpip_thread, communication_thread and
app_thread, with safe (queues?) communication comm<->app.
Regards,
Krzysztof Wesołowski,
On Thu, Aug 30, 2012 at 9:51 AM, Simon Goldschmidt <address@hidden> wrote:
> jblackarty wrote:
>> An: Ivan Delamer <address@hidden>, Mailing list for lwIP users
>> <address@hidden>
>> Betreff: Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)
>
>> > Question: is it important for your application thread and the tcpip
>> thread
>> > to be in different protected memory regions? is it possible for that
>> > memory to be accessed by both threads?
>>
>> As I said already, I did it so. I've placed application thread stack
>> in separate memory region and added this region to user
>> memory regions of tcpip thread with read/write access. Thanks to this,
>> I was able to run my tcpip-enabled application.
>>
>> Is it important to avoid this in my application ?
>> [..]
>
> To me, the essence of what you wrote is that the system doesn't run stable.
> That's of course a problem, but it wouldn't run stable with protected
> threads, either. So while I also think that protecting the thread's stacks
> against each other would be a good thing, the lack of this protection doesn't
> seem to be the cause of your problems!
>
>> Please, note that I didn't even talk about such
>> details like that there are chaos is going in whole global
>> memory shared between tasks, and network-enabled part of my
>> application is not adequate anymore.
>
> What kind of chaos in global shared memory are you talking about?
>
>> [..]
>> Nothing can crash kernel, provided that tasks are
>> run in user-mode and each task has no access to other tasks threads.
>> LwIP thread is the only thread which violates this...
>
> "Nothing can crash kernel": this would only hold for a kernel that is
> strictly seperated from tasks stacks and very strictly checks arguments
> passed from threads to kernel functions, wouldn't it? Is FreeRTOS-MPU
> designed like that?
>
> As a summary, lwIP's multithreading design should certainly be improved if
> used in situations like that. However, the fact remains that global memory
> like pbufs is still shared (e.g. between ISR, tcpip_thread and application
> threads), so I don't think you would gain too much security unless protecting
> most pools.
>
> The reason for all this is that lwIP has not been designed for MPU systems.
> It has been designed for very small systems at a time where MPUs were not
> available for systems of that size.
>
>
> Simon
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), Ivan Delamer, 2012/08/29
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), jblackarty, 2012/08/29
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), Simon Goldschmidt, 2012/08/30
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU),
Krzysztof Wesołowski <=
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), Richard Barry, 2012/08/30
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), FreeRTOS Info, 2012/08/30
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), Simon Goldschmidt, 2012/08/30
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), Richard Barry, 2012/08/30
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), Richard Barry, 2012/08/30
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), jblackarty, 2012/08/30
- Re: [lwip-users] lwip and MPU (FreeRTOS-MPU), Simon Goldschmidt, 2012/08/30