Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1382881pxb; Wed, 20 Oct 2021 04:06:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxamsvx4Tct8SIIBz7jDHfMPBG+re26yr10iT4tkMeiV8klwV92wrkU3FrGYOpnbHyt9/HN X-Received: by 2002:a17:906:fad8:: with SMTP id lu24mr47288975ejb.133.1634727969859; Wed, 20 Oct 2021 04:06:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634727969; cv=none; d=google.com; s=arc-20160816; b=UgX67o2e6SIyO3P1ScEzZ/vIqiNtjkHCVF1JSY2p4+uEcNrk4CpEsKXZ0Q5x41XOxW +uuY3BVCc8N6qCTETxM3bWN4k5OOxNE2ieFOvaxSMhy+WrdrYSvWGs/Bdum+kRbKUAVE uIxfOoyJ5cOowy1uIhTBa1B3FPjN40ZTzbYrsakH95z0WcTV1X+rmAwjtnSw6oHTcuEI 13UvbDjQvLJej6+XD06gfgKGtPpNw9BWPHNDl2yocVORyogwkA37vLalWSgVNf0/iIwN NASj5fyi79oFtO4P1wjgZSQUIyzMlGCokTOEip+vMGm9FxRYR/vEIwvdzX/ZU82O2OZQ LPkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=8A9C5E8tdK3Q1/o4m/27R2aNTTSBIWA+hDzCu4axFW0=; b=09LPC9lqX8sbO5APoE7syEPrHrBhFsd0nyvxDIbCyNfyDE1bmxcDo6DS8PZsljs3lM ny1B6/edGZdodZLDol4x5lmz2mssvuXuSf6H+5zoyxPVK0Et/iwI5lsTBdKM1rhFIjsW 2/rHVAP2GGEXRKgfnvLdzXvDQVbX5B5npTGObeXaLShhTyBtJXrv2JCzzbagstU7LRoc +8faeG/oSue9eI7O/y4mAUTblgB2kOPFnIbP2J714lZ8PZItgWgLWb89z0KQc+zDwtL+ Mk4ybC+3xb3B5DlmKRhTVD49ilxYpic82+zHztmnEmrjUBDM36SQJSLpkDemZp2UK3nm +GVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XL2jKHlr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y11si2189499edu.339.2021.10.20.04.05.44; Wed, 20 Oct 2021 04:06:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XL2jKHlr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230090AbhJTLFe (ORCPT + 99 others); Wed, 20 Oct 2021 07:05:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229910AbhJTLFd (ORCPT ); Wed, 20 Oct 2021 07:05:33 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3242C061746 for ; Wed, 20 Oct 2021 04:03:19 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id t184so2680260pfd.0 for ; Wed, 20 Oct 2021 04:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8A9C5E8tdK3Q1/o4m/27R2aNTTSBIWA+hDzCu4axFW0=; b=XL2jKHlr/fyCAFaxWGlvHVmU8AtpFp0D/QTIzup/lf4toTqvizjmReZiGgUfASJQWz qhRSldMBBAPK0WZr9mOTUoRTtp+gFoRbGHhjo24DFksiOmhma/THWyHmPIDYjci7mXV/ DGDi02PbSGfW4iux8MsflOkpO0GFekIfyoAMA4RJ2ESOJx+4zFjK+YU9XPxXUcrYJ1T2 iu+aFFLvfhgwoz3Bmp3qz+84Hzjf5H/QcPceMTHaaAlRUxG0WxaEjgG4W/i25u8mgNTn IfIzOGQv0Ka4lvz4qFlc+1IrL+y2DsNn11SBk8YfQEKaxbSyNVuh0x948ZwqCCLTVt64 LSRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8A9C5E8tdK3Q1/o4m/27R2aNTTSBIWA+hDzCu4axFW0=; b=rfdfK6Y4If65BWAMicq4nThQdF6Wnyj21Gle3JE3BE26wWiKT7WPf4hjnqdRdebBp5 rzRRDUUMKNIn5inj0Zk/VLSqnwIkLZSyJGy005Ws4P7nw7M1e5hpzbEl+G54V/QkXa1E P7fb6BsmHsSy+9y0SqO6RrDqgVGayEFRLsUOA92d2fbi8wEHpcVfy2gl0wURXAYB24jB Xu6ioCWSRq4ocW0EO/ajMVrKGWZ1u7mb5VcIMMGbb356F0j/cp/IyS5ZB5l8mgGounSN tGJ3u4vgU29yQW9n6mvjZDO/BBSbFLMHtiNMITsAvfDJcdA8DEj4/C8s0ArZX+QiW4jk 34uQ== X-Gm-Message-State: AOAM530k8IiDOJO9hdyUwDBu8H3FrzK3aV8+ImD0MDk8V2IaWvZh8MrV VAbu0tD3/nAMBY0pD8PZCeT9aA== X-Received: by 2002:a63:6b82:: with SMTP id g124mr732952pgc.20.1634727799170; Wed, 20 Oct 2021 04:03:19 -0700 (PDT) Received: from localhost ([106.201.113.61]) by smtp.gmail.com with ESMTPSA id ob5sm6296790pjb.2.2021.10.20.04.03.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Oct 2021 04:03:18 -0700 (PDT) Date: Wed, 20 Oct 2021 16:33:16 +0530 From: Viresh Kumar To: Vincent Whitchurch Cc: Jie Deng , Greg KH , Wolfram Sang , "virtualization@lists.linux-foundation.org" , "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" , kernel Subject: Re: [PATCH 1/2] i2c: virtio: disable timeout handling Message-ID: <20211020110316.4x7tnxonswjuuoiw@vireshk-i7> References: <20211019094203.3kjzch7ipbdv7peg@vireshk-i7> <20211019143748.wrpqopj2hmpvblh4@vireshk-i7> <94aa39ab-4ed6-daee-0402-f58bfed0cadd@intel.com> <8e182ea8-5016-fa78-3d77-eefba7d58612@intel.com> <20211020064128.y2bjsbdmpojn7pjo@vireshk-i7> <01d9c992-28cc-6644-1e82-929fc46f91b4@intel.com> <20211020105554.GB9985@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211020105554.GB9985@axis.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20-10-21, 12:55, Vincent Whitchurch wrote: > If the timeout cannot be disabled, then the driver should be fixed to > always copy buffers and hold on to them to avoid memory corruption in > the case of timeout, as I mentioned in my commit message. That would be > quite a substantial change to the driver so it's not something I'm > personally comfortable with doing, especially not this late in the -rc > cycle, so I'd leave that to others. Or we can avoid clearing up and freeing the buffers here until the point where the buffers are returned by the host. Until that happens, we can avoid taking new requests but return to the earlier caller with timeout failure. That would avoid corruption, by freeing buffers sooner, and not hanging of the kernel. -- viresh