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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 B5FBFC433E0 for ; Mon, 22 Feb 2021 15:34:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6267864E74 for ; Mon, 22 Feb 2021 15:34:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231536AbhBVPe3 (ORCPT ); Mon, 22 Feb 2021 10:34:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:58230 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230412AbhBVPcW (ORCPT ); Mon, 22 Feb 2021 10:32:22 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5E2A564E76; Mon, 22 Feb 2021 15:31:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614007898; bh=XMEZ7PH/ni+hF/4PzC80cUBZVOIDoDWFydw/tU/lfhE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pz+ySTl/03N7Tyvbc8xOkfaa/v61t91srPxX0mzW7+7fEpiM+U55PDXRlAZE5uOSw unbPjWJBEnZ69vAvjjCsy5BuQ2QWWFstuzBRkkbNsDzxBR1Ljay6jYq3beAZvgzya8 bieDwiFexYbtu+ADcBO/xQIoz/W2VZ5snJ0J4rLs= Date: Mon, 22 Feb 2021 16:26:33 +0100 From: Greg KH To: Atul Gopinathan Cc: tiwai@suse.de, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, gustavo@embeddedor.com Subject: Re: [PATCH 2/2] staging: rtl8192e: Change state information from u16 to u8 Message-ID: References: <20210220182154.9457-1-atulgopinathan@gmail.com> <20210220182154.9457-2-atulgopinathan@gmail.com> <20210221165721.GA10040@atulu-nitro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210221165721.GA10040@atulu-nitro> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 21, 2021 at 10:27:21PM +0530, Atul Gopinathan wrote: > On Sun, Feb 21, 2021 at 02:08:26PM +0100, Greg KH wrote: > > On Sat, Feb 20, 2021 at 11:51:55PM +0530, Atul Gopinathan wrote: > > > The "CcxRmState" field in struct "rtllib_network" is defined > > > as a u16 array of size 2 (so, 4 bytes in total). > > > > > > But the operations performed on this array throughout the code > > > base (in rtl8192e/) are all in byte size 2 indicating that this > > > array's type was defined wrongly. > > > > > > There are two situation were u16 type of this field could yield > > > incorrect behaviour: > > > > > > 1. In rtllib_rx.c:1970: > > > memcpy(network->CcxRmState, &info_element->data[4], 2); > > > > > > Here last 2 bytes (index 4 and 5) from the info_element->data[] > > > array are meant to be copied into CcxRmState[]. > > > Note that "data" array here is an array of type u8. > > > > > > 2. In function "update_network()" in staging/rtl8192e/rtllib_rx.c: > > > memcpy(dst->CcxRmState, src->CcxRmState, 2); > > > > > > Here again, only 2 bytes are copied from the source state to > > > destination state. > > > > > > There are no instances of "CcxRmState" requiring u16 data type. > > > Here is the output of "grep -IRn 'CcxRmState'" on the rtl8192e/ > > > directory for reviewing: > > > > > > rtllib_rx.c:1970: memcpy(network->CcxRmState, &info_element->data[4], 2); > > > rtllib_rx.c:1971: if (network->CcxRmState[0] != 0) > > > rtllib_rx.c:1975: network->MBssidMask = network->CcxRmState[1] & 0x07; > > > rtllib_rx.c:2520: memcpy(dst->CcxRmState, src->CcxRmState, 2); > > > rtllib.h:1108: u8 CcxRmState[2]; > > > > You just changed the logic in line 1975 in that file, right? Are you > > _SURE_ that is ok? Do you have a device to test this on? > > I'm sorry, I didn't quite get you. By line 1975 in rtllib_rx.c, did you mean > the following line?: > > network->MBssidMask = network->CcxRmState[1] & 0x07; Yes. > network->CcxRmState is being fed with 2 bytes of u8 data, in line 1970 (as > seen above). I believe my patch doesn't change the logic of an "&" operation > being performed on it with 0x07, right? It changes the location of the [1] operation to point to a different place in memory from what I can tell, as you changed the type of that array. 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 B4868C433DB for ; Mon, 22 Feb 2021 15:31:45 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 2777F64EDB for ; Mon, 22 Feb 2021 15:31:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2777F64EDB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B627E839DC; Mon, 22 Feb 2021 15:31:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5JXfi3nUPu8; Mon, 22 Feb 2021 15:31:43 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp1.osuosl.org (Postfix) with ESMTP id 6876283A48; Mon, 22 Feb 2021 15:31:43 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 5B1AE1BF3FE for ; Mon, 22 Feb 2021 15:31:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 4A78F6F56D for ; Mon, 22 Feb 2021 15:31:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id groESLvwmj-3 for ; Mon, 22 Feb 2021 15:31:40 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5176E600D4 for ; Mon, 22 Feb 2021 15:31:40 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5E2A564E76; Mon, 22 Feb 2021 15:31:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614007898; bh=XMEZ7PH/ni+hF/4PzC80cUBZVOIDoDWFydw/tU/lfhE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pz+ySTl/03N7Tyvbc8xOkfaa/v61t91srPxX0mzW7+7fEpiM+U55PDXRlAZE5uOSw unbPjWJBEnZ69vAvjjCsy5BuQ2QWWFstuzBRkkbNsDzxBR1Ljay6jYq3beAZvgzya8 bieDwiFexYbtu+ADcBO/xQIoz/W2VZ5snJ0J4rLs= Date: Mon, 22 Feb 2021 16:26:33 +0100 From: Greg KH To: Atul Gopinathan Subject: Re: [PATCH 2/2] staging: rtl8192e: Change state information from u16 to u8 Message-ID: References: <20210220182154.9457-1-atulgopinathan@gmail.com> <20210220182154.9457-2-atulgopinathan@gmail.com> <20210221165721.GA10040@atulu-nitro> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210221165721.GA10040@atulu-nitro> X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tiwai@suse.de, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, gustavo@embeddedor.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On Sun, Feb 21, 2021 at 10:27:21PM +0530, Atul Gopinathan wrote: > On Sun, Feb 21, 2021 at 02:08:26PM +0100, Greg KH wrote: > > On Sat, Feb 20, 2021 at 11:51:55PM +0530, Atul Gopinathan wrote: > > > The "CcxRmState" field in struct "rtllib_network" is defined > > > as a u16 array of size 2 (so, 4 bytes in total). > > > > > > But the operations performed on this array throughout the code > > > base (in rtl8192e/) are all in byte size 2 indicating that this > > > array's type was defined wrongly. > > > > > > There are two situation were u16 type of this field could yield > > > incorrect behaviour: > > > > > > 1. In rtllib_rx.c:1970: > > > memcpy(network->CcxRmState, &info_element->data[4], 2); > > > > > > Here last 2 bytes (index 4 and 5) from the info_element->data[] > > > array are meant to be copied into CcxRmState[]. > > > Note that "data" array here is an array of type u8. > > > > > > 2. In function "update_network()" in staging/rtl8192e/rtllib_rx.c: > > > memcpy(dst->CcxRmState, src->CcxRmState, 2); > > > > > > Here again, only 2 bytes are copied from the source state to > > > destination state. > > > > > > There are no instances of "CcxRmState" requiring u16 data type. > > > Here is the output of "grep -IRn 'CcxRmState'" on the rtl8192e/ > > > directory for reviewing: > > > > > > rtllib_rx.c:1970: memcpy(network->CcxRmState, &info_element->data[4], 2); > > > rtllib_rx.c:1971: if (network->CcxRmState[0] != 0) > > > rtllib_rx.c:1975: network->MBssidMask = network->CcxRmState[1] & 0x07; > > > rtllib_rx.c:2520: memcpy(dst->CcxRmState, src->CcxRmState, 2); > > > rtllib.h:1108: u8 CcxRmState[2]; > > > > You just changed the logic in line 1975 in that file, right? Are you > > _SURE_ that is ok? Do you have a device to test this on? > > I'm sorry, I didn't quite get you. By line 1975 in rtllib_rx.c, did you mean > the following line?: > > network->MBssidMask = network->CcxRmState[1] & 0x07; Yes. > network->CcxRmState is being fed with 2 bytes of u8 data, in line 1970 (as > seen above). I believe my patch doesn't change the logic of an "&" operation > being performed on it with 0x07, right? It changes the location of the [1] operation to point to a different place in memory from what I can tell, as you changed the type of that array. thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel