All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dev Jain" <dev.jain@arm.com>,
	david@kernel.org, ljs@kernel.org, akpm@linux-foundation.org,
	hughd@google.com, chrisl@kernel.org, kasong@tencent.com,
	davem@davemloft.net, andreas@gaisler.com
Cc: riel@surriel.com, liam@infradead.org, vbabka@kernel.org,
	harry@kernel.org, jannh@google.com, lance.yang@linux.dev,
	baolin.wang@linux.alibaba.com, shikemeng@huaweicloud.com,
	nphamcs@gmail.com, baoquan.he@linux.dev, baohua@kernel.org,
	youngjun.park@lge.com, linux-mm@kvack.org, rppt@kernel.org,
	surenb@google.com, mhocko@suse.com, pfalcato@suse.de,
	anshuman.khandual@arm.com, geert@linux-m68k.org,
	sparclinux@vger.kernel.org, ryan.roberts@arm.com
Subject: Re: [PATCH v4 9/9] mm, sparc: batch arch_unmap_one()
Date: Sun, 15 Nov 2026 15:23:26 +0000	[thread overview]
Message-ID: <sashiko-outbox-215629@kernel.org> (raw)
In-Reply-To: <20261115143905.3045084-10-dev.jain@arm.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] sparc: leak of ADI tag_users and tag storage in
  adi_save_tags_range()
--

commit ccbef0704b88d6e8aff2c2f0c82f32d9131dcc3f
Author: Dev Jain <dev.jain@arm.com>

mm, sparc: batch arch_unmap_one()

This commit extends arch_unmap_one() to accept a page count so SPARC can
save ADI tags across a PTE batch during anonymous large-folio unmapping.

> diff --git a/arch/sparc/kernel/adi_64.c b/arch/sparc/kernel/adi_64.c
> index 18036a43cf568..ffa378accefe3 100644
> --- a/arch/sparc/kernel/adi_64.c
> +++ b/arch/sparc/kernel/adi_64.c
[ ... ]
> @@ -394,3 +395,23 @@ int adi_save_tags(struct mm_struct *mm, struct vm_area_struct *vma,
>  
>  	return 0;
>  }
> +
> +int adi_save_tags_range(struct mm_struct *mm, struct vm_area_struct *vma,
> +			unsigned long addr, pte_t oldpte, unsigned long nr)
> +{
> +	unsigned long i;
> +
> +	for (i = 0; i < nr; i++, addr += PAGE_SIZE,
> +	     oldpte = pte_next_pfn(oldpte)) {
> +		int ret;
> +
> +		if (!(pte_val(oldpte) & _PAGE_MCD_4V))
> +			continue;
> +
> +		ret = adi_save_tags(mm, vma, addr, oldpte);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}

[Severity: Medium]
Does this leak tag_desc->tag_users references and tag storage when
adi_save_tags() fails partway through a batch?

Each successful adi_save_tags() call invokes alloc_tag_store(), which
allocates a tag_storage_desc_t slot (and its tag_desc->tags buffer) or
increments tag_desc->tag_users on an existing descriptor:

arch/sparc/kernel/adi_64.c:alloc_tag_store() {
    ...
				if ((addr >= tag_desc->start) &&
				    (tag_desc->end >= (addr + PAGE_SIZE - 1))) {
					tag_desc->tag_users++;
					goto out;
				}
    ...
}

If a batch crosses tag_desc->end at page i > 0 and alloc_tag_store() fails
its GFP_NOWAIT allocation for the new range, adi_save_tags_range() returns
an error without unwinding the first i pages.  In mm/rmap.c,
__ttu_anon_swapbacked_folio() then fails and ttu_anon_swapbacked_folio()
restores the present PTEs for the entire sub-batch via set_ptes().  Because
those first i pages are not swapped out, adi_restore_tags() ->
del_tag_store() never runs for them, leaking their tag_users references and
preventing del_tag_store() from freeing tag_desc->tags or releasing the
descriptor slot until process exit.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115143905.3045084-1-dev.jain@arm.com?part=9

      reply	other threads:[~2026-11-15 15:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-15 14:38 [PATCH v4 0/9] Optimize anonymous swapbacked large folio unmapping Dev Jain
2026-11-15 14:38 ` [PATCH v4 1/9] mm/swapfile: add batched version of folio_dup_swap Dev Jain
2026-11-15 14:38 ` [PATCH v4 2/9] mm/swapfile: add batched version of folio_put_swap Dev Jain
2026-11-15 14:38 ` [PATCH v4 3/9] mm: move anon-exclusive batch helper to rmap.h Dev Jain
2026-11-15 14:38 ` [PATCH v4 4/9] mm/rmap: Add batched version of folio_try_share_anon_rmap_pte Dev Jain
2026-11-15 14:39 ` [PATCH v4 5/9] mm/internal: rename swap offset helpers to softleaf offset Dev Jain
2026-11-15 14:39 ` [PATCH v4 6/9] mm/internal: add set_softleaf_ptes Dev Jain
2026-11-15 14:39 ` [PATCH v4 7/9] mm/memory: use set_softleaf_ptes for uffd-wp markers Dev Jain
2026-11-15 14:39 ` [PATCH v4 8/9] mm/rmap: batch unmap anonymous swap-backed large folios Dev Jain
2026-11-15 14:39 ` [PATCH v4 9/9] mm, sparc: batch arch_unmap_one() Dev Jain
2026-11-15 15:23   ` sashiko-bot [this message]

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=sashiko-outbox-215629@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andreas@gaisler.com \
    --cc=anshuman.khandual@arm.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=baoquan.he@linux.dev \
    --cc=chrisl@kernel.org \
    --cc=davem@davemloft.net \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=geert@linux-m68k.org \
    --cc=harry@kernel.org \
    --cc=hughd@google.com \
    --cc=jannh@google.com \
    --cc=kasong@tencent.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=nphamcs@gmail.com \
    --cc=pfalcato@suse.de \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shikemeng@huaweicloud.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=youngjun.park@lge.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.