| Message ID | 20230518110727.2106156-2-ryan.roberts@arm.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Encapsulate PTE contents from non-arch code | expand |
On Thu, May 18, 2023 at 12:07:23PM +0100, Ryan Roberts wrote: > It is bad practice to directly set pte entries within a pte table. > Instead all modifications must go through arch-provided helpers such as > set_pte_at() to give the arch code visibility and allow it to check > (and potentially modify) the operation. > > Fixes: 3e9a9e256b1e ("mm: add a vmap_pfn function") > Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> > Reviewed-by: Zi Yan <ziy@nvidia.com> > Acked-by: Lorenzo Stoakes <lstoakes@gmail.com> > Reviewed-by: Christoph Hellwig <hch@lst.de> > --- > mm/vmalloc.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 9683573f1225..48202ec5f79a 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2899,10 +2899,16 @@ struct vmap_pfn_data { > static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) > { > struct vmap_pfn_data *data = private; > + unsigned long pfn = data->pfns[data->idx]; > + pte_t ptent; > > - if (WARN_ON_ONCE(pfn_valid(data->pfns[data->idx]))) > + if (WARN_ON_ONCE(pfn_valid(pfn))) > return -EINVAL; > - *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot)); > + > + ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); > + set_pte_at(&init_mm, addr, pte, ptent); > + > + data->idx++; > return 0; > } > > -- > 2.25.1 > Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com> -- Uladzislau Rezki
On Thu, May 18, 2023 at 12:07:23PM +0100, Ryan Roberts wrote: > It is bad practice to directly set pte entries within a pte table. > Instead all modifications must go through arch-provided helpers such as > set_pte_at() to give the arch code visibility and allow it to check > (and potentially modify) the operation. > > Fixes: 3e9a9e256b1e ("mm: add a vmap_pfn function") > Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> > Reviewed-by: Zi Yan <ziy@nvidia.com> > Acked-by: Lorenzo Stoakes <lstoakes@gmail.com> > Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org> > --- > mm/vmalloc.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 9683573f1225..48202ec5f79a 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2899,10 +2899,16 @@ struct vmap_pfn_data { > static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) > { > struct vmap_pfn_data *data = private; > + unsigned long pfn = data->pfns[data->idx]; > + pte_t ptent; > > - if (WARN_ON_ONCE(pfn_valid(data->pfns[data->idx]))) > + if (WARN_ON_ONCE(pfn_valid(pfn))) > return -EINVAL; > - *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot)); > + > + ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); > + set_pte_at(&init_mm, addr, pte, ptent); > + > + data->idx++; > return 0; > } > > -- > 2.25.1 > >
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 9683573f1225..48202ec5f79a 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2899,10 +2899,16 @@ struct vmap_pfn_data { static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) { struct vmap_pfn_data *data = private; + unsigned long pfn = data->pfns[data->idx]; + pte_t ptent; - if (WARN_ON_ONCE(pfn_valid(data->pfns[data->idx]))) + if (WARN_ON_ONCE(pfn_valid(pfn))) return -EINVAL; - *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot)); + + ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); + set_pte_at(&init_mm, addr, pte, ptent); + + data->idx++; return 0; }
It is bad practice to directly set pte entries within a pte table. Instead all modifications must go through arch-provided helpers such as set_pte_at() to give the arch code visibility and allow it to check (and potentially modify) the operation. Fixes: 3e9a9e256b1e ("mm: add a vmap_pfn function") Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: Lorenzo Stoakes <lstoakes@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> --- mm/vmalloc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)