From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (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 A0E064C83 for ; Mon, 20 May 2024 01:26:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716168365; cv=none; b=KXrcWdW3E0ej4lZ8ZVjbHSaQ2bx54swNyXkdAOY+uD0E2rGF3lIMBAPCfdU6ZNEwsoXke2bTZ9AeOI2LAJEW/W20l34JwVJlkeCeiFPKef5PDaoZawA78yIZDQr0MbkhlaMUi86ePffgdC9gabui0Zg1/P706rbGMHWd5tMzTTM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716168365; c=relaxed/simple; bh=TtwtjcXrrA11KTveXffexyVsNN0b1pCRGDvph290NUQ=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=Tp7XDYyHMVrCvDmrM+ewDlAdIb4w0kn9dKBq/UNP5pbxhi2kk5DgA3ojcuo4t3tRwEP9h7hDQ05ToMR1wMiZYHDdCa7UZXimxR9VQ/kEF8cP+NUcLUJ8H5zdFVyFPT7ObC5yAbERlA0W/iM0+OaQNAKMdtGb51L/MCa4aGDwyNM= 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=inyhMKtt; arc=none smtp.client-ip=192.198.163.14 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="inyhMKtt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1716168365; x=1747704365; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=TtwtjcXrrA11KTveXffexyVsNN0b1pCRGDvph290NUQ=; b=inyhMKtt40q1Cp89ck/GS8B8G48yAVjrWWwGZXt/lYA1AqVqevIdU6SF Cv+XCQ+uCQ0ZcWTEapXok7b6QP4CQMp4ueLE5gFg5pkOChBqTvlu5BXAw f2I77yXtReWc6HA7cTxnwcAf1GUlY8JnKkFdlBOv3Y2z994g5hfE6TvY/ 7yZvh4NqNYTvjEaD12bWgL8I9o01QxD3Ax62ZMDCuXLw3MNibtjpTICkh jOAqTT5kpJ0Szae5l2a4xzLu6wU5rqverxO2P0q1e234yxoJROSDN5/V3 87nVhY5S8BIwaMRHaChmpJcAu9LfnhzIQZmMhOgzk2sH90Pz2OXLaLTYk Q==; X-CSE-ConnectionGUID: Va07MakeQFWJVcw2TG0t2Q== X-CSE-MsgGUID: t2lEetHtQ4qpbVKJ3LBAbw== X-IronPort-AV: E=McAfee;i="6600,9927,11077"; a="12498186" X-IronPort-AV: E=Sophos;i="6.08,174,1712646000"; d="scan'208";a="12498186" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2024 18:26:04 -0700 X-CSE-ConnectionGUID: SI+sGxD1SaWg/GFY7brOWg== X-CSE-MsgGUID: db5ZHzgxSsuIxnX9A7ZDYQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,174,1712646000"; d="scan'208";a="36786047" Received: from unknown (HELO [10.239.159.127]) ([10.239.159.127]) by fmviesa005.fm.intel.com with ESMTP; 19 May 2024 18:26:01 -0700 Message-ID: <79bacf16-dfa6-42c7-b02d-117985e38472@linux.intel.com> Date: Mon, 20 May 2024 09:24:09 +0800 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, "iommu@lists.linux.dev" , "virtualization@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v5 5/9] iommufd: Add iommufd fault object To: "Tian, Kevin" , Jason Gunthorpe , Joerg Roedel , Will Deacon , Robin Murphy , Jean-Philippe Brucker , Nicolin Chen , "Liu, Yi L" , Jacob Pan , Joel Granados References: <20240430145710.68112-1-baolu.lu@linux.intel.com> <20240430145710.68112-6-baolu.lu@linux.intel.com> Content-Language: en-US From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/15/24 4:37 PM, Tian, Kevin wrote: >> +static ssize_t iommufd_fault_fops_write(struct file *filep, const char __user >> *buf, >> + size_t count, loff_t *ppos) >> +{ >> + size_t response_size = sizeof(struct iommu_hwpt_page_response); >> + struct iommufd_fault *fault = filep->private_data; >> + struct iommu_hwpt_page_response response; >> + struct iommufd_device *idev = NULL; >> + struct iopf_group *group; >> + size_t done = 0; >> + int rc; >> + >> + if (*ppos || count % response_size) >> + return -ESPIPE; >> + >> + mutex_lock(&fault->mutex); >> + while (count > done) { >> + rc = copy_from_user(&response, buf + done, response_size); >> + if (rc) >> + break; >> + >> + if (!idev || idev->obj.id != response.dev_id) >> + idev = container_of(iommufd_get_object(fault->ictx, >> + response.dev_id, >> + >> IOMMUFD_OBJ_DEVICE), >> + struct iommufd_device, obj); >> + if (IS_ERR(idev)) >> + break; >> + >> + group = xa_erase(&idev->faults, response.cookie); >> + if (!group) >> + break; > is 'continue' better? If we can't find a matched iopf group here, it means userspace provided something wrong. The current logic is that we stop here and tell userspace that only part of the faults have been responded to and it should retry the remaining responses with the right message. Best regards, baolu