From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
Lixiao Yang <lixiao.yang@intel.com>,
Matthew Rosato <mjrosato@linux.ibm.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 1/2] iommufd: Do not access the area pointer after unlocking
Date: Tue, 20 Jun 2023 09:36:06 -0300 [thread overview]
Message-ID: <ZJGdNhEd+A0qmA1Z@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB52768CF5BF9526D06C7149DE8C5CA@BN9PR11MB5276.namprd11.prod.outlook.com>
On Tue, Jun 20, 2023 at 05:30:39AM +0000, Tian, Kevin wrote:
> this looks incorrect. If the unmapped range covers more than 1000 areas
> and each area is attached by an access, this logic implies that an error will
> be returned after the first 1000 areas are unmapped.
Yes, that makes sense
> IMHO here we want to record the last notified area and compare it in
> retry, e.g.:
>
> struct iopt_area *last_notify_area = NULL;
We can't use the area pointer, but we can keep track of the IOVA and
reset tries as it progresses.
Thanks,
Jason
next prev parent reply other threads:[~2023-06-20 12:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-19 18:24 [PATCH rc 0/2] iommufd syzkaller fixes Jason Gunthorpe
2023-06-19 18:24 ` [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking Jason Gunthorpe
2023-06-20 4:42 ` Nicolin Chen
2023-06-20 5:30 ` Tian, Kevin
2023-06-20 12:36 ` Jason Gunthorpe [this message]
2023-06-19 18:24 ` [PATCH rc 2/2] iommufd: Call iopt_area_contig_done() under the lock Jason Gunthorpe
2023-06-20 5:34 ` Tian, Kevin
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=ZJGdNhEd+A0qmA1Z@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.