From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by gnuweeb.org (Postfix) with ESMTPS id 62D267E7B3 for ; Fri, 29 Apr 2022 20:37:39 +0000 (UTC) Authentication-Results: gnuweeb.org; dkim=pass (2048-bit key; unprotected) header.d=kernel-dk.20210112.gappssmtp.com header.i=@kernel-dk.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=4+ISdTvZ; dkim-atps=neutral Received: by mail-pj1-f50.google.com with SMTP id p6so8054718pjm.1 for ; Fri, 29 Apr 2022 13:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=NRhhCK3GT/y/Zi1uwzAe7OHKimJk7g4khsv9OjwSjV8=; b=4+ISdTvZwQ/E2dUL1MSKZXF/oQsB7hEGvFWkls8GdG7jKwTqs9X+QHKqzNfRFa2Nu+ Zq7/rDbJX5Q4dlG/wLtjIMaMOxe2+X1PN5myrGlwNJCGB5wDmeB9sz+03C/3LJtjmRd2 XG4/ihZCLIUQbfRJ9ZmhcxyAPcSlCnDANah/ZFC/V6mggNoa+Ykdsz7CJ9l3Cwq1k2LQ 8nECQtJjDEB5j0squC5YEdznUeTtzlKT8KL3XUaOYtDNUzZ07jSqEEOEMyeSx+LYaeIn QBed4flcuHJ5f7fDY8wjjEjf6GmxXirbJoBCU9OL4vWJoVzxdBVJFtSUFEugDfpeGO/z R+Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=NRhhCK3GT/y/Zi1uwzAe7OHKimJk7g4khsv9OjwSjV8=; b=ngiH/47Tdn4CjnQPvP5UtM0LbbsPpXChoZFV9em4m2MwuFCsETE6ODB+YzzFlQEQzZ 42zEOvVzwArdheHdM11Ca5HEtcPEcFmGtOhE8HQPmJllaxyerems4Dq2zuPRb4v/iNnp G7x+jOpWmQYVn39TLnZy5SpUrilJysxLQ2JfW+3H4wiZv6NITARuUHYeRHeDVW89f9Ap zX1ekLZzIkdPTbNTPGZSUfoIIty7w8dEsuHUCKWbWyw45fv9AvirhYhXmWNCzy7HAh98 vEY/pzT4BQW+XPvyg4KRBrIFvS3DcOWy48s6Q8DKhKkwv4llzvx2OQCwO6yKihkYGgxT GGUw== X-Gm-Message-State: AOAM5303tQymL5gPKHr6qUziKPUCpxLmg4PcNotgJ8Erz7PpBkUrpvTy kjowlc3QzdPvxg7YwNmeXQZpKg== X-Google-Smtp-Source: ABdhPJwiImRPALKeiImujoOEjPX7UtnAK2OjTjC4aOXmm2KvNhnTu0Uz/hrf8aR1z6AWLX9K4wnQ0w== X-Received: by 2002:a17:902:c3cb:b0:15c:e5d2:227e with SMTP id j11-20020a170902c3cb00b0015ce5d2227emr1071273plj.13.1651264658468; Fri, 29 Apr 2022 13:37:38 -0700 (PDT) Received: from [192.168.1.100] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id n7-20020a1709026a8700b0015e8d4eb248sm22438plk.146.2022.04.29.13.37.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:37:37 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2022 14:37:36 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v1 0/8] fio error handling fixes Content-Language: en-US To: Ammar Faizi Cc: Alviro Iskandar Setiawan , Niklas Cassel , Vincent Fu , fio Mailing List , GNU/Weeb Mailing List References: <20220429004705.260034-1-ammarfaizi2@gnuweeb.org> <5a686d0d-63e8-33c5-d59b-dad1bceaae4c@kernel.dk> From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: On 4/29/22 2:15 PM, Ammar Faizi wrote: > On Sat, Apr 30, 2022 at 1:21 AM Jens Axboe wrote: >> On 4/28/22 6:46 PM, Ammar Faizi wrote: >>> From: Ammar Faizi >>> >>> Hi Jens, >>> >>> This series contains patches that were dropped from my previous thread: >>> >>> https://lore.kernel.org/fio/20220428203954.222165-1-ammarfaizi2@gnuweeb.org >>> >>> 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