From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
Lixiao Yang <lixiao.yang@intel.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"syzbot+1ad12d16afca0e7d2dde@syzkaller.appspotmail.com"
<syzbot+1ad12d16afca0e7d2dde@syzkaller.appspotmail.com>,
"syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com"
<syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com>,
"Liu, Yi L" <yi.l.liu@intel.com>
Subject: Re: [PATCH rc v2 1/2] iommufd: Do not access the area pointer after unlocking
Date: Wed, 21 Jun 2023 08:59:30 -0300 [thread overview]
Message-ID: <ZJLmIr8NLEVjddWB@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB527648F55F4F36A24B50E6778C5DA@BN9PR11MB5276.namprd11.prod.outlook.com>
On Wed, Jun 21, 2023 at 05:01:28AM +0000, Tian, Kevin wrote:
> At this point what about a concurrent thread triggering freeing of the
> area pointer and then adding a new area at the exactly same offset
> and the new area is also attached by an access?
>
> If it's allowed and repeatedly occurred, then the counter may overflow
> too given the new 'area_first' is equal to 'start' in that
> theoretical case...
Yes, and that is appropriate to return EDEADLOCK if we spend too much
time trying to free the same IOVA.
This is userspace harms itself, no sane userspace should race map and
unmap of the same IOVA.
Jason
next prev parent reply other threads:[~2023-06-21 11:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 14:11 [PATCH rc v2 0/2] iommufd syzkaller fixes Jason Gunthorpe
2023-06-20 14:11 ` [PATCH rc v2 1/2] iommufd: Do not access the area pointer after unlocking Jason Gunthorpe
2023-06-21 5:01 ` Tian, Kevin
2023-06-21 11:59 ` Jason Gunthorpe [this message]
2023-06-26 6:13 ` Tian, Kevin
2023-06-20 14:11 ` [PATCH rc v2 2/2] iommufd: Call iopt_area_contig_done() under the lock Jason Gunthorpe
2023-06-26 12:18 ` [PATCH rc v2 0/2] iommufd syzkaller fixes Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZJLmIr8NLEVjddWB@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=lixiao.yang@intel.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=syzbot+1ad12d16afca0e7d2dde@syzkaller.appspotmail.com \
--cc=syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com \
--cc=yi.l.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox