[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250113191225.GS5556@nvidia.com>
Date: Mon, 13 Jan 2025 15:12:25 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: kevin.tian@...el.com, corbet@....net, will@...nel.org, joro@...tes.org,
suravee.suthikulpanit@....com, robin.murphy@....com,
dwmw2@...radead.org, baolu.lu@...ux.intel.com, shuah@...nel.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
linux-kselftest@...r.kernel.org, linux-doc@...r.kernel.org,
eric.auger@...hat.com, jean-philippe@...aro.org, mdf@...nel.org,
mshavit@...gle.com, shameerali.kolothum.thodi@...wei.com,
smostafa@...gle.com, ddutile@...hat.com, yi.l.liu@...el.com,
patches@...ts.linux.dev
Subject: Re: [PATCH v5 06/14] iommufd: Add IOMMUFD_OBJ_VEVENTQ and
IOMMUFD_CMD_VEVENTQ_ALLOC
On Fri, Jan 10, 2025 at 01:58:21PM -0800, Nicolin Chen wrote:
> Hmm, it seems that I haven't got your first narrative straight..
>
> Would you mind elaborate "copy_to_user() can block while waiting
> on a page fault"? When would this happen?
copy_to_user() is a sleeping function that sleeps if the user memory
is non-present. So userspace can cause copy_to_user to copy to
anything, including memory that is non-present and will take along
time to page fault in. Eg perhaps by abusing userfaultfd.
We should not allow userspace to globally DOS the iommu driver this
way.
So do not hold locks that are also held by the HW event path across
copy_to_user().
Jason
Powered by blists - more mailing lists