From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51211C38A30 for ; Sun, 19 Apr 2020 12:04:12 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C4C8121744 for ; Sun, 19 Apr 2020 12:04:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="IsQBphYJ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BQIo366f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4C8121744 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 2215C1663; Sun, 19 Apr 2020 14:03:20 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 2215C1663 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1587297850; bh=x2vOiaCnxxSwfQdLjmqVJM8lbr3nu9ilx4uLADcHgbI=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=IsQBphYJhyEOqaN2zFRqUnqmjGWmH9nZu1/bybZ4TzZdERTdi3sIZTdBnen0wgJ4n A1/P46lGJxIviTLuF2FL3Bj8pfLZ7IxvfHfDUJp4Q2K6BM7Y2EIKgRhMK/ZHq14xhS qP6+nKa0g2FGJy6cmB664zcdEDcxeb+AAp6qisyU= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id B33B9F800E7; Sun, 19 Apr 2020 14:03:19 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id E438FF801EC; Sun, 19 Apr 2020 14:03:17 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id AA23DF800E7 for ; Sun, 19 Apr 2020 14:03:11 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz AA23DF800E7 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BQIo366f" Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EEB2F21841; Sun, 19 Apr 2020 12:03:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587297788; bh=x2vOiaCnxxSwfQdLjmqVJM8lbr3nu9ilx4uLADcHgbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BQIo366fubUyRRR8gy2ghwhRQu0Kwnh4p0dbM2JbxKVFUDW8yZ1SDgiYSl5JqwVeR wZ5SL8Ku8jXAHvkI6SEOWx2BKIwYfUnNkbRnpiO/xRR81S6FYbEAx2Q4OceLmb8Ctn LwJSFTVsq/8XLc3RC94BktgRcZXJ/hdv3QPM50lA= Date: Sun, 19 Apr 2020 14:03:04 +0200 From: Greg Kroah-Hartman To: Linus Torvalds Subject: Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c Message-ID: <20200419120304.GA3668771@kroah.com> References: <20200418184111.13401-1-rdunlap@infradead.org> <20200418184111.13401-8-rdunlap@infradead.org> <20200418185033.GQ5820@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: alsa-devel@alsa-project.org, Randy Dunlap , Rafael Wysocki , Zzy Wysm , Linux Kernel Mailing List , "J. Bruce Fields" , target-devel , Dave Jiang , linux-scsi , linux-nvdimm , Vishal Verma , Matthew Wilcox , Chuck Lever , linux-input@vger.kernel.org, Joe Perches , Alexander Viro , Dan Williams , Andrew Morton , "open list:NFS, SUNRPC, AND..." , "Martin K. Petersen" , Dmitry Torokhov , Takashi Iwai , linux-usb@vger.kernel.org, linux-fsdevel , Johannes Berg X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Sat, Apr 18, 2020 at 12:15:57PM -0700, Linus Torvalds wrote: > On Sat, Apr 18, 2020 at 11:57 AM Joe Perches wrote: > > > > sysfs_create_link is __must_check > > The way to handle __must_check if you really really don't want to test > and have good reasons is > > (a) add a big comment about why this case ostensibly doesn't need the check > > (b) cast a test of it to '(void)' or something (I guess we could add > a helper for this). So something like > > /* We will always clean up, we don't care whether this fails > or succeeds */ > (void)!!sysfs_create_link(...) > > There are other alternatives (like using WARN_ON_ONCE() instead, for > example). So it depends on the code. Which is why that comment is > important to show why the code chose that option. > > However, I wonder if in this case we should just remove the > __must_check. Greg? It goes back a long long time. Yeah, maybe it is time to remove it, the gyrations people go through to remove the warning when they "know" they are doing it right feels pretty bad compared to forcing people to check things for "normal" calls to the function. thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A6C9C38A30 for ; Sun, 19 Apr 2020 12:03:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66AFF21744 for ; Sun, 19 Apr 2020 12:03:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587297790; bh=x2vOiaCnxxSwfQdLjmqVJM8lbr3nu9ilx4uLADcHgbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=McJY9cQOKSQ9uyIhqRE4xWzG8GpEYpaWAAN5l0+S8INVXUIrZMz9rm+APktPzRW9X rhJOs1aVV0y/4KiL/CRdYDsHyQ+PvPFalSYzTh0xEbdtFAc1bZkD6iMpHtoquakq5r UDAP9CX/CDiGVAb9KjypxygEccinW51iMME4y17w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725990AbgDSMDJ (ORCPT ); Sun, 19 Apr 2020 08:03:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:46508 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725841AbgDSMDJ (ORCPT ); Sun, 19 Apr 2020 08:03:09 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EEB2F21841; Sun, 19 Apr 2020 12:03:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587297788; bh=x2vOiaCnxxSwfQdLjmqVJM8lbr3nu9ilx4uLADcHgbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BQIo366fubUyRRR8gy2ghwhRQu0Kwnh4p0dbM2JbxKVFUDW8yZ1SDgiYSl5JqwVeR wZ5SL8Ku8jXAHvkI6SEOWx2BKIwYfUnNkbRnpiO/xRR81S6FYbEAx2Q4OceLmb8Ctn LwJSFTVsq/8XLc3RC94BktgRcZXJ/hdv3QPM50lA= Date: Sun, 19 Apr 2020 14:03:04 +0200 From: Greg Kroah-Hartman To: Linus Torvalds Cc: Joe Perches , Rafael Wysocki , Randy Dunlap , Matthew Wilcox , Linux Kernel Mailing List , Andrew Morton , Alexander Viro , linux-fsdevel , Dmitry Torokhov , linux-input@vger.kernel.org, Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-usb@vger.kernel.org, "J. Bruce Fields" , Chuck Lever , "open list:NFS, SUNRPC, AND..." , Johannes Berg , Dan Williams , Vishal Verma , Dave Jiang , linux-nvdimm , "Martin K. Petersen" , linux-scsi , target-devel , Zzy Wysm Subject: Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c Message-ID: <20200419120304.GA3668771@kroah.com> References: <20200418184111.13401-1-rdunlap@infradead.org> <20200418184111.13401-8-rdunlap@infradead.org> <20200418185033.GQ5820@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org On Sat, Apr 18, 2020 at 12:15:57PM -0700, Linus Torvalds wrote: > On Sat, Apr 18, 2020 at 11:57 AM Joe Perches wrote: > > > > sysfs_create_link is __must_check > > The way to handle __must_check if you really really don't want to test > and have good reasons is > > (a) add a big comment about why this case ostensibly doesn't need the check > > (b) cast a test of it to '(void)' or something (I guess we could add > a helper for this). So something like > > /* We will always clean up, we don't care whether this fails > or succeeds */ > (void)!!sysfs_create_link(...) > > There are other alternatives (like using WARN_ON_ONCE() instead, for > example). So it depends on the code. Which is why that comment is > important to show why the code chose that option. > > However, I wonder if in this case we should just remove the > __must_check. Greg? It goes back a long long time. Yeah, maybe it is time to remove it, the gyrations people go through to remove the warning when they "know" they are doing it right feels pretty bad compared to forcing people to check things for "normal" calls to the function. thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDB4FC3A5A9 for ; Sun, 19 Apr 2020 12:03:11 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D1D3821744 for ; Sun, 19 Apr 2020 12:03:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BQIo366f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1D3821744 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 6DB8F10FC62F8; Sun, 19 Apr 2020 05:03:13 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=gregkh@linuxfoundation.org; receiver= Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 31EA2100AA410 for ; Sun, 19 Apr 2020 05:03:11 -0700 (PDT) Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EEB2F21841; Sun, 19 Apr 2020 12:03:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587297788; bh=x2vOiaCnxxSwfQdLjmqVJM8lbr3nu9ilx4uLADcHgbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BQIo366fubUyRRR8gy2ghwhRQu0Kwnh4p0dbM2JbxKVFUDW8yZ1SDgiYSl5JqwVeR wZ5SL8Ku8jXAHvkI6SEOWx2BKIwYfUnNkbRnpiO/xRR81S6FYbEAx2Q4OceLmb8Ctn LwJSFTVsq/8XLc3RC94BktgRcZXJ/hdv3QPM50lA= Date: Sun, 19 Apr 2020 14:03:04 +0200 From: Greg Kroah-Hartman To: Linus Torvalds Subject: Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c Message-ID: <20200419120304.GA3668771@kroah.com> References: <20200418184111.13401-1-rdunlap@infradead.org> <20200418184111.13401-8-rdunlap@infradead.org> <20200418185033.GQ5820@bombadil.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Message-ID-Hash: ASXF7EG554IHZQOJIGHTEFSFUS25YEOL X-Message-ID-Hash: ASXF7EG554IHZQOJIGHTEFSFUS25YEOL X-MailFrom: gregkh@linuxfoundation.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: Joe Perches , Rafael Wysocki , Randy Dunlap , Matthew Wilcox , Linux Kernel Mailing List , Andrew Morton , Alexander Viro , linux-fsdevel , Dmitry Torokhov , linux-input@vger.kernel.org, Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-usb@vger.kernel.org, "J. Bruce Fields" , Chuck Lever , "open list:NFS, SUNRPC, AND..." , Johannes Berg , linux-nvdimm , linux-scsi , target-devel , Zzy Wysm X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, Apr 18, 2020 at 12:15:57PM -0700, Linus Torvalds wrote: > On Sat, Apr 18, 2020 at 11:57 AM Joe Perches wrote: > > > > sysfs_create_link is __must_check > > The way to handle __must_check if you really really don't want to test > and have good reasons is > > (a) add a big comment about why this case ostensibly doesn't need the check > > (b) cast a test of it to '(void)' or something (I guess we could add > a helper for this). So something like > > /* We will always clean up, we don't care whether this fails > or succeeds */ > (void)!!sysfs_create_link(...) > > There are other alternatives (like using WARN_ON_ONCE() instead, for > example). So it depends on the code. Which is why that comment is > important to show why the code chose that option. > > However, I wonder if in this case we should just remove the > __must_check. Greg? It goes back a long long time. Yeah, maybe it is time to remove it, the gyrations people go through to remove the warning when they "know" they are doing it right feels pretty bad compared to forcing people to check things for "normal" calls to the function. thanks, greg k-h _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kroah-Hartman Date: Sun, 19 Apr 2020 12:03:04 +0000 Subject: Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c Message-Id: <20200419120304.GA3668771@kroah.com> List-Id: References: <20200418184111.13401-1-rdunlap@infradead.org> <20200418184111.13401-8-rdunlap@infradead.org> <20200418185033.GQ5820@bombadil.infradead.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Linus Torvalds Cc: alsa-devel@alsa-project.org, Randy Dunlap , Rafael Wysocki , Zzy Wysm , Linux Kernel Mailing List , "J. Bruce Fields" , target-devel , Dave Jiang , linux-scsi , linux-nvdimm , Vishal Verma , Matthew Wilcox , Chuck Lever , linux-input@vger.kernel.org, Joe Perches , Alexander Viro , Dan Williams , Andrew Morton , "open list:NFS, SUNRPC, AND..." , "Martin K. Petersen" , Dmitry Torokhov , Takashi Iwai , linux-usb@vger.kernel.org, linux-fsdevel , Johannes Berg On Sat, Apr 18, 2020 at 12:15:57PM -0700, Linus Torvalds wrote: > On Sat, Apr 18, 2020 at 11:57 AM Joe Perches wrote: > > > > sysfs_create_link is __must_check > > The way to handle __must_check if you really really don't want to test > and have good reasons is > > (a) add a big comment about why this case ostensibly doesn't need the check > > (b) cast a test of it to '(void)' or something (I guess we could add > a helper for this). So something like > > /* We will always clean up, we don't care whether this fails > or succeeds */ > (void)!!sysfs_create_link(...) > > There are other alternatives (like using WARN_ON_ONCE() instead, for > example). So it depends on the code. Which is why that comment is > important to show why the code chose that option. > > However, I wonder if in this case we should just remove the > __must_check. Greg? It goes back a long long time. Yeah, maybe it is time to remove it, the gyrations people go through to remove the warning when they "know" they are doing it right feels pretty bad compared to forcing people to check things for "normal" calls to the function. thanks, greg k-h