Thanks you for taking the time to respond. I think I will look at providing kmm_strdup and submit a PR with the fix. It will probably be safer to do this and reduce the possibly of disturbing existing code with changes to the definition of free.
Regards, Mark _____________________________ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 21 Sep 2022, at 17:24, Gregory Nutt <spudan...@gmail.com> wrote: > > This does not seem like a technical issue but rather awkward usage/naming > that is prone to misuse. > > Yes, free() should be called to release the memory allocated by strdup. But > applications cannot use the kernel heap and, for reasons of protection, the > kernel should not store anything in the user-accessible application heap in > Protected mode. In Kernel mode, the application heap may not even be > available to OS without switching the address environment. > > So I think that a clean solution would be to fix the naming, either: (1) > rename the stdup used by the OS to kmm_strdup() with allocated memory freed > by kmm_free(), or (2) conditionally redefine free() to be kmm_free() in the > kernel portion of the build. > > kmm_free() is already defined as free() in the FLAT build in > include/nuttx/kmalloc.h > > On 9/21/2022 9:59 AM, Mark Stevens wrote: >> So this post has been triggered by an issue I have just had using strdup in >> the OS components of a protected mode build. >> >> For clarity I will be using the term OS for the kernel part of the build and >> application/app for the user part of the build. >> >> The TLDR; is this design question: >> >> Do we expect malloc and free to work with the relevant heaps? So for the OS >> should they be working with the kernel heap and for apps they should be >> using the user heap? >> >> I am trying to work out if the problem is with strdup or with malloc & free. >> >> >> Investigation / background >> >> My understanding of strdup is that any string generated should have its >> memory released using free, at least that is the way I have been using it >> for years. >> >> The system under development uses a protected/kernel build with a memory >> protection unit. We also have two heaps, one for the OS and one for the app. >> >> At some point in the OS lifecycle we have the need to generate copies of >> strings. These were generated using strdup. At some point in the future >> these strings were released using free. At a point further in the future >> the system crashed. >> >> After some tracking it turns out that strdup was allocating memory using the >> kernel heap (the strings were duplicated in the OS) and then freed in the OS >> but the memory was being released to the user (Application) heap. When this >> was then later allocated and used in user space the system would crash with >> a memory fault. >> >> Investigation points to the fact that strdup uses lib_malloc which will call >> kmm_malloc in OS builds and malloc in app builds. >> >> It also appears that malloc and free always work with the user heap. >> >> I know that our build is a little old but looking at the sources this seems >> to be the case with the current release. I am struggling to get the >> protected build working on a F767 board to verify if the problem is still >> present. >> >> Regards, >> Mark >> _____________________________ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >
