Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751497AbcLCVFx (ORCPT ); Sat, 3 Dec 2016 16:05:53 -0500 Received: from mail-lf0-f53.google.com ([209.85.215.53]:35802 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbcLCVFu (ORCPT ); Sat, 3 Dec 2016 16:05:50 -0500 Subject: Re: [PATCH 1/1] net: caif: fix ineffective error check To: PanBian , Dmitry Tarnyagin , "David S. Miller" References: <1480763901-5323-1-git-send-email-bianpan2016@163.com> <20161203153535.GA7976@bp> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org From: Sergei Shtylyov Organization: Cogent Embedded Message-ID: <218c3915-46f1-75e0-1a9b-f8cdc1789108@cogentembedded.com> Date: Sun, 4 Dec 2016 00:05:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161203153535.GA7976@bp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1136 Lines: 42 On 12/03/2016 06:38 PM, Pan Bian wrote: >>> In function caif_sktinit_module(), the check of the return value of >>> sock_register() seems ineffective. This patch fixes it. >>> >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188751 >>> >>> Signed-off-by: Pan Bian >>> --- >>> net/caif/caif_socket.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c >>> index aa209b1..2a689a3 100644 >>> --- a/net/caif/caif_socket.c >>> +++ b/net/caif/caif_socket.c >>> @@ -1108,7 +1108,7 @@ static int caif_create(struct net *net, struct socket *sock, int protocol, >>> static int __init caif_sktinit_module(void) >>> { >>> int err = sock_register(&caif_family_ops); >>> - if (!err) >>> + if (err) >>> return err; >> >> Why not just: >> >> return sock_register(&caif_family_ops); >> > Your solution looks much cleaner. > > But I am not really sure whether it is the author's intention to > return 0 anyway. Do you have any idea? I don't think so, the error check seems to have a typo. [...] > Best regards, > Pan MBR, Sergei