Received: by 2002:ab2:c01:0:b0:1ef:a04a:229c with SMTP id b1csp36337lqb; Sun, 10 Mar 2024 00:57:23 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVhV7r1A4Ql7WXvPhIGe65Q7xg6uFdcxkJklAX5wBocNoSxY78+j/W6Rnkm7ZwtcboxEONGsWSv5MdigGaDI5mZE/9FOoyYA+CKTrOL2Q== X-Google-Smtp-Source: AGHT+IF+J/5zu7phqEasCSnLzi0xjtv1QGBzQzxc/XtcvCA3sfqmQoYtNnTTiwsPIDPTt+CR+qNy X-Received: by 2002:a05:6870:fb91:b0:221:9159:4ae with SMTP id kv17-20020a056870fb9100b00221915904aemr3761211oab.55.1710061043434; Sun, 10 Mar 2024 00:57:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1710061043; cv=pass; d=google.com; s=arc-20160816; b=AtAM3e48muLR7I53X46oZrQms0r2fxHoQuB7uRKNulOrav4l30Y7sOMcS4qFmIifQm IsbePS145h0I0Zv7D3b9pxQbXNSbShKwTfiVF0Rrm5UlPI26w+Syx5uk6VG8IuK8v6zi EGrbzLwYvAYGH9NFXjTbpFjMIFt8wBE4qt0gnXoqNR0rpqZUOLH065rRnH6WCLhV5rWJ fAlcrQZcSCLgvHWZ5mVcl1VOQnWjVDgSXzjsJxtcyUYMwaWa9ClryavFbFFOgHey9m/o s5hyyX44JfE4utuNr/4h074/1vsTokilwtGiOXssNitGMOF6tz4usSycKkyqiWHZK/KH pOsA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=MKQ93p63o2otS+LT12JDoP89CmvcUexpXrKxc1eq7T8=; fh=0PFxBzmgQbDIvfoczeL2dNtiomtOp+U6Mw4Ct6BW/A8=; b=LuMr/B/7LybXa8ooD0q0VunqajmmpxSqM71mE2vuF3Tul/AMCe7KE6+VmWngDKQuWd xCzuaYzj4SgCmUW7bwdkMuCINVbcMfcVHKAi32z4DFFyhauqiqzV6puw/tQj69X3mZ86 RLsxhFOCk2hXbu2NzFscX25O6rOakJY6l13gEf/D2IwuQDnTHmiuc1tlYWPSgiAiJHAC p6pnIxhBMOOWhS3bpuWpY+mLQsMt4rvHy/eTob/LXf/h7VOFSCOyhgmK55ZDwpvksjWx QwXc8vlmNexBpsff/QSs5E38xpiDChzzueSPiCa8uRhJupLWM3d3kEm0w1ZtEs/e5yWM rsVA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hevEjtdC; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-98105-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-98105-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id fd32-20020a056a002ea000b006e5f7e04915si2859134pfb.159.2024.03.10.00.57.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Mar 2024 00:57:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-98105-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hevEjtdC; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-98105-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-98105-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 4DC09281D9C for ; Sun, 10 Mar 2024 03:00:01 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5C84B1171C; Sun, 10 Mar 2024 02:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="hevEjtdC" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA306F503; Sun, 10 Mar 2024 02:59:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710039591; cv=none; b=j+xdQ4heKaNKY2ZSyDzKVra+VJE4EqlK4pKrrMSoHCdo5HRh6IJx1IxyqDHZ/8FvDxf/h78k8xNNN3hArrMwGHl1ESNJzUXY6sooGd9x6Ygl9T6rnul3FKe2NCLXufPGLLnwvx2r07e3emPBNPmhaqdhF+/mcPDU1RLPkwOyB5I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710039591; c=relaxed/simple; bh=GfXW4C6GlijK82l5vOoVk6CS8xy/zjIX2B+QiJxYiv4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DIx7thEx9dJ9wyAJfJK+Hcl5oDsB1eWqUioR1aubbJyis/MPJk68knxkhTcBkLJBweA8Q/0CEUSE4o40/g5NuFvxBKX4tzbyec0TKVckHPo8GSHzkj5LKyfA25JFKYs7tmvp5sI80di3++pAGEhwBHrVada+m3uLXzp5qGQ5hV0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=hevEjtdC; arc=none smtp.client-ip=198.175.65.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710039589; x=1741575589; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=GfXW4C6GlijK82l5vOoVk6CS8xy/zjIX2B+QiJxYiv4=; b=hevEjtdCJBvIuveH/5x50LH5PrXLfOFhU9x4PDE9yAJYYHYNXoBdfU3T PUD2m4hQki75dSpKLK8AMWHUIoPNLVcvQ0YckOkceS6dTKxrE6p8CVD5l M/CSitwOtaSM65sHxzb3HyKWYA61Q7h5RjtldcFaAiVYu3qO4pz3Jb7oc VHUL7p6Y2zY4a45LgEKbHDvRFOti/lx3IvmrzUv7h1XnGkkZb63uqMMxC dNjO9tApfS+Dgb01+ia9/lAQDGIj7UAn3Ac9/zd599MAfhBEFTaO5U89P gqtB3Je3D4B4kXq6h6m1Q7NXo0s19SZcv05NkQn1tJ+I3wkgC0jq9A3A6 w==; X-IronPort-AV: E=McAfee;i="6600,9927,11008"; a="4652779" X-IronPort-AV: E=Sophos;i="6.07,113,1708416000"; d="scan'208";a="4652779" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2024 18:59:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,113,1708416000"; d="scan'208";a="10922168" Received: from leihuan1-mobl.amr.corp.intel.com (HELO [10.0.2.15]) ([10.124.0.187]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2024 18:59:48 -0800 Message-ID: <0fcdb6bc-68e6-639b-4710-7aaadda62ae1@linux.intel.com> Date: Sat, 9 Mar 2024 21:59:33 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v1] fs/fuse: Fix missing FOLL_PIN for direct-io To: Miklos Szeredi , Bernd Schubert Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <1693334193-7733-1-git-send-email-lei.huang@linux.intel.com> Content-Language: en-US From: Lei Huang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thank you very much, Miklos! Yes. It is not easy to reproduce the issues in real applications. We only observed the issue in our own testing tool which runs multiple tests concurrently. We have not been able reproduce it with simple code yet. -lei On 3/6/24 07:05, Miklos Szeredi wrote: > On Wed, 6 Mar 2024 at 12:16, Bernd Schubert wrote: >> >> >> >> On 3/6/24 11:01, Miklos Szeredi wrote: >>> On Tue, 29 Aug 2023 at 20:37, Lei Huang wrote: >>>> >>>> Our user space filesystem relies on fuse to provide POSIX interface. >>>> In our test, a known string is written into a file and the content >>>> is read back later to verify correct data returned. We observed wrong >>>> data returned in read buffer in rare cases although correct data are >>>> stored in our filesystem. >>>> >>>> Fuse kernel module calls iov_iter_get_pages2() to get the physical >>>> pages of the user-space read buffer passed in read(). The pages are >>>> not pinned to avoid page migration. When page migration occurs, the >>>> consequence are two-folds. >>>> >>>> 1) Applications do not receive correct data in read buffer. >>>> 2) fuse kernel writes data into a wrong place. >>>> >>>> Using iov_iter_extract_pages() to pin pages fixes the issue in our >>>> test. >>>> >>>> An auxiliary variable "struct page **pt_pages" is used in the patch >>>> to prepare the 2nd parameter for iov_iter_extract_pages() since >>>> iov_iter_get_pages2() uses a different type for the 2nd parameter. >>>> >>>> Signed-off-by: Lei Huang >>> >>> Applied, with a modification to only unpin if >>> iov_iter_extract_will_pin() returns true. >> >> Hi Miklos, >> >> do you have an idea if this needs to be back ported and to which kernel >> version? >> I had tried to reproduce data corruption with 4.18 - Lei wrote that he >> could see issues with older kernels as well, but I never managed to >> trigger anything on 4.18-RHEL. Typically I use ql-fstest >> (https://github.com/bsbernd/ql-fstest) and even added random DIO as an >> option - nothing report with weeks of run time. I could try again with >> more recent kernels that have folios. > > I don't think that corruption will happen in real life. So I'm not > sure we need to bother with backporting, and definitely not before > when the infrastructure was introduced. > > Thanks, > Miklos