On 4/29/22 2:15 PM, Ammar Faizi wrote: > On Sat, Apr 30, 2022 at 1:21 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >> On 4/28/22 6:46 PM, Ammar Faizi wrote: >>> From: Ammar Faizi <ammarfaizi2@xxxxxxxxxxx> >>> >>> Hi Jens, >>> >>> This series contains patches that were dropped from my previous thread: >>> >>> https://lore.kernel.org/fio/20220428203954.222165-1-ammarfaizi2@xxxxxxxxxxx >>> >>> Plus, I have more patches in this series. This series contains error >>> handling fixes, mostly about ENOMEM. There are 8 patches in this >>> series. All of them are ENOMEM handling stuff except that patch #4 has >>> extra fixes and a bit of refactoring. >> >> While I agree on good error handling in general, I'm a bit dubious at >> malloc() related NULL returns. Have you ever seen malloc() return NULL? >> On Linux, or somewhere else? Most systems overcommit themselves to >> death, and things will death spiral before you ever get NULL. > > Yes, you're right. malloc() returns NULL is a very rare case. I don't > think fio users will ever see that in general. > > I have seen malloc() return NULL when a program is in jail (e.g. > inside cgroup, or whatever that puts a limit on the memory resource). > But obviously, it is not reasonable for fio. Although that's one of my > motivations, it's actually not the main one that brought me to do this > series. > >> I'm happy to be convinced otherwise, just naturally skeptical that >> there's any real value in making changes like this. > > I am a bit bothered seeing inconsistent error handling in the > codebase. From what I see in the fio codebase today, sometimes we > handle ENOMEM cases, sometimes we don't. I want to make it consistent > in the hope we can improve the quality of the overall error handling. Any internal allocator use case must handle errors, but malloc() and friends most likely do not, or at least do so inconsistently I'm sure. > If you are fine with that, I can send more incremental patches for > review in the future to fix those inconsistencies. It may be tiring > and progressive work. But I am okay doing that. > > However, if you NAK this series. I will start fixing other broken > things I can find, like in patch #4 for example. And that's fine. It's not that I'm against cleaning up these bits, my only worry is that it's quite easy to add errors when fixing these things up. And if the choice is between some inconsistency in alloc error handling or potentially adding error that users WILL actually hit, then I'd pick the former any day. I'll leave the decision to you. If you feel they are all trivial and risk of introducing errors it close to zero, then I'm happy to apply them. I just don't have the strongest motivation myself for doing thorough reviews of it, just don't have time to do so. -- Jens Axboe
