On Mon, 2025-02-03 at 15:36 +0100, Alejandro Colomar wrote: > Hi Chen, > > On Mon, Feb 03, 2025 at 10:11:14PM +0800, Chen Linxuan wrote: > > > > The memory we mmap here is used as the stack of child process we are > > > > going to create. > > > > Once child process is created, I mean clone(2) return without error, > > > > it's OK to munmap(2) memory, > > > > as the child process has its own memory space, and that memory is not > > > > used in parent process at all. > > > > So, whether the clone(2) is success or not, we both need to call > > > > munmap(2) to release the memory. > > > > > > In case of a clone(2) error, exit(3) (called within err(3)) will release > > > the memory, right? Why do we need an explicit munmap(2) call? > > > > > > > > > > > If we call munmap(2) after the error handling of clone(2), we will > > > > print a error message and then exit > > > > before we free those memory. > > > > > > exit(3) releases all memory, doesn't it? Why would we want to > > > explicitly munmap(2) it before printing the error message? > > > > > > > In the code snippet provided as an example for clone(2), I believe we > > should strive to write example code in a way that avoids potential > > misunderstandings. From the perspective of whether memory is eventually > > released, the original program does not technically cause any memory > > leak since the parent process exits immediately after completing > > clone(2). > > > > However, I think it's necessary to explicitly perform munmap(2) in > > cases where clone(2) fails. The reason is: for readers studying this > > documentation, the error handling approach in their actual code might > > not be as simple as directly exiting the process. In real-world > > scenarios, if the error handling here involves returning error codes > > instead of terminating immediately, handling clone(2) error before > > calling munmap(2) could become misleading. > > I believe reporting the error from munmap(2) if there is one, and > silencing the clone(2) error, would be similarly confusing. I prefer I just notice that call munmap(2) before handling clone(2) error will overwrite errno set by clone(2). > to have the munmap(2) call after the clone(2) error handling. That's > how we do it in most examples. I think it is better to use warn(3) to report munmap(2) error here. I will send another patch. > > But I like proposal to do correct cleanup in the successful path. > > > Cheers, > Alex > > > By explicitly freeing > > resources before error handling, we ensure the example demonstrates > > robust practices that remain valid across different error-handling > > architectures. > > > > > > > Have a lovely day! > > > Alex > > > > > >
