Re: [linux-next:master 5116/5396] mm/memory.c:710:25: sparse: sparse: cast to non-scalar

[Alistair Popple <apopple@nvidia.com>]

On Wednesday, 26 May 2021 11:56:13 PM AEST kernel test robot wrote:

> sparse warnings: (new ones prefixed by >>)
> >> mm/memory.c:710:25: sparse: sparse: cast to non-scalar
> >> mm/memory.c:710:25: sparse: sparse: cast from non-scalar

These warnings seem strange to me - sparse is warning about the following:

    struct test test1 = { .x = 0 }, test2;
    test2 = (struct test) test1;

But I don't see what the issue is. Obviously you wouldn't normally write code
like this but this is the result of macro expansion. The reason this warning
occurs only for Alpha is READ_ONCE has a different implementation there. At
this stage I don't think there is a problem with this patch though - it is
either an issue with sparse or with the Alpha READ_ONCE implementation. I did
have a go at fixing the Alpha implementation but couldn't come up with a way
to make sparse happy.

It's also worth noting a x86 build encounters the same pair of warnings in
other analogous situations.

 - Alistair

>    mm/memory.c:1024:17: sparse: sparse: context imbalance in 'copy_pte_range' - different lock contexts for basic block
>    mm/memory.c:1721:16: sparse: sparse: context imbalance in '__get_locked_pte' - different lock contexts for basic block
>    mm/memory.c:1770:9: sparse: sparse: context imbalance in 'insert_page' - different lock contexts for basic block
>    mm/memory.c:2272:17: sparse: sparse: context imbalance in 'remap_pte_range' - different lock contexts for basic block
>    mm/memory.c:2528:17: sparse: sparse: context imbalance in 'apply_to_pte_range' - unexpected unlock
>    mm/memory.c:2816:17: sparse: sparse: context imbalance in 'wp_page_copy' - unexpected unlock
>    mm/memory.c:3162:17: sparse: sparse: context imbalance in 'wp_pfn_shared' - unexpected unlock
>    mm/memory.c:3225:19: sparse: sparse: context imbalance in 'do_wp_page' - different lock contexts for basic block
>    mm/memory.c: note: in included file (through include/linux/mm.h, arch/alpha/include/asm/io.h, include/linux/io.h, include/linux/irq.h, ...):
>    include/linux/pgtable.h:257:16: sparse: sparse: cast to non-scalar
>    include/linux/pgtable.h:257:16: sparse: sparse: cast from non-scalar
>    mm/memory.c:4823:5: sparse: sparse: context imbalance in 'follow_invalidate_pte' - different lock contexts for basic block
>    mm/memory.c:4944:9: sparse: sparse: context imbalance in 'follow_pfn' - unexpected unlock
> 
> vim +710 mm/memory.c
> 
>    702
>    703  static void restore_exclusive_pte(struct vm_area_struct *vma,
>    704                                    struct page *page, unsigned long address,
>    705                                    pte_t *ptep)
>    706  {
>    707          pte_t pte;
>    708          swp_entry_t entry;
>    709
>  > 710          pte = pte_mkold(mk_pte(page, READ_ONCE(vma->vm_page_prot)));
>    711          if (pte_swp_soft_dirty(*ptep))
>    712                  pte = pte_mksoft_dirty(pte);
>    713
>    714          entry = pte_to_swp_entry(*ptep);
>    715          if (pte_swp_uffd_wp(*ptep))
>    716                  pte = pte_mkuffd_wp(pte);
>    717          else if (is_writable_device_exclusive_entry(entry))
>    718                  pte = maybe_mkwrite(pte_mkdirty(pte), vma);
>    719
>    720          set_pte_at(vma->vm_mm, address, ptep, pte);
>    721
>    722          /*
>    723           * No need to take a page reference as one was already
>    724           * created when the swap entry was made.
>    725           */
>    726          if (PageAnon(page))
>    727                  page_add_anon_rmap(page, vma, address, false);
>    728          else
>    729                  /*
>    730                   * Currently device exclusive access only supports anonymous
>    731                   * memory so the entry shouldn't point to a filebacked page.
>    732                   */
>    733                  WARN_ON_ONCE(!PageAnon(page));
>    734
>    735          if (vma->vm_flags & VM_LOCKED)
>    736                  mlock_vma_page(page);
>    737
>    738          /*
>    739           * No need to invalidate - it was non-present before. However
>    740           * secondary CPUs may have mappings that need invalidating.
>    741           */
>    742          update_mmu_cache(vma, address, ptep);
>    743  }
>    744
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>