Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Thu, 2 Nov 2023 21:31:04 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Rik van Riel <riel@surriel.com>
Cc:     Edward Adam Davis <eadavis@qq.com>, akpm@linux-foundation.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        llvm@lists.linux.dev, muchun.song@linux.dev, nathan@kernel.org,
        ndesaulniers@google.com,
        syzbot+6ada951e7c0f7bc8a71e@syzkaller.appspotmail.com,
        syzkaller-bugs@googlegroups.com, trix@redhat.com
Subject: Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write
Message-ID: <20231103043104.GA245368@monkey>
References: <3382634358afa9b95dc4f6db8a53a136d4b9e9cb.camel@surriel.com>
 <tencent_164A247533766D667C3D873798968236C409@qq.com>
 <20231103022426.GA3531@monkey>
 <20231103023737.GC3531@monkey>
 <48ec0dd17f048541dd83f7ed7cb29dac91d8c607.camel@surriel.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <48ec0dd17f048541dd83f7ed7cb29dac91d8c607.camel@surriel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?nF9zQIsk0fosl8eIwDsX9q5OMpTAxc3YDCOigBq+YWfLxnREAu8SYi8DYi?=
 =?iso-8859-1?Q?BO/Igohqy72D1hTO6YRdkJ10wi3TwfzAxUGeKIr3/A3FHlQlhk3s6ahMQ4?=
 =?iso-8859-1?Q?iKFHNBzXjmuDbd4aJLVQjQ8Be5+e34BqZS6W55zrrsJQvf+7uD182OyYGI?=
 =?iso-8859-1?Q?Nan2H1gfFUi5pZkmFnQfHyH6XfFTh9pXm3GkwDEy+FuUap1SFF35eCvT8U?=
 =?iso-8859-1?Q?7lHad5ARmSJWQbYnCQ8xbwf0G7Te7Z3qtqs2p+LJfRPFIxCoN4BltbsjZU?=
 =?iso-8859-1?Q?xUgebWAqac+mJr7/ZYcmTmEBxHWQji+T01tsf9gPMJbXDRzqBRy+jW51MN?=
 =?iso-8859-1?Q?5pF0v6AMTeHylkal8sm/sTbhHlsRF8StFZxHJ4HAce5GcgX6q0S/tMMGK2?=
 =?iso-8859-1?Q?obIKL3gOqY7+IAXjCYdEKgyXlqbACN3jDQ5aEGfsNjsYIDpAPRr3GJ2gvz?=
 =?iso-8859-1?Q?jKjgL+TVxFDjgKh02pWG2QHy7P+T7D+dBbBaSzuWFdUr8xfmyOLZOWKXXw?=
 =?iso-8859-1?Q?rueF/eRC7I7q2DQxf3d2wnT53B0li+gUCwn4GPl79eaSWBnMsYMDpmuPe3?=
 =?iso-8859-1?Q?eUqTPAvsGd9ew8LQCLUuujt1LrMAy3WItBpS00qPvI+qhIZkpTQVFvnq9y?=
 =?iso-8859-1?Q?aDWSB2LSwTjGQITP5G/XXb9VCJlWDxjnJZbe4cRYbe5iBOkGASCKrk/InW?=
 =?iso-8859-1?Q?K/hT3VI37DoXW9BeE508iLOQaq8wxUf+CRIQXxsVn3xyPoGg/lHl6JcAgV?=
 =?iso-8859-1?Q?+nFN6oarV4jO22yS7tPjKq5ibd0Lx1kZGALgtgVnJq8DV1iICI7nwvFRuL?=
 =?iso-8859-1?Q?XNtcAtY5xzjhZ03LoEFLnIy9rjW/py6EU5gv+VqzXQQoYYtafuBjCIAQgm?=
 =?iso-8859-1?Q?lNNB8xguHCyYNEiqhxzrCr7M+hvtEkjqVJOs0MZpAxaScQSjFpoCaI9HkB?=
 =?iso-8859-1?Q?OOcoHkfpg09s9odzrmffa+EZbJjyx1Pd95+ewMVLeVg7XnQwFWWpCum72n?=
 =?iso-8859-1?Q?oWh0AzZghccyvkPz2ZWHJNiablPcL0zZFywcqUEhwqfW8upBVNYoSSC1T8?=
 =?iso-8859-1?Q?0ovAEI/29K3iixoKlBgaOkQU0xnNxuJt954s0of0fR5IFi9Nu5UbGxcgbd?=
 =?iso-8859-1?Q?TkWIiqx91PYSzkGmsVE/sf5fbhOC7E/X9AIaw+bK9IZdvC/de52GIWiwJm?=
 =?iso-8859-1?Q?ckSN7A7wb0X62osrUgcZ9pI/MSSEHHDAvRT3XhvqcEEu6taR2CL33JCBIR?=
 =?iso-8859-1?Q?Efxty53UDmN1WAwXBr6vcWV+jiaaDzXLCYqzTfycPzt/wlLwQm8I18Jc2l?=
 =?iso-8859-1?Q?rWET+WLYMpI+/E5KI3+w8EWrr9woOhSiQOnOEicBNaE5fEBudc6s2sHeKw?=
 =?iso-8859-1?Q?KF0uQ9rT5fUrckMsw6/JEMR5dVFq7kn3XXL3PP8WyEk6pRQWzTcjoAiEKA?=
 =?iso-8859-1?Q?SD4GXglicG8OMrAZ7TblWmzH9M78ARHUszYa41DjkX3KSurPNED7AoHoYA?=
 =?iso-8859-1?Q?3fIOyAs51HbRdvPRuR/uO4wOLDxs9sH//P4RCI5GoyyTypaOnbYU4MLWgL?=
 =?iso-8859-1?Q?/WwT/t77VxePga4CcokKXN/sK8YC36qrJWnuPWLtnWyXb3DhvNaylbm9d+?=
 =?iso-8859-1?Q?6TYBN3YWszt0C7l9A1zscd5rgxX8HHJcTO?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?iso-8859-1?Q?NgTz9/gF+PasL8B6q8TJoFbF3t3v/46LDbegMxaZZl8QuTpp7JJ1XMuc40?=
 =?iso-8859-1?Q?G5Y3xDNVYZb6YhbDpLghUjbsilTmGaF00+yI+MQ9O5WlKQq3+wK/MZNZpS?=
 =?iso-8859-1?Q?DrxKiiInFkaBqH2h6xoG9QGz0RuhIlHVtQwdlTnDulZdsP9mBHzloh3upW?=
 =?iso-8859-1?Q?2AsTlhCRS5z3PxpQmZUZwh++VYX+5q8z3EuqUMXE03hJL4+rbUOlxcmiOo?=
 =?iso-8859-1?Q?kDqgT1y1yvSHRPy30/e6kw3A4hEAGSkWZ7doa4QbgNLf445CAukK/kFQgL?=
 =?iso-8859-1?Q?VxjW3iBHN8I2r4w3K1NK1DAQTT70nR0yDEINj7TDw80BER7vCQYOdguLwi?=
 =?iso-8859-1?Q?NxG6S2yLBU0kzcBCwK1luU+O52El8IcWPFo/RlE+Y+h/xNW+xXpY91u098?=
 =?iso-8859-1?Q?u0QPbSAk/qmiIWjnlUMNn48JMAVgtJunL9GMOvnqg/7H9YbWLb57gq2IX6?=
 =?iso-8859-1?Q?k1tKpJWQeeKOpXk7RemmWvFUh8YUYGmtlnmovO1UbG0tBbNt2MlqsOJ94j?=
 =?iso-8859-1?Q?761qINzI+Z/lNNrNXgu+BUOf7Tfm6tExGpy6tt7I/QMRAGBqAsh/Dsw8Ae?=
 =?iso-8859-1?Q?aYorBmegZZl8KhFcOTSuujkmXSp7KnzfnuuDPJz5hoRR9OHUZInt1tfFww?=
 =?iso-8859-1?Q?c/laqH9v5Z8tFJqaGv4FWpoG/51r8Hih4ItS0sctCQ8MMoT95bSAoKpRKK?=
 =?iso-8859-1?Q?2n2GOPbH2/nL/VMIz3NhafJOOpZtp8C+6HTmq2294Td/RxYwTE8VCRD0VE?=
 =?iso-8859-1?Q?30byd/7U/kK0PE6gLFZXLaemOHyN1n9B1cv6vz31MceW7T6sibDB3C067f?=
 =?iso-8859-1?Q?SPZ6qv8VFaocK5UO/wM7CMocF5uSDbf1Icqj1cPDI9m7SUd2fz6yUFJ5eR?=
 =?iso-8859-1?Q?/fvk0uAOI1R/Hv54Aor9yk9Vl5+jWYvNG6XauBgRoTTqvsjUfEMa+7/+af?=
 =?iso-8859-1?Q?B2ShlIk7KKMBGeFVSMcPXaQIeHCASJrL+8WGIC4KbLLkocBLKlPqwza7+b?=
 =?iso-8859-1?Q?nLU+JUSFVsI0ozzTFZBXkpfjss8Doj5oGGrLVcIcbd1xArNU+IKyAUWs3w?=
 =?iso-8859-1?Q?IoYBhJdMwxwp8a7Zn+x5IR+ne8pAewfi3+SaPEmkfyh8oIWy8wzLYeIasD?=
 =?iso-8859-1?Q?lPVbt15toLGwzHpbTD2O45uafLQOb6sKcG4jirsuIBYICp53S1ghelZr9y?=
 =?iso-8859-1?Q?G896x39b6fcp6bmBlaAq7kuJPMsXedZVVI0=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e4674855-6834-4ebe-bf24-08dbdc25b237
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2023 04:31:06.6086
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Ep6h8fAl51Xlgk+j1+EZKCxiyz6BJFKHDQU9EJaQOMdmfGY3fe0kdK3RaNmvm0GyTqXBtrD9Hvh8yK8mEh4DLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB6518
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-11-03_03,2023-11-02_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 mlxscore=0
 suspectscore=0 mlxlogscore=860 bulkscore=0 phishscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000
 definitions=main-2311030036
