From: "David Hildenbrand (Arm)" <david@kernel.org>
To: John Hubbard <jhubbard@nvidia.com>,
Yunhui Cui <cuiyunhui@bytedance.com>,
akpm@linux-foundation.org, jgg@ziepe.ca, peterx@redhat.com,
yang.lee@linux.alibaba.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Subject: Re: [PATCH] mm/gup_test: fix race with PIN_LONGTERM_TEST ioctls
Date: Fri, 12 Jun 2026 08:47:55 +0200 [thread overview]
Message-ID: <884cf1df-2256-4eb9-a2cb-67377a3bd8f6@kernel.org> (raw)
In-Reply-To: <932e1fa0-dd9e-47d2-9133-d3b2f78dcd97@nvidia.com>
On 6/12/26 06:20, John Hubbard wrote:
> On 6/7/26 7:50 PM, Yunhui Cui wrote:
>> The PIN_LONGTERM_TEST helpers keep their state in global variables that
>> are protected by pin_longterm_test_mutex when accessed from ioctl().
>> However, gup_test_release() calls pin_longterm_test_stop() without
>> holding that mutex.
>>
>> This can race with PIN_LONGTERM_TEST_STOP and let two callers operate on
>> the same pages array concurrently, corrupting the test state and possibly
>> freeing it twice:
>
> Let's add here that there are *no* such callers in the kernel, today.
>
>>
>> CPU 0 CPU 1
>> ----- -----
>> ioctl(PIN_LONGTERM_TEST_STOP)
>> mutex_lock(&pin_longterm_test_mutex)
>> pin_longterm_test_stop()
>> if (pin_longterm_test_pages)
>> kvfree(pin_longterm_test_pages)
>>
>> close()
>> gup_test_release()
>> pin_longterm_test_stop()
>> if (pin_longterm_test_pages)
>> kvfree(pin_longterm_test_pages)
>>
>> pin_longterm_test_pages = NULL
>> mutex_unlock(&pin_longterm_test_mutex)
>>
>> Protect the release path with the same mutex so that stop and release
>> cannot run pin_longterm_test_stop() concurrently.
>>
>> Fixes: c77369b437f9 ("mm/gup_test: start/stop/read functionality for PIN LONGTERM test")
>> Cc: stable@vger.kernel.org
>
> umm, no, to "Cc: stable". This is the sort of thing that gives AI
> a bad name. Specifically:
>
> * Nothing in tree can possibly hit this race condition.
>
> * This fix is purely static code analysis hygiene: correcting
> a theoretical problem that does not actually provide any
> sort of vulnerability fix in the kernel.
>
Yes, all rather useless churn that consumes our capacity.
--
Cheers,
David
next prev parent reply other threads:[~2026-06-12 6:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 2:50 [PATCH] mm/gup_test: fix race with PIN_LONGTERM_TEST ioctls Yunhui Cui
2026-06-12 4:20 ` John Hubbard
2026-06-12 6:47 ` David Hildenbrand (Arm) [this message]
2026-06-12 7:36 ` David Hildenbrand (Arm)
2026-08-10 10:23 ` [External] " yunhui cui
2026-08-10 11:02 ` David Hildenbrand (Arm)
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=884cf1df-2256-4eb9-a2cb-67377a3bd8f6@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cuiyunhui@bytedance.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yang.lee@linux.alibaba.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.