Received: by 10.213.65.68 with SMTP id h4csp1380459imn; Wed, 21 Mar 2018 09:16:05 -0700 (PDT) X-Google-Smtp-Source: AG47ELu9ceaJnd+Jcz7j4SaDgPgrg+q5Sh9fRL4GzhHzqywt5qaWXBlABMAsy9p1G2ihNT/FjXb6 X-Received: by 2002:a17:902:6e8c:: with SMTP id v12-v6mr21114778plk.24.1521648965762; Wed, 21 Mar 2018 09:16:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521648965; cv=none; d=google.com; s=arc-20160816; b=YhyJjXkj86FigX6aebJGHfo/r17ZnXlwc26C2IQgiJRpna03Zcl58K3rA+J0PSaanV 0N0tqxJiQLE2/LRHqPJYnSIZ0VRiJmVZZKNO3vekrp5+hjkVKmt+0Pfx5bOR/3IuNqsj O/lsjE3R5vAEo2SJeAeByeUZdgoWIEP+4jZVcom07nbT5KmuYmLcDkz9FK79RgNwInww zHom9jCEIG/WT2WRum30QaYt9MXAHh+bX8qXHV0RTcXCF2W/rL4g92bkmKAHSGtElVNI RMvNd/aVilJmJE09hn7p1T/MKiQ7gGxq4nQwEBSJ/yGGNIznxbfQ36nrI9Iu3gtj+8xt lNMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=YyHFmH8NLLpx4oecmnng8mvI/WVX9oW1qbpdu1iBLUc=; b=mJdgczGZP0j2PcSVqK3EY6d3s2OjxmqPGB4gq/w1HR9wA8bbesgtg0F9uaaL/nLFya A4F9Twxn63Ot/u/tWx9/M5XUmVuO6T4y06KRYtlInAyyqcUwJr3/Pny6dH/T1dVa+70u dGYjm2tBZ9RA3ZHN7nXvzYa/efg4c/w39YIsuUpjcuClmQERn4KuurYqztCzEu4irjHZ fM5ZeKyKC4YOC4MSnDPGy7BJcsXe+8gSOChRG4AsSgduGDYr9ZJlRHR5H6s82lBc2dMa MAjcptRAwZDWf64EKWM7XpDDBOpYHl0CvzElNb7c8NdFdOZhxMyk+Ls2Cy0zaFUiwXmL 1ZOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=aBvGNVM1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v1-v6si4203638plb.281.2018.03.21.09.15.50; Wed, 21 Mar 2018 09:16:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=aBvGNVM1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752783AbeCUQOR (ORCPT + 99 others); Wed, 21 Mar 2018 12:14:17 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:56390 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752028AbeCUQON (ORCPT ); Wed, 21 Mar 2018 12:14:13 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2LG97dG177396; Wed, 21 Mar 2018 16:13:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references; s=corp-2017-10-26; bh=YyHFmH8NLLpx4oecmnng8mvI/WVX9oW1qbpdu1iBLUc=; b=aBvGNVM1yEyYjhn8i1sWIzxdqBAU0bAzyFna+vKloQIpqDg6Jl59B6pJdWNxD9ur/MtJ CeLS8csYnYzYQVkRBtvjR/ttOc4daT654wEvuDxctm7rOchMui2unzIOdxBRV4rEo83H IW4dmtVUFf+KgjraQ+qoAWaDauI0LhyDiOJybhsE1mnGSxjsYOWqx5ZYLai7HbJFWspP /MBbr8g0IH118Usr01Sgildo+HUke2GWVQ+YBF52ydCMcJuxi3xWl4j0dD4xlLo6LHSE rQUjL003J/FVDIIdu0s7QHdQ4ATifflXrqq+WV1fsyaGHQkc+3l/Djrca98Y9524I2z/ hQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2gutnhg1bv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Mar 2018 16:13:53 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2LGDqfY017534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Mar 2018 16:13:52 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2LGDqXL024600; Wed, 21 Mar 2018 16:13:52 GMT Received: from monkey.oracle.com (/98.246.252.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Mar 2018 09:13:52 -0700 From: Mike Kravetz To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Laurent Dufour , Michal Hocko , Dan Williams , Andrea Arcangeli , Andrew Morton , Mike Kravetz , stable@vger.kernel.org Subject: [PATCH v2] shm: add split function to shm_vm_ops Date: Wed, 21 Mar 2018 09:13:14 -0700 Message-Id: <20180321161314.7711-1-mike.kravetz@oracle.com> X-Mailer: git-send-email 2.13.6 In-Reply-To: <0d24f817-303a-7b4d-4603-b2d14e4b391a@oracle.com> References: <0d24f817-303a-7b4d-4603-b2d14e4b391a@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8838 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If System V shmget/shmat operations are used to create a hugetlbfs backed mapping, it is possible to munmap part of the mapping and split the underlying vma such that it is not huge page aligned. This will untimately result in the following BUG: kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310! Oops: Exception in kernel mode, sig: 5 [#1] LE SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt 8<--8<--8<--8< snip 8<--8<--8<--8< CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E 4.15.0-10-generic #11-Ubuntu NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009 REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E (4.15.0-10-generic) MSR: 9000000000029033 CR: 24002222 XER: 20040000 CFAR: c00000000036ee44 SOFTE: 1 GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40 GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000 GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000 GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554 GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40 GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950 NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760 LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50 Call Trace: [c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable) [c000003fbcdcfb50] [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50 [c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190 [c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140 [c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0 [c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0 [c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80 [c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100 [c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30 [c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c Instruction dump: 552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010 7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468 ---[ end trace ee88f958a1c62605 ]--- This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct"). A split function was added to vm_operations_struct to determine if a mapping can be split. This was mostly for device-dax and hugetlbfs mappings which have specific alignment constraints. Mappings initiated via shmget/shmat have their original vm_ops overwritten with shm_vm_ops. shm_vm_ops functions will call back to the original vm_ops if needed. Add such a split function to shm_vm_ops. Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct") Signed-off-by: Mike Kravetz Reported by: Laurent Dufour Tested-by: Laurent Dufour Acked-by: Michal Hocko Cc: stable@vger.kernel.org --- Changes in v2 * Updated commit message * Cc stable ipc/shm.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/ipc/shm.c b/ipc/shm.c index 4643865e9171..93e0e3a4d009 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vmf) return sfd->vm_ops->fault(vmf); } +static int shm_split(struct vm_area_struct *vma, unsigned long addr) +{ + struct file *file = vma->vm_file; + struct shm_file_data *sfd = shm_file_data(file); + + if (sfd->vm_ops && sfd->vm_ops->split) + return sfd->vm_ops->split(vma, addr); + + return 0; +} + #ifdef CONFIG_NUMA static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new) { @@ -510,6 +521,7 @@ static const struct vm_operations_struct shm_vm_ops = { .open = shm_open, /* callback for a new vm-area open */ .close = shm_close, /* callback for when the vm-area is released */ .fault = shm_fault, + .split = shm_split, #if defined(CONFIG_NUMA) .set_policy = shm_set_policy, .get_policy = shm_get_policy, -- 2.13.6