From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A78711DE2B9 for ; Thu, 16 Jan 2025 14:26:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737037572; cv=none; b=oj6hIskpxiH2Ugj5NTyAsGf9H3XQbv83GaIeGKPbLjBeRozLFDyu8uYOLR0FEdpUVHFgr0UoABzqeLSVKzttDIEUNmrUC31AcKWh08SmS+6FBL+xxkSd6QQ0N6gPJGjyeoPbNBGio9C8rLl1GaXFd7c0i238Ydromsms9fA5KHw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737037572; c=relaxed/simple; bh=Cbf234aSobN820SDLRoS0vB0kB7EtRKENiGrsWEFhzk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AyGb4GY11qRxcKPb6WZyXCvc3Bo0Ivqq8Heis6u999c5ZFpXAHlzC6u5/N8LhjUHyfGOJQEzXdFar6O11PKRgcBGs6+DF2OQ6G+lPpEx0CKYBePDoSX9kb0gX76OjZvIMRcIzChtGVEMbXLqpsDzNh4onO41Rbk4DWHvB8/7JBw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=PQAn1dmf; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PQAn1dmf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737037569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iKe6KcY8mvA8I/UtecGUiy6u52GdsOnELZoEiMhFOAc=; b=PQAn1dmfMLuqDz9NOgx16mcP+ekLo1hKgBMxVJ25/FcCfM8WXv0gpVDqorT6S1m6XOIkq8 jB1CfVUMEL+l982Ludpjn1v2KkLhsGp+a7koxtstZkjbALoujHST0dJLuOavEidVnSzJoO N260cgVe1yJ0M+AMs4+r0dsDcbW8xRU= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-62-qKjv-RYHM0uFg31XjTtJ8A-1; Thu, 16 Jan 2025 09:26:08 -0500 X-MC-Unique: qKjv-RYHM0uFg31XjTtJ8A-1 X-Mimecast-MFC-AGG-ID: qKjv-RYHM0uFg31XjTtJ8A Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-4675749a982so18147981cf.1 for ; Thu, 16 Jan 2025 06:26:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737037568; x=1737642368; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iKe6KcY8mvA8I/UtecGUiy6u52GdsOnELZoEiMhFOAc=; b=DLdfWLgQlJUpVVmYsRHI4mIqI2Hyro300bH8kh2gny6c6D6l+26TzFF2aHPSa57GtP RaDLpW4+Zi2WR59l/uwq19urEtI1y6oktwf0hBUHcvVRjZUyWKVZcWFI9QafpLAHYN+I OU4B3gJVMEYFKxykbkyiyVCMAlw9oLmfQPz/RqgjDJKMBSwA3PMlMURheM5PCY3OHw5O BHSon5zUy/Y/7JJEfoTk7gEbeLEctNWiYt/djVXPX+7ARRwwDvBWGwNlW1WsQC/XNwpI H3wBq+nPoQp3Wa/+dk3tqxatdsxj1DyL0QGkkZrv9swT/WoiXanalBIpQBz4WIQbr3Bb +Zig== X-Forwarded-Encrypted: i=1; AJvYcCXOiJpsHumEtZcZPLE2fKHZOohPzGXPwlhZ5+M9Au3MYicmXdCZmbdebo9hxv+usHW2unjEsNtzPbpBlzM=@vger.kernel.org X-Gm-Message-State: AOJu0YyYcbM897K3mKJP9rNjUxNIxzfS1EbHiKA9/loFZwCEQMsRKMjA ROAcm47+z1Pzr1lSo4G5toq4zMR8hZDy2Ei3ORFk7BMvx8U0xCkWnXndOMKJYhqjg7BjoiTa7BY wBDxSkTbdwbYozDOJSXxbIbYUMySDv967QVVPsYYRzLceDkwVzM2zTLwmzWjzjw== X-Gm-Gg: ASbGncu82NTUTicL2J685r7s4UQyzzJXt64dkiSdKFpPX2FuFk7nOGJoywZtUkOAHZG LRJfQ3d2xhFTFI9OexGPMBUrpM7mgXu21Vl7VK4srg1RONAALzvjsvbR5QET0opuAO+PvPT8Bc1 V8shVkVcunaUq3P2BzgA9wzejIrIl82eBjtAafO8wSFkmfncXNeKjXJr59mSM9KmiRC0ML5tLv4 eUO8ij1pQkd+PldKYTlh20/mSZFs4V8ntKGwfa4RGS6+jonI0pTonE8Uxau5ni0xAU3hkMNP3xx xrZWEY/7ahotMPwckg== X-Received: by 2002:a05:622a:47:b0:467:6226:bfbd with SMTP id d75a77b69052e-46c7108fddamr540431781cf.21.1737037567898; Thu, 16 Jan 2025 06:26:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2zEj7BJCtwai45n40ywW8QXo28hswimXis9xNl5GkP7DD2Ph5Fqhv4GN0l0MBAyJlw1aUQA== X-Received: by 2002:a05:622a:47:b0:467:6226:bfbd with SMTP id d75a77b69052e-46c7108fddamr540431421cf.21.1737037567578; Thu, 16 Jan 2025 06:26:07 -0800 (PST) Received: from x1n (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-46e102fe43fsm15081cf.26.2025.01.16.06.26.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 06:26:06 -0800 (PST) Date: Thu, 16 Jan 2025 09:26:05 -0500 From: Peter Xu To: Oscar Salvador Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton Subject: Re: [PATCH v2 3/7] mm/hugetlb: Rename avoid_reserve to cow_from_owner Message-ID: References: <20250107204002.2683356-1-peterx@redhat.com> <20250107204002.2683356-4-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Hi, Oscar, On Thu, Jan 16, 2025 at 11:15:09AM +0100, Oscar Salvador wrote: > Now, let me see if I get this straight: > > 1) parent maps a hugetlb page, but not yet fault in. > 2) forks, child faults-in the page Agreed until here. > 3) child doesn't have any reservation, when 'cow_from_owner' set to true > we check whether we have a spare hugetlb page to satisfy that When the child fault in, it should trigger the hugetlb CoW fault, in which case it should set 'cow_from_owner' to false (rather than true) always, because it's not a CoW from owner (the child is not an owner). See the check in the fault path: if (is_vma_resv_set(vma, HPAGE_RESV_OWNER) && old_folio != pagecache_folio) cow_from_owner = true; Here I would expect when the child faults, the 1st OWNER check failed. > 4) parent faults in the page > 5) we do not have spare hugetlb pages, so we 'steal' it from the child > with unmap_ref_private. Agreed on 4/5. At last step 5, above check will become true, hence this is the place where the allocation will have cow_from_owner set to true. If we see the difference at step 3/5, that's also exactly why I renamed the variable for the whole stack: it represents this special condition from the top layer (fault) until the allocation layer, saying explicitly when it should be set true (only "cow", from the "owner" not child), rather than a very blurred idea of someone trying to avoid_reserve for whatever reason. The hope is it made that niche path very clear in the allocation path, and it discourage any other user using this flag which can be abuse (and cause the allocation path harder to follow in general). Thanks, -- Peter Xu