X-Proofpoint-GUID: Qa8la11WekuoMo1nkJVRVd8wb6vCj_Uf
X-Proofpoint-ORIG-GUID: Qa8la11WekuoMo1nkJVRVd8wb6vCj_Uf
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Thu, 02 Nov 2023 21:31:43 -0700 (PDT)

On 11/02/23 23:15, Rik van Riel wrote:
> On Thu, 2023-11-02 at 19:37 -0700, Mike Kravetz wrote:
> > On 11/02/23 19:24, Mike Kravetz wrote:
> > That qualification '(with resv_map)' caught my attention originally,
> > and
> > I thought about it again while looking into this.? We now cover the
> > common
> > cases, but there are still quite a few cases where resv_map is NULL
> > for
> > private mappings.? In such cases, the race between MADV_DONTNEED and
> > page
> > fault still exists.? Is that a concern?
> 
> Honestly, I'm not sure. In hugetlb_dup_vma_private, which is
> called at fork time, we have this comment:
> 
>          * - For MAP_PRIVATE mappings, this is the reserve map which
> does
>          *   not apply to children.  Faults generated by the children
> are
>          *   not guaranteed to succeed, even if read-only.
> 
> That suggests we already have no guarantee of faults
> succeeding after fork.

Right!

> 
> > 
> > With a bit more work we 'could' make sure every hugetlb vma has a
> > lock
> > to participate in this scheme.
> > 
> > Any thhoughts?
> 
> We can certainly close the race between MADV_DONTNEED
> and page faults for MAP_PRIVATE mappings in child processes,
> but that does not guarantee that we actually have hugetlb
> pages for those processes.
> 
> In short, I'm not sure :)

I sort of remember something Dave Hansen added years ago to help a customer
allocating LOTs of hugetlb pages dynamically.  I seem to recall that this
was to get better numa locality.  As a result, they did not use reservations.

I guess it sticks with me because it was/is a real example of a customer
choosing NOT to use reservations.  

I don't have any evidence that this is common.  My thought is to leave
it as is until someone complains.
-- 
Mike Kravetz