From patchwork Tue Jun 10 21:38:49 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 4332391 Return-Path: X-Original-To: patchwork-linux-sparse@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id BD83CBEEAA for ; Tue, 10 Jun 2014 21:39:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E37C02028D for ; Tue, 10 Jun 2014 21:39:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ABE2020274 for ; Tue, 10 Jun 2014 21:39:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753343AbaFJVjB (ORCPT ); Tue, 10 Jun 2014 17:39:01 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:50347 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753119AbaFJVjB (ORCPT ); Tue, 10 Jun 2014 17:39:01 -0400 Received: by mail-ig0-f176.google.com with SMTP id a13so5666428igq.15 for ; Tue, 10 Jun 2014 14:39:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=E5CUasSiMSPHTe4sQ7VWYtogg8J0WjYn7zSdjJymlKI=; b=YgKq4hMCU31gNM8sNRp1Fn5ZGyInyfKYiXzGRAfP0XYkjcXLIxeWNeN6OX0KAj/KUQ 9fJ5uwnAZr7oeTySfBZtKUqOZEd81Zrb52QXtwuPrRk8jjYt3X7yB6uVtY5OYduT1MkP VePOI0lzD3YmLYqZKDE9MP01D2j9DVRNWE9tA1oe4fhmffDk4HXhS/Gwn7rIl7QuPY3Z KHZgBV0OzTkkic5tuzrYaBFAWaQjwi2eIaw6Pi1NxjXwxka5e72qgfRGuVGb7MF5JtY3 DR4vMcFn5rXP/gmsd210BvqPUUEQbWOAyPuhJVDw9KJ/tDS/bcmx591aUpcsbydyXqZY Z2Xw== X-Gm-Message-State: ALoCoQkPNoLgPm+9Qj+fnsM9kTLa2riN3pWn9Z3er+3upppiYm2Stjh79rI1hkDwO5uRtnDFK9qJ X-Received: by 10.43.138.8 with SMTP id iq8mr42163568icc.37.1402436340535; Tue, 10 Jun 2014 14:39:00 -0700 (PDT) Received: from f20.localdomain (c-71-205-30-39.hsd1.mi.comcast.net. [71.205.30.39]) by mx.google.com with ESMTPSA id t18sm68220549igr.18.2014.06.10.14.38.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jun 2014 14:38:59 -0700 (PDT) From: Jeff Layton To: linux-kernel@vger.kernel.org Cc: dan.carpenter@oracle.com, linux-sparse@vger.kernel.org, Jeff Layton Subject: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression Date: Tue, 10 Jun 2014 17:38:49 -0400 Message-Id: <1402436329-24750-1-git-send-email-jlayton@poochiereds.net> X-Mailer: git-send-email 1.9.3 Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Jeff Layton Lately, when I do a make with C=1, I get *tons* of these warnings: include/linux/err.h:35:16: warning: dereference of noderef expression include/linux/err.h:30:23: warning: dereference of noderef expression ...so many that it's really driven down the signal to noise ratio. I've taken a look at what's driving these warnings and I really just don't get it. The pointers being passed in aren't being dereferenced as far as I can tell, so what is sparse complaining about? Even odder, just in playing around I've noticed that removing the __force directives seems to silence these warnings. This is really strange since all of the docs I see indicate that __force is supposed to help silence sparse warnings, not cause them. This patch just removes the __force directives on the err.h inlines and that silences the warnings for me. Dan originally added those in commit e7152b97f38f1 (err.h: IS_ERR() can accept __user pointers). I don't really consider this a serious proposal for inclusion, but rather just a starting point for discussion. What's the right way to fix this problem? Is this a bug in sparse? Signed-off-by: Jeff Layton --- include/linux/err.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/err.h b/include/linux/err.h index a729120644d5..284897f403b3 100644 --- a/include/linux/err.h +++ b/include/linux/err.h @@ -25,17 +25,17 @@ static inline void * __must_check ERR_PTR(long error) return (void *) error; } -static inline long __must_check PTR_ERR(__force const void *ptr) +static inline long __must_check PTR_ERR(const void *ptr) { return (long) ptr; } -static inline bool __must_check IS_ERR(__force const void *ptr) +static inline bool __must_check IS_ERR(const void *ptr) { return IS_ERR_VALUE((unsigned long)ptr); } -static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr) +static inline bool __must_check IS_ERR_OR_NULL(const void *ptr) { return !ptr || IS_ERR_VALUE((unsigned long)ptr); } @@ -47,13 +47,13 @@ static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr) * Explicitly cast an error-valued pointer to another pointer type in such a * way as to make it clear that's what's going on. */ -static inline void * __must_check ERR_CAST(__force const void *ptr) +static inline void * __must_check ERR_CAST(const void *ptr) { /* cast away the const */ return (void *) ptr; } -static inline int __must_check PTR_ERR_OR_ZERO(__force const void *ptr) +static inline int __must_check PTR_ERR_OR_ZERO(const void *ptr) { if (IS_ERR(ptr)) return PTR_ERR(ptr);