Received: by 2002:a05:6830:16d2:b0:61c:ac69:ca1b with SMTP id l18csp197156otr; Thu, 4 Aug 2022 00:30:09 -0700 (PDT) X-Google-Smtp-Source: AA6agR7e/UEdWaNlzRjoJLg8LJZFVFjt1ymm+Ask5wMhqFjn25WI7LlHDGZ5/8Ga0k+covpxPoyD X-Received: by 2002:a17:907:3f24:b0:730:b83d:3a20 with SMTP id hq36-20020a1709073f2400b00730b83d3a20mr461040ejc.271.1659598208993; Thu, 04 Aug 2022 00:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659598208; cv=none; d=google.com; s=arc-20160816; b=aH0MYgd+t7FCFWGfGUzeYZNJURVyTJQzENHwPadgZW8EyuwLPV96d9SNkoVpUAGVXs jWqJfU/PxzBKJyv/aAKtvXAQG0TxJHLYE6HA5rhHjlMUPGrr1zd7VbM3imiifAUT0VJk xM8hjVUtMTGfnOQR6rr7APNh0H4QXIbDTGc2/popEwZnDtPdCOms51eFyU+oWxwoEdE6 WSKsJMqq0hub4t9vK7KA5rQV22u92m77bt9JKumND77RC4Zuc17feV4MGBsjfZW3S8mp 9L+WTZNoBjSqyGjzFSrZivy1BHyUdraJTZJMXt65GW6+umfmtaIJiXwyAd4/l/Qvih0/ EX0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :dkim-signature; bh=z3vWBn92jw9wjv8iB6bykXSQHVghyocK8H/JdGa1fPY=; b=DxBt5mYSvkNk7ukdydeXHBMtJn0SCQxTYbpqOZq8MgrO9zyomyDoQfY2XXX2KPruJP +0LFvhUvc5v4416wZDslQFyvhk3eh4aeUQ07oDatKjDo5ugDim544TWh9CkfYPk2IiPN bV/ILWMFnd2Y7frXs4AG8x8cbJNV6+51zutDQwKNAlYaHUqrDABFWLEchvUFe7GR0krq 3plR7Lfcphl1Gw8C4ImedSYQxSBVU71tzmooP9MCc4x6gagQEgxvwySrBKRJmBRtt5aa rkgY29x+mHwjjcpRebscSc3xZspE4VrR96OlBeQbvz5u7FT887cit5H3fPyxzi9G9mnP 8emw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=H8h5HFdn; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q5-20020aa7da85000000b0043e898f7840si385713eds.449.2022.08.04.00.29.47; Thu, 04 Aug 2022 00:30:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=H8h5HFdn; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239109AbiHDHXD (ORCPT + 66 others); Thu, 4 Aug 2022 03:23:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239092AbiHDHXB (ORCPT ); Thu, 4 Aug 2022 03:23:01 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [176.9.125.105]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0291C60683; Thu, 4 Aug 2022 00:22:57 -0700 (PDT) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id CF2E82224D; Thu, 4 Aug 2022 09:22:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1659597774; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z3vWBn92jw9wjv8iB6bykXSQHVghyocK8H/JdGa1fPY=; b=H8h5HFdnNZZANsest1Kfov9ceHkPlfP8EoQpXVKZDaeYgmAtpbID1CWSwRy8y22CSYqVLx uBH1L9yG7sRnnafOpFcUye16VmPhefsehiSVsksC6fgisUMUULaErTOlNoonDDcXjZgVmQ NSAi9BXdHfAffMWTBcxJuAXBcR1uI50= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 04 Aug 2022 09:22:51 +0200 From: Michael Walle To: Ajay.Kathat@microchip.com Cc: David.Laight@aculab.com, Claudiu.Beznea@microchip.com, kvalo@kernel.org, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, mwalle@kernel.org Subject: Re: [PATCH] wilc1000: fix DMA on stack objects In-Reply-To: References: <20220728152037.386543-1-michael@walle.cc> <0ed9ec85a55941fd93773825fe9d374c@AcuMS.aculab.com> <612ECEE6-1C05-4325-92A3-21E17EC177A9@walle.cc> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: michael@walle.cc X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Am 2022-07-29 17:39, schrieb Ajay.Kathat@microchip.com: > On 29/07/22 20:28, Michael Walle wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know >> the content is safe >> >> Am 29. Juli 2022 11:51:12 MESZ schrieb David Laight >> : >>> From: Michael Walle >>>> Sent: 28 July 2022 16:21 >>>> >>>> From: Michael Walle >>>> >>>> Sometimes wilc_sdio_cmd53() is called with addresses pointing to an >>>> object on the stack. E.g. wilc_sdio_write_reg() will call it with an >>>> address pointing to one of its arguments. Detect whether the buffer >>>> address is not DMA-able in which case a bounce buffer is used. The >>>> bounce >>>> buffer itself is protected from parallel accesses by >>>> sdio_claim_host(). >>>> >>>> Fixes: 5625f965d764 ("wilc1000: move wilc driver out of staging") >>>> Signed-off-by: Michael Walle >>>> --- >>>> The bug itself probably goes back way more, but I don't know if it >>>> makes >>>> any sense to use an older commit for the Fixes tag. If so, please >>>> suggest >>>> one. >>>> >>>> The bug leads to an actual error on an imx8mn SoC with 1GiB of RAM. >>>> But the >>>> error will also be catched by CONFIG_DEBUG_VIRTUAL: >>>> [ 9.817512] virt_to_phys used for non-linear address: >>>> (____ptrval____) (0xffff80000a94bc9c) >>>> >>>> .../net/wireless/microchip/wilc1000/sdio.c | 28 >>>> ++++++++++++++++--- >>>> 1 file changed, 24 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/net/wireless/microchip/wilc1000/sdio.c >>>> b/drivers/net/wireless/microchip/wilc1000/sdio.c >>>> index 7962c11cfe84..e988bede880c 100644 >>>> --- a/drivers/net/wireless/microchip/wilc1000/sdio.c >>>> +++ b/drivers/net/wireless/microchip/wilc1000/sdio.c >>>> @@ -27,6 +27,7 @@ struct wilc_sdio { >>>> bool irq_gpio; >>>> u32 block_size; >>>> int has_thrpt_enh3; >>>> + u8 *dma_buffer; >>>> }; >>>> >>>> struct sdio_cmd52 { >>>> @@ -89,6 +90,9 @@ static int wilc_sdio_cmd52(struct wilc *wilc, >>>> struct sdio_cmd52 *cmd) >>>> static int wilc_sdio_cmd53(struct wilc *wilc, struct sdio_cmd53 >>>> *cmd) >>>> { >>>> struct sdio_func *func = container_of(wilc->dev, struct >>>> sdio_func, dev); >>>> + struct wilc_sdio *sdio_priv = wilc->bus_data; >>>> + bool need_bounce_buf = false; >>>> + u8 *buf = cmd->buffer; >>>> int size, ret; >>>> >>>> sdio_claim_host(func); >>>> @@ -100,12 +104,20 @@ static int wilc_sdio_cmd53(struct wilc *wilc, >>>> struct sdio_cmd53 *cmd) >>>> else >>>> size = cmd->count; >>>> >>>> + if ((!virt_addr_valid(buf) || object_is_on_stack(buf)) && >>> How cheap are the above tests? >>> It might just be worth always doing the 'bounce'? >> I'm not sure how cheap they are, but I don't think it costs more than >> copying the bulk data around. That's up to the maintainer to decide. > > > I think, the above checks for each CMD53 might add up to the processing > time of this function. These checks can be avoided, if we add new > function similar to 'wilc_sdio_cmd53' which can be called when the > local > variables are used. Though we have to perform the memcpy operation > which > is anyway required to handle this scenario for small size data. > > Mostly, either the static global data or dynamically allocated buffer > is > used with cmd53 except wilc_sdio_write_reg, wilc_sdio_read_reg > wilc_wlan_handle_txq functions. > > I have created a patch using the above approach which can fix this > issue > and will have no or minimal impact on existing functionality. The same > is copied below: > > > --- >  .../net/wireless/microchip/wilc1000/netdev.h  |  1 + >  .../net/wireless/microchip/wilc1000/sdio.c    | 46 > +++++++++++++++++-- >  .../net/wireless/microchip/wilc1000/wlan.c    |  2 +- >  3 files changed, 45 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/wireless/microchip/wilc1000/netdev.h > b/drivers/net/wireless/microchip/wilc1000/netdev.h > index 43c085c74b7a..2137ef294953 100644 > --- a/drivers/net/wireless/microchip/wilc1000/netdev.h > +++ b/drivers/net/wireless/microchip/wilc1000/netdev.h > @@ -245,6 +245,7 @@ struct wilc { >      u8 *rx_buffer; >      u32 rx_buffer_offset; >      u8 *tx_buffer; > +    u32 vmm_table[WILC_VMM_TBL_SIZE]; > >      struct txq_handle txq[NQUEUES]; >      int txq_entries; > diff --git a/drivers/net/wireless/microchip/wilc1000/sdio.c > b/drivers/net/wireless/microchip/wilc1000/sdio.c > index 600cc57e9da2..19d4350ecc22 100644 > --- a/drivers/net/wireless/microchip/wilc1000/sdio.c > +++ b/drivers/net/wireless/microchip/wilc1000/sdio.c > @@ -28,6 +28,7 @@ struct wilc_sdio { >      u32 block_size; >      bool isinit; >      int has_thrpt_enh3; > +    u8 *dma_buffer; >  }; > >  struct sdio_cmd52 { > @@ -117,6 +118,36 @@ static int wilc_sdio_cmd53(struct wilc *wilc, > struct sdio_cmd53 *cmd) >      return ret; >  } > > +static int wilc_sdio_cmd53_extend(struct wilc *wilc, struct sdio_cmd53 > *cmd) If you handle all the stack cases anyway, the caller can just use a bounce buffer and you don't need to duplicate the function. -michael