From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E443AC02196 for ; Thu, 6 Feb 2025 06:18:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 790686B0098; Thu, 6 Feb 2025 01:18:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 740A46B0099; Thu, 6 Feb 2025 01:18:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 607DC6B009A; Thu, 6 Feb 2025 01:18:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 403816B0098 for ; Thu, 6 Feb 2025 01:18:40 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0259E120F36 for ; Thu, 6 Feb 2025 06:18:39 +0000 (UTC) X-FDA: 83088516000.23.AEEA150 Received: from mail-qv1-f97.google.com (mail-qv1-f97.google.com [209.85.219.97]) by imf15.hostedemail.com (Postfix) with ESMTP id DB95DA0008 for ; Thu, 6 Feb 2025 06:18:37 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=K3fukELE; dmarc=pass (policy=reject) header.from=purestorage.com; spf=pass (imf15.hostedemail.com: domain of ushankar@purestorage.com designates 209.85.219.97 as permitted sender) smtp.mailfrom=ushankar@purestorage.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738822718; a=rsa-sha256; cv=none; b=2HHL6UDTMyAWLRy16CK4j9Q93kToUI4zqq5uHb10WfcH5ivMq+58FtxlaPlC9pEYITRdHw l3cMO5fVbgkA9pukDE+MsxQP9SZRAyWhuTZLt+KcRnblohj6tcHubw+I+IYZvMga5/i/wk VJckpLrqCCnN/yghWuGGJ4SGxZJsLEc= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=K3fukELE; dmarc=pass (policy=reject) header.from=purestorage.com; spf=pass (imf15.hostedemail.com: domain of ushankar@purestorage.com designates 209.85.219.97 as permitted sender) smtp.mailfrom=ushankar@purestorage.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738822718; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=f0+3dldPw22A0PvsCVczWsrK8f2fzFb/x8xlwDXKflA=; b=ho7KqPIGERllsEPeO1mgQEsnFtTCau7OxRPVG+IOH8xHzGmEMQi2wYG+F4lT+8cDH94xKX PX89wVu6XZxa8wfvVT2RI78NNHaXaU3eW8Kc5AriHTqMYkZX98DZHdjDXNyWmMFc5ljt3y 6YRU69NtNmAXi0DHwreYk9z4XTYszKM= Received: by mail-qv1-f97.google.com with SMTP id 6a1803df08f44-6e4242b0b96so8871716d6.1 for ; Wed, 05 Feb 2025 22:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1738822717; x=1739427517; darn=kvack.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=f0+3dldPw22A0PvsCVczWsrK8f2fzFb/x8xlwDXKflA=; b=K3fukELE1ppc3ZnN00eA5AF82OGDP7LogQsUmnhb238Oke0/q50YaxqMJzK326vGaT 9Vhy9QOULSjyZ1TnP1o4wCyVWRrSaaFYIAMNPcM+egiNBiGKhG6fzyRyX3WMAEwfLwRY 2e4PNvG2WwZPexacK7ptGdsswtGg/REU7dzAXib0V/npX7UyrzM5KL0RIwK3F8heAnaF lumdH93r8lkpDwNX7QCwVwfGGpc0SQozv438P0q1XQWSO5Qzir8TTap72O6B5g6PERtZ 5SjOzwn0iq6/Vkd1aLh5Tjr85U1g9iKgwG4epahGiHzPA1/JMy2CETK1OgAOI+cTKRnv JyvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738822717; x=1739427517; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f0+3dldPw22A0PvsCVczWsrK8f2fzFb/x8xlwDXKflA=; b=iPbYYhJD32Uok42kN5neBcTsuCJKbThtboNY7p9iHflzq3suH12FJ6Tt+KnnWJRjPN RTlGkWPdS477Ycb8z0fzoiRlnLskEq4ESftivNImL4YBdYxVwCPr0sT5jQw9uusB7s58 TFU/RN6v4rz/Fm9g7euf4/LslQeUzQ04PErd+Vz8u1oYTNgs9jX+HPJJGsEokkXk+gkQ 3SfMSHdGS9UJTZkmz9FRVQAIFaSibi1jwX4aw5K/DcAHvwa5PIk58ptP8+0ukUf+R8PF PIi9UAChZJylsqzFHm2dmEAqjgUeZ13N8IS6pTzm6Si1XrSbuSVEb6R2uV6UtkUVgFAv 75sg== X-Gm-Message-State: AOJu0YzlDQE+TTLjAcHTUKiQUUq/WJqwM4UKuy0LBPciT3ABKjKbqZy2 Sb1/BmqW36v9bitV8MA1eq4cz4mrWUjtQsXTjOpyXXsubuYu2bJTMG6YHmV7mZWnWpL4N/6y7pg F8Esik3rXr5vaRISckyqjvMxlIz+UqlX7Uqtmue4PSLGl1XRsjuodHk3BTIyB3/qEK91jFXPWrD TSeSXzF179EXn3IR2U16ZKLRbUIp+QrO7TrzEVEPxZ2WNZP6oCT0HdBEqfA35t/K0E9vn4U+Ey2 tt5 X-Gm-Gg: ASbGncsUI3L12e8Jl/Na6B8LIAQokUy7rbAG+G42oDyx+phmNoAOcEPhP4FzrwB7OtG I7FoMrkZiGU6hJanJL6+DqO0538IA32xlEt4pFFx8amf9F7G77JQAlHKAWSXjUcRKhoFqmuUFfh MD6qgpFFpQoKpYVmP2Pxw/Vejwgi1k8AagjEobe169lXtNy5oDvPQjdfXM5zqJleM5MaWgbPrCT /gQZvWHKBkhKLNK1qm6urCMfxm21Tmkj8rh7GwEjVNGDGQDW7HxVYV4zhwOwaCttdlJQFnOillf unfNGr4l00PRbNzgMcX3TfD2Es5OSRfcP9to/xk= X-Google-Smtp-Source: AGHT+IFRN7RU3L+jpKzcHcOCkBBYHL8+CHvbi/IxovFCxETLDqBUYGx+bgqYrEdytFdBWh7tWZj6+VA0C68t X-Received: by 2002:a05:6214:1bc5:b0:6d9:3016:d101 with SMTP id 6a1803df08f44-6e42fc78d1emr71970546d6.41.1738822716888; Wed, 05 Feb 2025 22:18:36 -0800 (PST) Received: from c7-smtp-2023.dev.purestorage.com ([208.88.159.128]) by smtp-relay.gmail.com with ESMTPS id 6a1803df08f44-6e43ba40bf8sm427396d6.24.2025.02.05.22.18.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Feb 2025 22:18:36 -0800 (PST) X-Relaying-Domain: purestorage.com Received: from dev-ushankar.dev.purestorage.com (dev-ushankar.dev.purestorage.com [IPv6:2620:125:9007:640:7:70:36:0]) by c7-smtp-2023.dev.purestorage.com (Postfix) with ESMTP id 2E1C93401E5; Wed, 5 Feb 2025 23:18:35 -0700 (MST) Received: by dev-ushankar.dev.purestorage.com (Postfix, from userid 1557716368) id 22767E40EC4; Wed, 5 Feb 2025 23:18:35 -0700 (MST) Date: Wed, 5 Feb 2025 23:18:34 -0700 From: Uday Shankar To: Muchun Song , Andrew Morton , Joern Engel Cc: linux-mm@kvack.org Subject: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DB95DA0008 X-Stat-Signature: 95nno5jxnpwo1u5been3cswa1cemazam X-Rspam-User: X-HE-Tag: 1738822717-947535 X-HE-Meta: U2FsdGVkX19PqAfBM2lfb2bhTOPluYhvBrB0b+Q+TwF8J0gkTheWtSYgyGF0re2avvKdDvDK5Y5R95x1P7yzFShQKgM771+CI9dP3Trl64Yb3NSPrWdY9z/KsPaVx111lVZFjH8KOC6uFG9oWPbvh9yzXBvYNzQdR0GR79wUqvQkHvdh7F5CXJn3kUtdiucsI6tP2+kPbEr/L/x6OZNKaaUcQOUnm6abjcydA/aszjLcZzxIKJboboqnJ0DDs+zT0OIaKx6YgKSMiYV53sohxArpdGsI8fYAPeYpuFPehu+bbQ5P1epaGC5zxW+Ej1HaiiKFbzoWx8d03ZyWbWNJnRFH9wTI0MIxTCurZOaEtEin6dUcf4FQ73w71vIIu7SU27pPaWuWbD1kVe8YWc9a3COjszxCfxy0MdwqYr2Q9GrZFV/d4k4MIuioq67G9Bv94pIUbigOf4mJPZLoSNryQ8lhgoFWMpv7bYzeQAxJ1uIG2YLZAJ9KH/H8cVQqLeQSC2BzXYTz5xFBS+ttangYvnFS8EA8lH//koIJ0Hb69iVNcWm4biDzBVjEm7n+LHTQ1g1adxGrbgI9s4p4u45xoXLwCvnJd0v6SL7Vs50yCEyoA2oIOS281G4wA3/YJwlieA9bYK7SUA6f1z82v6yfJDcflCImMSTWTdSEfYhb7xYAgVJ9bcGqDN1sQp3wuU/KQOqvbYFgWevUbAeRVQFLr+L2U45ule1Uf+wRKsw/BXJhLR+RZuF+P5L/a0ekgQva9PDox1lhauk5mIvpso4iG2vjeNlCU3U0MnDkFRjI8FFYycCYSivNKZwej4lxpbG25+Yjh0DBUeMHXmCwBkSMEoSQLKJNdzkPk/UXnRmr81oGUVr9VfQBlvNeXSxbNjUVr1KmVj6LAfCBLhTLdEtQC8swUi7HEWCzvg6KuUKpjToYCWJ5oghyw7lgfUbpfz1ViSNYFCw2UcxcX5aF21r 9OVrLB9E kr67y0+4iDqndBtjpGebR1gPXcJFSQFHcA03hQtnZ/LsR0wJawqPRM5bGQgFA3ITEkge6S3soeLw6tSLoW4hPUQKLO7stvz/tj8xouKw74AxqZct6RcHmQk3I9+3I7grDIkdBzf4qKwTPmSxohUsjakZ6icpa8KWnCztbdxyLRKSL9BgSHipDuIYJm3eeT674lf+UHtvcK/sq05D1k4mJ9BtfvOCEYO79W3jhQ+nymNHgre+SbklugI8Vhg6Sa8iqpR1AJYKg5JJM36vea7phraSww9Lfn89YbbImRzEzblLz8rTNxJwqZsI6zXwyzdAnFzxmXAGGEQUzIcVpEG4gThh67mN/+XdAvnswYshQLTUWG3gH9mYHWDvKiYEV31TmKbhzfVdDr0wr7ri89e+j25JX9sLwhyGC7bDnMlbwmSHKtX7TWnHO/OlTcHO/dsA02T1muPnR20D8HtI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: I was debugging an issue with a malloc implementation when I noticed some unintuitive behavior that happens when someone attempts to overwrite part of a hugepage-backed PROT_NONE mapping with another mapping. I've isolated the issue and reproduced it with the following program: [root@localhost ~]# cat test.c #include #include #include #include #include #include #define MMAP_FLAGS_COMMON (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB) int main() { size_t len = 2ULL << 30; void *a = mmap( (void *)0x7c8000000000, len, PROT_NONE, MMAP_FLAGS_COMMON | MAP_FIXED_NOREPLACE | MAP_NORESERVE, -1, 0); printf("a=%p errno %d %m\n", a, errno); errno = 0; char buf[128]; sprintf(buf, "cp /proc/%d/smaps smaps1", getpid()); assert(system(buf) == 0); len = 4096; void *b = mmap( a, len, PROT_READ | PROT_WRITE, MMAP_FLAGS_COMMON | MAP_POPULATE | MAP_FIXED, -1, 0); printf("b=%p errno %d %m\n", b, errno); errno = 0; sprintf(buf, "cp /proc/%d/smaps smaps2", getpid()); assert(system(buf) == 0); return 0; } [root@localhost ~]# gcc -o test test.c && ./test a=0x7c8000000000 errno 0 Success b=0xffffffffffffffff errno 12 Cannot allocate memory [root@localhost ~]# diff smaps1 smaps2 157,158c157,158 < 7c8000000000-7c8080000000 ---p 00000000 00:10 7332 /anon_hugepage (deleted) < Size: 2097152 kB --- > 7c8000200000-7c8080000000 ---p 00200000 00:10 7332 /anon_hugepage (deleted) > Size: 2095104 kB First, we map a 2G PROT_NONE region using hugepages. This succeeds. Then we try to map a 4096-length PROT_READ | PROT_WRITE region at the beginning of the PROT_NONE region, still using hugepages. This fails, as expected, because 4096 is much smaller than the hugepage size configured on the system (this is x86 with a default hugepage size of 2M). The surprising thing is the difference in /proc/pid/smaps before and after the failed mmap. Even though the mmap failed, the value in /proc/pid/smaps changed, with a 2M-sized bite being taken out the front of the mapping. This feels unintuitive to me, as I'd expect a failed mmap to have no effect on the virtual memory mappings of the calling process whatsoever. I initially saw this on an ancient redhat kernel, but I was able to reproduce it on 6.13 as well. So I assume this behavior still exists and has been around forever.