From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [benet] possible endianness bug in be_cmd_txq_create() Date: Sun, 10 Dec 2017 20:17:05 +0000 Message-ID: <20171210201705.GU21978@ZenIV.linux.org.uk> References: <20171210164120.GS21978@ZenIV.linux.org.uk> <20171210184307.GT21978@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sathya Perla To: netdev@vger.kernel.org Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:51838 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751994AbdLJURG (ORCPT ); Sun, 10 Dec 2017 15:17:06 -0500 Content-Disposition: inline In-Reply-To: <20171210184307.GT21978@ZenIV.linux.org.uk> Sender: netdev-owner@vger.kernel.org List-ID: On Sun, Dec 10, 2017 at 06:43:08PM +0000, Al Viro wrote: > On Sun, Dec 10, 2017 at 04:41:20PM +0000, Al Viro wrote: > > > I don't have the hardware, so the above is completely untested (caught by > > sparse when trying to do endianness annotations in drivers/net), but it > > does look like it might be worth a look from benet maintainers. > > Another very fishy place is be_roce_mcc_cmd(). be_get_fw_log_level()/be_set_fw_log_level() look slightly fishy as well: the latter has if (cfgs->module[i].trace_lvl[j].mode == MODE_UART) cfgs->module[i].trace_lvl[j].dbg_lvl = cpu_to_le32(level); while the former if (cfgs->module[0].trace_lvl[j].mode == MODE_UART) level = cfgs->module[0].trace_lvl[j].dbg_lvl; and returns level without further conversions. The caller of be_cmd_set_...() pass a host-endian value as level (48 or 64); the caller of be_cmd_get_...() expect a host-endian return value - it compares the result with 48. There's almost certainly a missing conversion somewhere; at a guess - le32_to_cpu() on the be_cmd_get_...() side.