Received: by 10.213.65.68 with SMTP id h4csp1633174imn; Thu, 15 Mar 2018 05:31:45 -0700 (PDT) X-Google-Smtp-Source: AG47ELvoOF4eZqlKllFbUxUG1F1Dqrs6ueYlZ9OZP6WKByhi2xAjBSCTOK2BKKh/JMDbjxV55NhI X-Received: by 2002:a17:902:8214:: with SMTP id x20-v6mr8070686pln.182.1521117105685; Thu, 15 Mar 2018 05:31:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521117105; cv=none; d=google.com; s=arc-20160816; b=g45mpSG8PRfOhjSOG9C1N3hyJS3WZHTJ4bAQlVZpiKaCGMXfqJUEh8E71qqif5hHNm PiV3yY/xohmLFvsf9bkd6vfYXSqzMXrpMDWWOnsTQUYdHWmeWQiLMTOndSKc95f+0g7B oCxhovYKs3op4e6E3jGuYv4bFoayukVw820f76B/NtYVtrO7IGNmFsl2sXP5r9nQBRNI 41hDJ3SmC7/GIvkRBnNDx+AwU/b9n7EmniIwzjr0b2jCT2AjD49nCws390V45sYTXFzh 7hQZNqey2Fq8yZhi2S0WXF4/6V6MsYVDxRqrtjOkPG6g2H5uwS0PMIh9r0e1pIuydNJ2 1E/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=LYjXhioVEcqlZ/uGUehrOvDYrYaO/Pb1KZVKlRp5www=; b=rd3+BAFpVTPd3lCs8KQqgXZ0b2c1UB/REXTuBmb6rkchEsvdeGD4gXGeMqGThEJu2f 5foqCpE/aJ7nRdZr6QcNkvH4znD0opb7StJaZjTQHl1HDvnZKzqujDZIJ9rYclZLK/0S 0z4BaXfDgIjQ37g+g5iS0Q7smu9E8fIHDOQ96uegCjsageButVPdNLo1Er9sAFS/21S4 MkVyhmhqwzASvVW0ZIgpla8HMn2q/aPN2g+iyB0ZSX3o1q2/r9iZ7/tJR5Lj5SL0B8XK 0VWaMri9cPNaMtNWIA9Om3VhOtgCSuzkjMRNmR9GGttrnC7Xx7kk1wYunM3VvbV1hqko 8fjg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j19-v6si3906420pll.34.2018.03.15.05.31.31; Thu, 15 Mar 2018 05:31:45 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751672AbeCOM3s (ORCPT + 99 others); Thu, 15 Mar 2018 08:29:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:37003 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556AbeCOM3r (ORCPT ); Thu, 15 Mar 2018 08:29:47 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1E5B8ABE0; Thu, 15 Mar 2018 12:29:46 +0000 (UTC) Date: Thu, 15 Mar 2018 13:29:44 +0100 From: Michal Hocko To: Zi Yan Cc: "Huang, Ying" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , Minchan Kim , Shaohua Li , jglisse@redhat.com, "Aneesh Kumar K.V" Subject: Re: [PATCH -mm] mm, madvise, THP: Use THP aligned address in madvise_free_huge_pmd() Message-ID: <20180315122944.GH23100@dhcp22.suse.cz> References: <20180315011840.27599-1-ying.huang@intel.com> <869F4AAA-5BBA-40D6-916F-6919E515D271@cs.rutgers.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <869F4AAA-5BBA-40D6-916F-6919E515D271@cs.rutgers.edu> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 14-03-18 21:39:54, Zi Yan wrote: > This cannot happen. > > Two address parameters are passed: addr and next. > If “addr” is not aligned and “next” is aligned or the end of madvise range, which might not be aligned, > either way next - addr < HPAGE_PMD_SIZE. > > This means the code in “if (next - addr != HPAGE_PMD_SIZE)”, which is above your second hunk, > will split the THP between “addr” and “next” and get out as long as “addr“ is not aligned. > Thus, the code in your second hunk should always get aligned “addr”. OK, so what would happen if the above doesn't hold anymore after some change up the call chain? Is it critical? If yes, do we want VM_BUG_ON to detect that? Or at least document the asumption? -- Michal Hocko SUSE Labs