Received: by 10.213.65.68 with SMTP id h4csp66126imn; Mon, 12 Mar 2018 06:56:39 -0700 (PDT) X-Google-Smtp-Source: AG47ELvDyXLefqRcJU+i2PIKgrrAj+PC9xUJP6SisFndV8XrgQoK6H9q/vyh5bXrAkLNNXHO/7uu X-Received: by 2002:a17:902:a607:: with SMTP id u7-v6mr8213717plq.367.1520862999348; Mon, 12 Mar 2018 06:56:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520862999; cv=none; d=google.com; s=arc-20160816; b=Sz/1m3MTwVzD6uo5FeqtetnqyTjSqMEUERea4t31TkYm7tbUN+edzoGXcIQ3Zb/Qlb JLOEOwdOqfskvShzeMV2BKadadJ4G4r4Xt1yCwBroVFra1jh4tWAcgZ1jBF8TMRdZBeA xeyXuQDX6fMMa8iPxif2L72cSNWzuLRQtQiXED1EubmtDxS5n+AoYlA1LzyAtVqq5AHI Ho5spRvX926eMIoI0dfRlcZ8s7RfeyWM/sV+Ye5YfU302ck33rttM5/Goj/Pe8ZS1vDd w4fDFR7ryGJ5Vj8/lpy3NlumH0exMrM8HQ42B4+A1HrabNQ+kMHRReNz+IHY/NcA+yrY uDWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=Y4dCLH+aFKVQkggaKglnSzpuxHstb196LpKS1oL8Zbc=; b=MvDn31CoMcpjyNwO23RShR7s1YV/fGL/HoIMnpoJRFqxysIpx275v3YY5YgeOxqxWf SmnroacAidENRNfivRQQm7h5AufKPo4YrBGvItc+sW/+MdNQMxsxS8DoGs25RHPR4Cq4 zxj1PuenyIRRR0iixNyjC6Cdq5rSrfLJ1m/L+A9roXJeUt+WH1EjCFY03ZXyNuGq00pa miey58TQdhPl3Z11SsXpBu6KvsK02SJbFUj9IC7lmwEHVE3J+4FSXmYEELKRpBaeTe69 SrzQWwi8mTvky/popjPcA/Ofhy/30m165RY/vQhPBy+m0iRqDLcRMiSx3rr12J/CBASw wEAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=KN4rtrA1; dkim=pass header.i=@codeaurora.org header.s=default header.b=aj9JZ8L+; 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 o3-v6si5996908pld.591.2018.03.12.06.56.24; Mon, 12 Mar 2018 06:56:39 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=KN4rtrA1; dkim=pass header.i=@codeaurora.org header.s=default header.b=aj9JZ8L+; 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 S932280AbeCLNzI (ORCPT + 99 others); Mon, 12 Mar 2018 09:55:08 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:37514 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932147AbeCLNzG (ORCPT ); Mon, 12 Mar 2018 09:55:06 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 3397160807; Mon, 12 Mar 2018 13:55:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520862906; bh=Mb9abz8VIhS4SeQ3HN91ql/QgtS5EMd6FYxq8xooOxo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KN4rtrA1B3VkKCFDCKbMZxXiFQI8bmsX/KAvOFXA27FITYOPeRr3G5GJ1TZg7FHdo Gdg+eo7j/ZqeMU9O0N5PhmTNYN1fDrMWCwCBj/H7bGbTO3ghVZ3BagFbSatlYVWPQA jSHUAFJRTHfdeSsi4QlZ5sqAM7mrMzLmhYNAdgjY= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 749D8601D2; Mon, 12 Mar 2018 13:55:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520862905; bh=Mb9abz8VIhS4SeQ3HN91ql/QgtS5EMd6FYxq8xooOxo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aj9JZ8L+UG9bh63x/sumPQsiKqs5od662CMF9Q8YzLaX1rLq2uUb4nRiFiYM7bENt Qz1lEdyZ1CQ0IkDaYPHUTeCKjP+ypP7ecukSXfnRJDeVG6Bwp94GamPYBQeeEWuMBg uvg50KhdGoMNHk32fxolX7KueNOv7v2OaLOCprlc= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 12 Mar 2018 19:25:05 +0530 From: Abhishek Sahu To: "Christ, Austin" Cc: Andy Gross , Wolfram Sang , David Brown , Sricharan R , linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len In-Reply-To: <99d007e0-7983-f0bf-1ca0-d37f2ea4d8fa@codeaurora.org> References: <1517644697-30806-1-git-send-email-absahu@codeaurora.org> <1517644697-30806-10-git-send-email-absahu@codeaurora.org> <99d007e0-7983-f0bf-1ca0-d37f2ea4d8fa@codeaurora.org> Message-ID: <732eadb6cf4304c6fb963f7b901ca4bf@codeaurora.org> X-Sender: absahu@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-02-28 03:36, Christ, Austin wrote: > Hey Abhishek, > > > On 2/3/2018 12:58 AM, Abhishek Sahu wrote: >> The BAM mode requires buffer for start tag data and tx, rx SG >> list. Currently, this is being taken for maximum transfer length >> (65K). But an I2C transfer can have multiple messages and each >> message can be of this maximum length so the buffer overflow will >> happen in this case. Since increasing buffer length won’t be >> feasible since an I2C transfer can contain any number of messages >> so this patch does following changes to make i2c transfers working >> for multiple messages case. >> >> 1. Calculate the required buffers for 2 maximum length messages >> (65K * 2). >> 2. Split the descriptor formation and descriptor scheduling. >> The idea is to fit as many messages in one DMA transfers for 65K >> threshold value (max_xfer_sg_len). Whenever the sg_cnt is >> crossing this, then schedule the BAM transfer and subsequent >> transfer will again start from zero. >> >> @@ -1603,7 +1640,7 @@ static int qup_i2c_probe(struct platform_device >> *pdev) >> one_bit_t = (USEC_PER_SEC / clk_freq) + 1; >> qup->one_byte_t = one_bit_t * 9; >> qup->xfer_timeout = TOUT_MIN * HZ + >> - usecs_to_jiffies(MX_TX_RX_LEN * qup->one_byte_t); >> + usecs_to_jiffies(2 * MX_TX_RX_LEN * qup->one_byte_t); > > Maybe it would make sense to add a comment here explaining why the > magic number 2 has been added. Thanks Austin for reviewing the patches. Now in v2, I have used the new macro MX_DMA_TX_RX_LEN which will make this multiplication by 2 more clear. This 2 is for allocating memory by taking 2 maximum length messages. https://lkml.org/lkml/2018/3/12/423 Thanks, Abhishek