Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1389682pxu; Sat, 5 Dec 2020 14:35:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJy5v8+ojbYxKYv1tFEJM0s929FmdfPDitfCLDHZB/QpoKI5ARqLl62xccTOoj5SZoLlLcXO X-Received: by 2002:a05:6402:1b1e:: with SMTP id by30mr12475095edb.75.1607207723624; Sat, 05 Dec 2020 14:35:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607207723; cv=none; d=google.com; s=arc-20160816; b=0OUJBjhbK2h3Tkrs8pPMhALPDXFci0uMBHHjWYF6NYu/WtiS9uNv2KfehPKxHupV3C anoyGdbp0cADqluRzFZ2RHJi2zV2ADrFqWgLJW3yGizJS/4vZ1qTxTzwClj61ai9k/bh 3SXm9Ox58ZYkrDPd2O2ER44g1A+x7Dfe3De60xzJzufG3yx6Qa0IFYKMgi6zuEKaaqEu hDYPijSeg9g/KsE9INySxbhauvrMnDuSX1NvNy4C4pv6W+yLKid1y6leWhzsqsWevglk dt883TSw3QX2Ii5Hhla6UFPH1I+7ZixLLiw0E7FgorSy8Yw7g/iyf9wfIVWlg/7kGGNG h1vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:dkim-signature:date; bh=LuRKX31HxUkFWu+yMcp1DIlQVDfv6S6t3sahyoEHMic=; b=aHN6gH7p/MQ1zNCvnoDrJzOLq/HZfWbo4jR82/cajAKngrQyZ5c6rNjB0YEgFESyxx v7etT7R8057sz5ISgyeMv4p7dhLOBboK2pYyI0VPuQUAC+ReUOf6c3WnqZ6QDxqiLEwl jU50bAruVEUnrt07Xv6CJ+gFFTRcBMO6qclXxqfLd2GmhuL+CPBEc+6BjykrUfugBLa0 +0wDBx0Grf9FCbzZm35B/giae0UNjqNYB8PhDZMdANxQG9X0uRZcM5/OCTfP56M+mQM/ IZ9BfAM7kmT8Y4PfU2QaBKBI3IorUKbWhRf27JK3hUdI9oE/nFfkCvMkKtfd8+f/xteh Guaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="twsk11/9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b11si5672155edz.485.2020.12.05.14.35.00; Sat, 05 Dec 2020 14:35:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="twsk11/9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726218AbgLEWdc (ORCPT + 99 others); Sat, 5 Dec 2020 17:33:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:59964 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726011AbgLEWdc (ORCPT ); Sat, 5 Dec 2020 17:33:32 -0500 Date: Sat, 5 Dec 2020 14:32:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607207572; bh=YZrn1IlbhlQAWy/qDP82GR67nZ5d803g393MCcPsdm0=; h=From:To:Cc:Subject:From; b=twsk11/9zewfQGMp7lYWqYVhZoy4/KRwjuLf0RSixLZfecN1zel/wVGotAM9CmPey Gk/tTHNkAqEHZMWXL0te3VsBLAs8puHlskNXm0oz5cZAB3gh1D50OSOO7qWAZf3G8C y2b2rA6Imfu+XJsHgwn1pv1par5Vgbx9FVjdQyBUAn3Urxayg252b6BIGETxX0CKX8 PbnvDiP8xtN1KcZ1JFInrWoqiZWgIO0tcEw3b2eXxBCSDIc4QTAwF8i/pUITV1ZiCQ 6sQtKmZ8LaD/QkqtiB/0HWMg4HPdf9pSpZ4uS7Da5trS1WlJ9LUKk/Os2rNZIXRpp/ MWmSzdVfgy1yg== From: Jakub Kicinski To: linux-sparse@vger.kernel.org Cc: linux-kernel@vger.kernel.org, edwin.peer@broadcom.com, Zhang Changzhong Subject: sparse annotation for error types? Message-ID: <20201205143250.2378b9f9@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! Recently we've been getting a steady stream of patches from Changzhong to fix missing assignment to error variables before jumping to error cases. I wonder if for new code it'd make sense to add an annotation for a type which has to be returned non-zero? What I have in mind is the following common flow: int do_a_thing(struct my_obj *obj, int param) { int err; err = first_step(obj, 1); if (err) return err; if (some_check(obj)) { err = -EINVAL; /* need explicit error set! */ goto err_undo_1s; } err = second_step(obj, param); if (err) goto err_undo_1s; err = third_step(obj, 0); if (err) goto err_undo_2s; return 0; err_undo_2s: second_undo(obj); err_undo_1s: first_undo(obj); return err; } The variable err should never be returned when it's equal to 0. So if we annotate it, let's say as: int __nzret err; could sparse then warn if we forgot to assign it after "if (some_check(obj))"? Am I the only one who thinks this would be a good idea?