From: kernel test robot <lkp@intel.com>
Cc: oe-kbuild-all@lists.linux.dev, vigneshr@ti.com, nm@ti.com
Subject: [ti:ti-android-linux-6.1.y 4/20] mm/mmap.c:1945:12: error: invalid type argument of '->' (have 'struct ma_state')
Date: Fri, 29 Mar 2024 08:44:17 +0800 [thread overview]
Message-ID: <202403290805.9efnF0gQ-lkp@intel.com> (raw)
Hi Liam,
FYI, the error/warning still remains.
tree: https://android.googlesource.com/kernel/common ti-android-linux-6.1.y
head: bbf722b1059a245fffdd90e1e763281a6d205dd3
commit: b802573f44901bf91ed597caf63b5e55ac162500 [4/20] FROMLIST: BACKPORT: mm: Set up vma iterator for vma_iter_prealloc() calls
config: parisc-allnoconfig (https://download.01.org/0day-ci/archive/20240329/202403290805.9efnF0gQ-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240329/202403290805.9efnF0gQ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403290805.9efnF0gQ-lkp@intel.com/
All errors (new ones prefixed by >>):
mm/mmap.c: In function 'expand_upwards':
>> mm/mmap.c:1945:12: error: invalid type argument of '->' (have 'struct ma_state')
1945 | mas->last = address - 1;
| ^~
vim +1945 mm/mmap.c
1908
1909 #if defined(CONFIG_STACK_GROWSUP) || defined(CONFIG_IA64)
1910 /*
1911 * PA-RISC uses this for its stack; IA64 for its Register Backing Store.
1912 * vma is the last one with address > vma->vm_end. Have to extend vma.
1913 */
1914 int expand_upwards(struct vm_area_struct *vma, unsigned long address)
1915 {
1916 struct mm_struct *mm = vma->vm_mm;
1917 struct vm_area_struct *next;
1918 unsigned long gap_addr;
1919 int error = 0;
1920 MA_STATE(mas, &mm->mm_mt, vma->vm_start, address - 1);
1921
1922 if (!(vma->vm_flags & VM_GROWSUP))
1923 return -EFAULT;
1924
1925 /* Guard against exceeding limits of the address space. */
1926 address &= PAGE_MASK;
1927 if (address >= (TASK_SIZE & PAGE_MASK))
1928 return -ENOMEM;
1929 address += PAGE_SIZE;
1930
1931 /* Enforce stack_guard_gap */
1932 gap_addr = address + stack_guard_gap;
1933
1934 /* Guard against overflow */
1935 if (gap_addr < address || gap_addr > TASK_SIZE)
1936 gap_addr = TASK_SIZE;
1937
1938 next = find_vma_intersection(mm, vma->vm_end, gap_addr);
1939 if (next && vma_is_accessible(next)) {
1940 if (!(next->vm_flags & VM_GROWSUP))
1941 return -ENOMEM;
1942 /* Check that both stack segments have the same anon_vma? */
1943 }
1944
> 1945 mas->last = address - 1;
1946 if (mas_preallocate(&mas, vma, GFP_KERNEL))
1947 return -ENOMEM;
1948
1949 /* We must make sure the anon_vma is allocated. */
1950 if (unlikely(anon_vma_prepare(vma))) {
1951 mas_destroy(&mas);
1952 return -ENOMEM;
1953 }
1954
1955 /*
1956 * vma->vm_start/vm_end cannot change under us because the caller
1957 * is required to hold the mmap_lock in read mode. We need the
1958 * anon_vma lock to serialize against concurrent expand_stacks.
1959 */
1960 anon_vma_lock_write(vma->anon_vma);
1961
1962 /* Somebody else might have raced and expanded it already */
1963 if (address > vma->vm_end) {
1964 unsigned long size, grow;
1965
1966 size = address - vma->vm_start;
1967 grow = (address - vma->vm_end) >> PAGE_SHIFT;
1968
1969 error = -ENOMEM;
1970 if (vma->vm_pgoff + (size >> PAGE_SHIFT) >= vma->vm_pgoff) {
1971 error = acct_stack_growth(vma, size, grow);
1972 if (!error) {
1973 /*
1974 * We only hold a shared mmap_lock lock here, so
1975 * we need to protect against concurrent vma
1976 * expansions. anon_vma_lock_write() doesn't
1977 * help here, as we don't guarantee that all
1978 * growable vmas in a mm share the same root
1979 * anon vma. So, we reuse mm->page_table_lock
1980 * to guard against concurrent vma expansions.
1981 */
1982 spin_lock(&mm->page_table_lock);
1983 if (vma->vm_flags & VM_LOCKED)
1984 mm->locked_vm += grow;
1985 vm_stat_account(mm, vma->vm_flags, grow);
1986 anon_vma_interval_tree_pre_update_vma(vma);
1987 vma->vm_end = address;
1988 /* Overwrite old entry in mtree. */
1989 vma_mas_store(vma, &mas);
1990 anon_vma_interval_tree_post_update_vma(vma);
1991 spin_unlock(&mm->page_table_lock);
1992
1993 perf_event_mmap(vma);
1994 }
1995 }
1996 }
1997 anon_vma_unlock_write(vma->anon_vma);
1998 khugepaged_enter_vma(vma, vma->vm_flags);
1999 mas_destroy(&mas);
2000 return error;
2001 }
2002 #endif /* CONFIG_STACK_GROWSUP || CONFIG_IA64 */
2003
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2024-03-29 0:44 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=202403290805.9efnF0gQ-lkp@intel.com \
--to=lkp@intel.com \
--cc=nm@ti.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=vigneshr@ti.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.