Message-ID: <c19eefb9-76ef-5e03-50e2-8a90c20a4c19@oracle.com>
Date:   Mon, 10 Jan 2022 11:05:18 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.0
Subject: Re: [External] : Re: [PATCH v2 06/28] gup: Fix some contiguous memmap
 assumptions
Content-Language: en-US
To:     Matthew Wilcox <willy@infradead.org>,
        Christoph Hellwig <hch@infradead.org>
Cc:     linux-mm@kvack.org, John Hubbard <jhubbard@nvidia.com>,
        William Kucharski <william.kucharski@oracle.com>,
        linux-kernel@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>
References: <20220110042406.499429-1-willy@infradead.org>
 <20220110042406.499429-7-willy@infradead.org>
 <YdvuhjweiC1SjVF4@infradead.org> <Ydw2iQR8fT+qGkz6@casper.infradead.org>
From:   Mike Kravetz <mike.kravetz@oracle.com>
In-Reply-To: <Ydw2iQR8fT+qGkz6@casper.infradead.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?ZjVqeVNMV0pNQTgrOWZYdUpsc1paZXY1ekNBV3FsaGY4WFdyZm82Sk9adldS?=
 =?utf-8?B?MmxPbUJoN1lHWU1KQUNyYnVRYzBSRWxLbCtjRWpBWERKc3h4K0lWd1dsa3dO?=
 =?utf-8?B?b1p3cEJXeCtiL3JQTmdjT3ZWaWpNUS9TNlBlaW5GdnBpaE9QQWdPL0JaZlJS?=
 =?utf-8?B?VVU3amVac1NpMlVUSjNiWkxkN1ZnQXQzMXpsMXo5cHNGWHV1NVlSR3QyTjZW?=
 =?utf-8?B?Zm51T3hweEQzaWRtL1JGYjhCMGlXSnpselJzZVNMUDVuVUxRVytDUTg3dmZv?=
 =?utf-8?B?dlVFQUMyT2RPYVFlTm00MDdZWjNPS0g3TFZZRTkzZ2puaDBoTUVwS3FCTm9S?=
 =?utf-8?B?dmRpTDB1OFBhRmpiMm5hanVRU1dud0FrR0xBbEdOQjMrR3N6M0VsWUZQSEU4?=
 =?utf-8?B?TVl1dUJ3VmNwVU9Bc1d3WUFaS2ZQUXZHYXEyblhYRWxxeUVXZm5hMkg4RExW?=
 =?utf-8?B?VkZ3YlZETitSVlI1cE5KQW5FZDI4cGxka2tZVTg5eW9GRmpBZnhsMmVRVzB0?=
 =?utf-8?B?eGJXRDBmNUxEMlo5bzdMVkZsYkhnV3ExUjBISFRsdjZGN2hKL2FxQUR4cU9V?=
 =?utf-8?B?eFczMkdtOG5Jc3kxcVJua0NOWjJ2Vm1rUjNmMU1Na2hiajV3WG5WenU4Qnc2?=
 =?utf-8?B?bnkxODJQSDcvT0l1NkNtL0VqMzdRbVVwUUdZQkoybWdnRGxpbVdxTzhsUjhh?=
 =?utf-8?B?U2E1dUF0RUxyMGY2WkIwaEFtY0xIa2N1YWlDbTNwQlc4cnkzbm80Z3krNTB4?=
 =?utf-8?B?TVJlSDF6Y25OaVlJbXl3MktYU3I2UC9wN25wcnlEOUhoQWc0MmNXUnA2YTh3?=
 =?utf-8?B?QjdILzdLTzVIVExid2krQVBFUUVSNGpCRVZQcWhYazFOMi9lTTN5cW9tVS83?=
 =?utf-8?B?aUZMVGJFS0ZGQVlCMlVIMTBVVC9DK1dIT2RsbHl1bTVNY3VXYmNRTy9SUndZ?=
 =?utf-8?B?dkU0QzdRTW9vNFUyWlJQTllHU0NxV0Z6SVI4amp6VTNjdEx1MzJFSW9XRmww?=
 =?utf-8?B?dkpEaFF2cFN5Z3puNHFXMjdoWG5OWG56bjNNVGdOK21YaldJQU51UVV0Mmhm?=
 =?utf-8?B?WUJuZ1p6SjRuSlRJNlZFOVhHaGlMWUZIeWtXTnRia2FrZ0FBWkpNSzhCdkVT?=
 =?utf-8?B?ZGFsU1lqS01sS0I4OGRSdGRjamh0TERxcU5rM205aGlwd2tZL0x5ODlxZitT?=
 =?utf-8?B?c3VWcGI0bjFsVU95c3dzSnUvb1JMb0hud0psUkVXU0E2aXJLRFMxajkxeTN3?=
 =?utf-8?B?azYwZ3Jjd1VyYUZKcGtRWnFmS21FMzJ6UnlVamZDUjRxYkdLL291UmdDRnZM?=
 =?utf-8?B?cVdBWS9zZFpGMDM0R05vUC9mc1Nta0ZQd1hITTJXWnJ1QTV2M2lTMG94Ny9O?=
 =?utf-8?B?UFd4NlJzQmlmYzc1YSs5ZmJtc2tCNDRhNWI2bWlqSFB6QXRDczRQRGZnWVEy?=
 =?utf-8?B?dXRTYkxBOWlTN3BVV0tydXVoY2pPSmhPdVFNaEtCN3J5TGJBdXZzeWtGZm05?=
 =?utf-8?B?b2RuTlowS0pMUEl4WEJxYStaVS9sOEN1ejVRb0FTd3RaSCtJRGtJcVIxT1px?=
 =?utf-8?B?MUxKczcvQXNiN0xkQmV5ck54emdHMUM3SFhoZmZkcjd5WFZObVQ4RkM5dXlk?=
 =?utf-8?B?dHlCTGh5NHZ2RzFOTEZhN2dzdWdYMWNlQm1rbmJncnRLNEF2bDJDQmsvd2J6?=
 =?utf-8?B?QXUwQ2NQMXZ6NTVubVhNR3NHOVZ5K3hoL1B0K2hmcThxNWhrNUo3WkNHdDV0?=
 =?utf-8?B?VGJjM3JCVEFXUFh5SXBxZDJLVDZvSG1rUTIyOWxZb1VXaWNXNHdYbVNBM1Fl?=
 =?utf-8?B?OFNPZXBjQzNRQXpSZlZFZndyWU16d3VkZDdoRHdSS3J5aE5Yd2xaTGtjWWhy?=
 =?utf-8?B?QnllUVgxak8yajRtdjZMVVorekNVN0VuYTlwOC82VDR4UDROY3ZtVjZKdkpL?=
 =?utf-8?B?SHNuaThEWFJJZjYrbGpCRlQwa0s2aHUxUzMwaFQyNnhIeW8xcDZmQnpzUlRr?=
 =?utf-8?B?SFJEU3YzbGtwVkM0UDhMbkxnTXBLK00rL043K05aczFhMDZXUDJ3L2hheFl1?=
 =?utf-8?B?TVJqWGRmekhYUEJNU1VqdkZUVVoyM3NjMGhjOFN4U1N6eEw1WUU4OXhLMDNz?=
 =?utf-8?B?Y2ZJbDlqMURvb2l4VWJKTWM2NkFHZmVhS054RndGc2IrTElMelpwZmRKYWxs?=
 =?utf-8?Q?9z1nCO6QNjnRVP7XGkkPvQ4=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab2acdbb-22b3-443b-9d8e-08d9d46c2660
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2022 19:05:21.7258
 (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: MOdnzGmx6VM1+8fx0SoY4xOCUYh615qVWKhffOjyqQlcTqIBuaN0pcr3BHZ0bm7uwpG9vAKe3UdZfJ+gL+/31g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2455
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10223 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 spamscore=0
 phishscore=0 adultscore=0 suspectscore=0 mlxscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000
 definitions=main-2201100130
X-Proofpoint-GUID: 3upw_r42Qqd_FAcJJWkvQvop7s_cjjfU
X-Proofpoint-ORIG-GUID: 3upw_r42Qqd_FAcJJWkvQvop7s_cjjfU
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/10/22 05:37, Matthew Wilcox wrote:
> On Mon, Jan 10, 2022 at 12:29:58AM -0800, Christoph Hellwig wrote:
>> On Mon, Jan 10, 2022 at 04:23:44AM +0000, Matthew Wilcox (Oracle) wrote:
>>> Several functions in gup.c assume that a compound page has virtually
>>> contiguous page structs.  This isn't true for SPARSEMEM configs unless
>>> SPARSEMEM_VMEMMAP is also set.  Fix them by using nth_page() instead of
>>> plain pointer arithmetic.
>>
>> So is this an actualy bug that need a Fixes tag, or do all architectures
>> that support THP and sparsemem use SPARSEMEM_VMEMMAP?
> 
> As far as I can tell (and I am by no means an expert in this area),
> this problem only affects pages of order MAX_ORDER or higher.  That is,
> somebody using regular 2MB hugepages on x86 won't see a problem, whether
> they're using VMEMMAP or not.  It only starts to become a problem for
> 1GB hugepages.
> 
> Since THPs are (currently) only allocated from the page allocator, it's
> never a problem for THPs, only hugetlbfs.  Correcting the places which
> can't see a 1GB page is just defense against copy-and-paste programming.
> 
> So I'll defer to Mike -- does this ever affect real systems and thus
> warrant a backport?  I know this doesn't affect UEK because we enable
> SPARSEMEM_VMEMMAP.

I guess it all depends on your definition of 'real' systems.  I am unaware
of any distros that disable SPARSEMEM_VMEMMAP, but I do not know or have
access to them all.

In arch specific Kconfig files, SPARSEMEM_VMEMMAP is enabled by default
(if sparsemem is enabled).  However, it is 'possible' to configure a kernel
with SPARSEMEM and without SPARSEMEM_VMEMMAP.

This issue came up almost a year ago in this thread:
https://lore.kernel.org/linux-mm/20210217184926.33567-1-mike.kravetz@oracle.com/

In practice, I do not recall ever seeing this outside of debug environments
specifically trying to hit the issue.
-- 
Mike Kravetz