Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp640421imm; Sat, 8 Sep 2018 06:12:53 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYzN51OFaIuCQ+oTgaip1JS97WcevTQVLPkmeciOnTmgEeVwdZa7/KyMf4grvD/7nisK3Sx X-Received: by 2002:a62:59d5:: with SMTP id k82-v6mr13672230pfj.143.1536412373419; Sat, 08 Sep 2018 06:12:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536412373; cv=none; d=google.com; s=arc-20160816; b=btBposA2OHqAJx0kAxTNZOxoR6bdMx9ObBABeHwQgUWhj8RYKIjOBraFPiSyuAcgJ1 cfZ9kRIXetUOinrvhDPZDE46zvcgeup92OwIn4/LJHo6Gmz5iZ9S/Z4meON+b79i2OvS uuE4zstJfOpLo4YtSvY3XicSPe5zUdzQ+0nfuIBu6aISaSNbhXRlIyEYksDKvgkUYGHm seW8NXHXoLuIxrxl8E3uZZCOKSx8EfuxFPTJnN0f+gb2ayzxmBIMq051nCHpwmcs/3JB Vhz0vCEn5mf/3p3Z5sXezpK0xfaPfYSDzDnytXnKOjL2i7xsnrOq8Up7EHO31GMNiTTF tbgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=a1mZjQRhhEuVFpeuOcfU8z93YnMF9UyC8qjYhfqTBEY=; b=muolftU7OZk6y5IrRIjTFiBeDPrtOVqCdhRRG1w3C6Wt8E9su4WgBgBvHLkhGeC6WL CgYoY60Fhg6Ia7JZCmbinWGZRiQu5BRP8U0OHr9JvhNxFGfXGRs4FdRks8+3TbrHlDjq WzVNNlTVA9QZbb1aR0f1YjYHtehesQdVut7Y3EfWgaiMdqLfZktmnDTW5MUBso0M5vmN xz3DtPGAOwBeMITFwbgjm21NaqF9R7S2Mlu3O1IXHR4nSXjetZcGSaTGzytTfENsrsgs +x5HgT3l5MRPas8/1LQpMBD93jc/I/GoRjVyZsF5EYHtoI7490G+wa0iKxdLSbGqfUSt zyKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c9-v6si11373907pgj.654.2018.09.08.06.12.37; Sat, 08 Sep 2018 06:12:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726705AbeIHR5R (ORCPT + 99 others); Sat, 8 Sep 2018 13:57:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:44356 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726351AbeIHR5R (ORCPT ); Sat, 8 Sep 2018 13:57:17 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DFF7BAECE; Sat, 8 Sep 2018 13:11:31 +0000 (UTC) Date: Sat, 8 Sep 2018 15:11:30 +0200 From: Jean Delvare To: zhong jiang Cc: , , , , , Subject: Re: [PATCH 2/2] s390: qeth_core_mpc: Use ARRAY_SIZE instead of reimplementing its function Message-ID: <20180908151130.3504d838@endymion> In-Reply-To: <1536402388-23872-3-git-send-email-zhongjiang@huawei.com> References: <1536402388-23872-1-git-send-email-zhongjiang@huawei.com> <1536402388-23872-3-git-send-email-zhongjiang@huawei.com> Organization: SUSE Linux X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 8 Sep 2018 18:26:28 +0800, zhong jiang wrote: > ARRAY_SIZE has implemented its function. we prefer to use the function > rather than the open code. > > Signed-off-by: zhong jiang > --- > drivers/s390/net/qeth_core_mpc.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/s390/net/qeth_core_mpc.c b/drivers/s390/net/qeth_core_mpc.c > index 5bcb8da..e8263de 100644 > --- a/drivers/s390/net/qeth_core_mpc.c > +++ b/drivers/s390/net/qeth_core_mpc.c > @@ -222,8 +222,7 @@ struct ipa_rc_msg { > char *qeth_get_ipa_msg(enum qeth_ipa_return_codes rc) > { > int x = 0; > - qeth_ipa_rc_msg[sizeof(qeth_ipa_rc_msg) / > - sizeof(struct ipa_rc_msg) - 1].rc = rc; > + qeth_ipa_rc_msg[ARRAY_SIZE(qeth_ipa_rc_msg) - 1].rc = rc; > while (qeth_ipa_rc_msg[x].rc != rc) > x++; > return qeth_ipa_rc_msg[x].msg; > @@ -270,9 +269,7 @@ struct ipa_cmd_names { > char *qeth_get_ipa_cmd_name(enum qeth_ipa_cmds cmd) > { > int x = 0; > - qeth_ipa_cmd_names[ > - sizeof(qeth_ipa_cmd_names) / > - sizeof(struct ipa_cmd_names)-1].cmd = cmd; > + qeth_ipa_cmd_names[ARRAY_SIZE(qeth_ipa_cmd_names) - 1].cmd = cmd; > while (qeth_ipa_cmd_names[x].cmd != cmd) > x++; > return qeth_ipa_cmd_names[x].name; Reviewed-by: Jean Delvare BTW, this code looks racy. It is modifying a global array member without any locking. If there is any chance that two instances of qeth_check_ipa_data() are running in parallel and both have unknown command (or unknown rc), we could end up overrunning either qeth_ipa_rc_msg[] or qeth_ipa_cmd_names[]. OK, that's unlikely to happen in practice (I suppose unknown command and unknown rc are not supposed to happen in the first place), but that's still bad programming style. I'll try to come up with something better... -- Jean Delvare SUSE L3 Support