чт, 18 мая 2023 г. в 09:10, Илья Шипицин <chipits...@gmail.com>:
>
>
> чт, 18 мая 2023 г. в 08:47, Gert Doering <g...@greenie.muc.de>:
>
>> Hi,
>>
>> On Wed, May 17, 2023 at 04:43:01PM -0400, Kristof Provost wrote:
>> > Fwiw: I usually don???t bother handling malloc failure in userspace,
>> > because modern systems all overallocate anyway, so the first thing
>> > you know about lack of memory is the out-of-memory killer terminating
>> > you. It???s a policy choice for the project, so I don???t object
>> > to handling it either.
>>
>> In OpenVPN, we do check malloc() returns :-) - and there's cases where
>> it actually hit, like running with too low ulimits and --mlock.
>>
>> If a malloc fail is not recoverable, we have check_malloc_return(p),
>> which will do
>>
>> void
>> out_of_memory(void)
>> {
>> fprintf(stderr, PACKAGE_NAME ": Out of Memory\n");
>> exit(1);
>> }
>> static inline void
>> check_malloc_return(const void *p)
>> {
>> if (!p)
>> {
>> out_of_memory();
>> }
>> }
>>
>> so it depends a bit on the context if "return an error upstream, and
>> wait for the next allocation to fail" or "abort right away" is the best
>> choice. In low level functions, "return error" might lead to a better
>> error message from upstream (or not).
>>
>
> this one is recoverable.
> if malloc fails, dco fails, but openvpn still able to function
>
maybe we should add something like "data channel offload failed due to ..."
>
>
>>
>> gert
>> --
>> "If was one thing all people took for granted, was conviction that if you
>> feed honest figures into a computer, honest figures come out. Never
>> doubted
>> it myself till I met a computer with a sense of humor."
>> Robert A. Heinlein, The Moon is a Harsh
>> Mistress
>>
>> Gert Doering - Munich, Germany
>> g...@greenie.muc.de
>>
>
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
