Message-ID: <92ad1cf1-cd73-c3f8-44b6-6eb917b94693@oracle.com>
Date:   Thu, 6 Jan 2022 09:43:47 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.0
Subject: Re: [PATCH] userfaultfd/selftests: clean up hugetlb allocation code
Content-Language: en-US
To:     Andrew Morton <akpm@linux-foundation.org>,
        Axel Rasmussen <axelrasmussen@google.com>
Cc:     LKML <linux-kernel@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
        Peter Xu <peterx@redhat.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Mina Almasry <almasrymina@google.com>,
        Shuah Khan <shuah@kernel.org>
References: <20220104021729.111006-1-mike.kravetz@oracle.com>
 <CAJHvVci5sSC-1TEiCBKe8uKQ=0uwCsoBJT_fsG1Rfq6ffy6Obg@mail.gmail.com>
 <20220105155613.45d7dcb81e19bd42deefab79@linux-foundation.org>
From:   Mike Kravetz <mike.kravetz@oracle.com>
In-Reply-To: <20220105155613.45d7dcb81e19bd42deefab79@linux-foundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?alMwbGdjMUJyemdtb00vdkk2VWUxcTVoRUE1WjVOSW1pY2ZhL1pSR1FEN2Fr?=
 =?utf-8?B?c1R6QmE1bG5iM2FlTDhXMDV3U1hmL2F1N2Y2UlA5YVFXa25TUkxwRlBhRkph?=
 =?utf-8?B?WkVab3cvTHFJaUF3VVR3SlNRVkQ1cE1LK3Z4MmV6UFR0QVJPQ2YrZ0kwZmxC?=
 =?utf-8?B?SHVOZ05wdzVGVU5nWTRUMWlzUTVoRTBCUDRTZ2dobFZlNlVONkJJa1FKUmlB?=
 =?utf-8?B?NUx0M1hqTUp4eWhQWHluZm9lejFnZGQyRFpxQUNCZ0NxQkRDRGV3aWt6aE5v?=
 =?utf-8?B?Slk4eXZpOGhVUHlCSzZoYXJmaFdKTlJ6dlZxWCtHbEovc1VNdFhndTk3bldC?=
 =?utf-8?B?Yll4YWZBS2FmWnI0K3h4cWgydXlZN2czZE5wYjRORXo1M2sycnJBU0Z5WmlP?=
 =?utf-8?B?bkdTWktxaCtIN0QwcTF4b3pLSkVudTZpQnlqeGthSFpxZXFtWmpUMW1GKzF0?=
 =?utf-8?B?UnJPaklGVExmaFdWNkN3WlhNaVVlWVN2YXA3eHZYQmJka1h2emFYS29Cd2VK?=
 =?utf-8?B?ek9qaHRNSStsOVphM3V1WEpRRVY4OXN5VTVna2diU3EvcjRsKzg3VXdKd2t0?=
 =?utf-8?B?L0l3TVovYlFOUm9ka2tVV1ljTEFiUUpUZE85N0NzZHgxeHRxblg5cHVWaXB1?=
 =?utf-8?B?R2tETGtPUE82TFY5bUlROTdCVjgwcUNXS3MwM0pCL1gwZTRwbEpCUFc4K0U0?=
 =?utf-8?B?dzlGNjhQbWNKMG9JUlNtNDNYQWFOWVU3bEpWSGxNaWxZMEsxTW1ydjNlenAz?=
 =?utf-8?B?S2crUmxydDdDNXJNN2RNbFJGTlVkbjRHd3QvMVRodTJnYUFNSnRZU0RwOUdG?=
 =?utf-8?B?b3ZXcW5hUjc5OVdENVJvVktwWEVjSkwram83L1RMejNiNE5HWnV4TmcyVnRX?=
 =?utf-8?B?cWczdjJmb0M2NGR1NnhqOHdpSWlJeUEyaEZ6L3ZkS01SdEgweGNFZlZ4Vy9n?=
 =?utf-8?B?OXhwSFU5bmFVdFNacVpkVU9haGlwSHFiZWtraUNIRk84V1kxRUtBNG8rSDl2?=
 =?utf-8?B?enRLdWo2V0VqUUxweHhGVFlPMzBweC80clVxcm9INlVZWTBoUW5GTnFtVWlB?=
 =?utf-8?B?L3BTSE5iRVlCNENDb1JHcDFNWUVwNkM4L0NaSWdxU0svUG5GTDBwd3lyTjI1?=
 =?utf-8?B?VjNsRjF3M0J3VzdTZ1ZDLzlGQU82S3lYc2cxaGZMQ1FqeVlSem9DNDNrbVUv?=
 =?utf-8?B?TXJ4aDZST2VuejJhRG9aK3RmdzljcEpqcTZTYk9Sdk5NTTZoSTVrYmRVbWtW?=
 =?utf-8?B?ZHU5czlkMHBTa1dTTDRDWU9jaWZZS3VpZ1VsVnFHQ040Q2JmUURpdDNzNnVH?=
 =?utf-8?B?NmtsejlSRUJURUExUWs1S0pETjkwa2V2R2FCM1lIdHlua1U3M3g0akR6NC83?=
 =?utf-8?B?NFYzZ1N4U0h4WFpZUWZ3bmZDaWluYngrbVA0TnNPZWdjN2xXQTlFTzNXQXZ4?=
 =?utf-8?B?Y3o4aVRsOVlVRXJBL0s0bWphTHpRT1ZXQnI1RXJoajN2V2UrNzZ4NEhGMTZI?=
 =?utf-8?B?M1RtNkxwRDFXekZxWW05UkpsSDBHV2s5eVc4cXkxRUdXdWgvRllabEVsZ0sx?=
 =?utf-8?B?OGsycUczeXlWaGxxelNieEl2Z2cwZlBsZ0tlejY2OTkzRmN6ZW9aQTR0SU1q?=
 =?utf-8?B?SUI0YVRudkt3VXlvR0J3dkMyaVBzTFdXVFZ3VW5GeDZjTk1ZaGZZWVJYU1I1?=
 =?utf-8?B?THVJdG5WNi9DejcrUWpNb3dqOHovMHZ6YlV0N2J0WGZHd1JFcjB0MTNidXM1?=
 =?utf-8?B?V1ZkbDJtenFkaW40aUhTcHlMQjR4ZmZzekR2Rlo0LzBZNFJYTXFWZ3NRSDJX?=
 =?utf-8?B?UW9rdk1RLzNNaFFxNGVmYU94VEg0RW9mU2lqblQvZ1I5LzhlQ3RRSmdoZW8r?=
 =?utf-8?B?R3htcGt4am5DVFZOSk5ubWdxcW5yMFQ4YmhJWnErYkt6bmZrNG0wODRhSkpY?=
 =?utf-8?B?NGNpY1Z4YUUvbmRpRWxjVVVsM1NpVFRKT0dweTdJeGl0eTJ5QkwrQVhKNVVF?=
 =?utf-8?B?OUd2MWVTMjZFRW04MDNXdFkwYWNsNkNYR2pEQ29hazVNQjBqdGxEZnpVdDZr?=
 =?utf-8?B?OUE4dEFTUUNDQWpnVkR6K0JYODJiakJpWklRYmZTR1A1Y1Y2SU5vTkFjemNM?=
 =?utf-8?B?L3dJY291S0VmeXYyWmk5N2U2UlRJcE5CSWFtS1Z1VEhkVnc4Wk0wSi9wampw?=
 =?utf-8?Q?wf637UJAnRoKMDfWPa5CuAU=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5103af56-1a31-413d-4b67-08d9d13c185f
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2022 17:43:48.8808
 (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: Lq0He851StN1a2UuGPwQdx2T8RsH0MLXab5tu/ODux2atWZ+PEylKsLPxMniyQe1vWqGTnsDEg29aUvFLI1LjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5632
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10219 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 malwarescore=0
 mlxlogscore=999 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000
 definitions=main-2201060118
X-Proofpoint-ORIG-GUID: IOfDa_dslMI3fXM5xWYobuJBshcEdY4q
X-Proofpoint-GUID: IOfDa_dslMI3fXM5xWYobuJBshcEdY4q
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/5/22 15:56, Andrew Morton wrote:
> On Tue, 4 Jan 2022 14:35:34 -0800 Axel Rasmussen <axelrasmussen@google.com> wrote:
> 
>> On Mon, Jan 3, 2022 at 6:17 PM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>>>
>>> The message for commit f5c73297181c ("userfaultfd/selftests: fix hugetlb
>>> area allocations") says there is no need to create a hugetlb file in the
>>> non-shared testing case.  However, the commit did not actually change
>>> the code to prevent creation of the file.
>>>
>>> While it is technically true that there is no need to create and use a
>>> hugetlb file in the case of non-shared-testing, it is useful.  This is
>>> because 'hole punching' of a hugetlb file has the potentially incorrect
>>> side effect of also removing pages from private mappings.  The
>>> userfaultfd test relies on this side effect for removing pages from the
>>> destination buffer during rounds of stress testing.
>>>
>>> Remove the incomplete code that was added to deal with no hugetlb file.
>>> Just keep the code that prevents reserves from being created for the
>>> destination area.
>>>
>>>         *alloc_area = mmap(NULL, nr_pages * page_size, PROT_READ | PROT_WRITE,
>>> -                          map_shared ? MAP_SHARED :
>>> -                          MAP_PRIVATE | MAP_HUGETLB |
>>> +                          (map_shared ? MAP_SHARED : MAP_PRIVATE) |
>>> +                          MAP_HUGETLB |
>>>                            (*alloc_area == area_src ? 0 : MAP_NORESERVE),
>>> -                          huge_fd,
>>> -                          *alloc_area == area_src ? 0 : nr_pages * page_size);
>>> +                          huge_fd, *alloc_area == area_src ? 0 :
>>> +                          nr_pages * page_size);
>>
>> Sorry to nitpick, but I think it was slightly more readable when the
>> ternary was all on one line.
> 
> When you have that many arguments I think it's clearer to put one per
> line, viz.
> 
> 	*alloc_area = mmap(NULL,
> 			   nr_pages * page_size,
> 			   PROT_READ | PROT_WRITE,
> 			   (map_shared ? MAP_SHARED : MAP_PRIVATE) |
> 			   	MAP_HUGETLB |
> 			   	(*alloc_area == area_src ? 0 : MAP_NORESERVE),
> 			   huge_fd,
> 			   *alloc_area == area_src ? 0 : nr_pages * page_size);
> 
> 
> But whatever...
I agree, and also agree with Axel's comment about keeping the ternary all on
one line.  However, there are examples of breaking both these conventions throughout the file.

My intention here was just to clean up the mess I created with the previous
patch.  As such, I would prefer to leave this patch as is.  If someone really
wants this modified, I will.  However, IMO if we make this one call easier
to read, we should use the same convention throughout the file.  I can do that
as well, but would prefer to first try to enable using mremap with hugetlb
within the test.
-- 
Mike Kravetz