Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp63361ybr; Fri, 22 May 2020 00:45:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxf42WTYrSv6oUZ4f+KmTxdKEmjnHYHwZNCVP/uBn3QxHFvZcWVyTh4a/MWx31pDM09zvNu X-Received: by 2002:a17:906:f75b:: with SMTP id jp27mr7317138ejb.141.1590133527443; Fri, 22 May 2020 00:45:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590133527; cv=none; d=google.com; s=arc-20160816; b=W1ozni85hKKtNnU4Anoji/XweDNmY4hUBzfzgwVVInJCnp0AVQPMX7USIUM++4x+dR GfRncgCAA09npT933Y50+Uv4Tf4Nje5kgSCDZ0OgLVrLBiSCwmyfmn7JNNqcMOoINc0A 9yynwqUKSnXbSMzuNsD6e5JDp4KhVhqrRihCnLmv9U+MdT1GjiMf1Hmpbv/b4Jw5+i6D UnQkOPrOa0cGmZezRRfKuhrzjcSYEZp1glfwaCuqTvPXgMYCA/79y5wucrqH2khkkx40 UyIUnQzyPru6QGx1q8YfOhSSzMMtDkTGe4ZhafSsLG3UsPG3DAwYO+sFCUEASEBZd6d7 CFMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=WUcyDTncPHOQV9NB5AwXf3dwySxGIAYkF3ieljmqrCw=; b=wpgBeffwqypwiV+jQTqrMk99QmzObPgI4Z/2t0PZ2zUoKpK3Oa+COIyTogzDDrFF1M AA37//bEUUAXjI2OhXoeiQR1v70pXUzxZBdje7zD7KeWJ0ds1vya/O3X6a0YMt1b/HYy B3Uxg+gorTy4ZpqZTIwHYUzakpOsDHvt+UWWucu1artncbX4jxDsVIY/hK9Tx/tAqv8f IRomYgXROMJ4vnLRWk7sDXQgc6b+kG+/R70y5eJj3klHtpKVdcXZaP4kuaLLICbPbxHz XrI8MRHidXh1fDrCOlEKk0Urs4iYcdh5cwL+FuCqmB78JPceXSOc6DTLwrzQTImbj9Cs Oc8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TB0jg2+M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ai4si4696391ejc.704.2020.05.22.00.45.05; Fri, 22 May 2020 00:45:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TB0jg2+M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728809AbgEVHnD (ORCPT + 99 others); Fri, 22 May 2020 03:43:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727839AbgEVHnD (ORCPT ); Fri, 22 May 2020 03:43:03 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74B17C061A0E for ; Fri, 22 May 2020 00:43:03 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id a23so7653378qto.1 for ; Fri, 22 May 2020 00:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WUcyDTncPHOQV9NB5AwXf3dwySxGIAYkF3ieljmqrCw=; b=TB0jg2+M0AS+ysjH0wzuBKlUUn04A7Th9OEwSEL2adxl+HzF2GaVWdQRHLcakcSSqt Qm4WyJTb8Rxk92rzd3QgdT12nYccf6gxO3M3gkskpiFod4TmaLzkMIulzDcx3HgORF7S e9uczcG4iMIm7bahe028RMdUVUrQtTIcAU5d2sUdyOy0LDeZtrMz6Yh8mZjuLJKGjyyq PnULQBX6EPLWXkBVtde7AZqAZgIu+W9qQazAMK7tRcdFyCQOXnFyvTZbgA29dKd1xFEG YZvMj+TbJkSYaIUAGiPs4cSc07esM/1FxZq7F6Wx9/EwRL+FL+dRvWkgE8/CM0tzFHuU qwnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WUcyDTncPHOQV9NB5AwXf3dwySxGIAYkF3ieljmqrCw=; b=W4gTw/eOIbl5Eh5/LvY19R2/yLaOChpo9WV838wXO/+sn2dhqp2MCyfWiX7RxoxseV kp20QqtWSflfXsfaJDw2Vjw2C5zu9TOuXPMayL8aYy6Qdzz5oeIi5XSb07ugZbQGNFbS e8gKluJXtck55b0q4Nw6eufEdeQSwvYzkTpynQkK0VfQ6RAQMFgoPQUmPUz69Hix+RNO s/xNRA+y2rS8uEao6VPeR5NIE8nHRGLvDkkIhjgWmBabfW2QCklPnlXktIJkFeWkkRRk TKgBMegA3LpXyqw7LbSwLjir/hkK8qttakuQgmnSU4fRNIf67mjrw3tap8vapK00MLtP 5w4Q== X-Gm-Message-State: AOAM530okYt9AtaOsxL1+g11OjDn8cf2kg8VXGKWU1usD7jnLeifRWUG wuUXaLzPhRIyf4uBGm0ME/DOW5gBFyNS9D9oCeQ= X-Received: by 2002:aed:2252:: with SMTP id o18mr14941673qtc.35.1590133382653; Fri, 22 May 2020 00:43:02 -0700 (PDT) MIME-Version: 1.0 References: <1589764857-6800-1-git-send-email-iamjoonsoo.kim@lge.com> <1589764857-6800-7-git-send-email-iamjoonsoo.kim@lge.com> <027b9f05-4a24-e69c-eafa-dbf7cca3ac4e@oracle.com> In-Reply-To: <027b9f05-4a24-e69c-eafa-dbf7cca3ac4e@oracle.com> From: Joonsoo Kim Date: Fri, 22 May 2020 16:42:54 +0900 Message-ID: Subject: Re: [PATCH 06/11] mm/hugetlb: do not modify user provided gfp_mask To: Mike Kravetz Cc: Andrew Morton , Linux Memory Management List , LKML , kernel-team@lge.com, Vlastimil Babka , Christoph Hellwig , Roman Gushchin , Naoya Horiguchi , Michal Hocko , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2020=EB=85=84 5=EC=9B=94 22=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 7:19, M= ike Kravetz =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On 5/17/20 6:20 PM, js1304@gmail.com wrote: > > From: Joonsoo Kim > > > > It's not good practice to modify user input. Instead of using it to > > build correct gfp_mask for APIs, this patch introduces another gfp_mask > > field, __gfp_mask, for internal usage. > > Modifying the flags as is done in the existing code does not bother me > too much, but that is just my opinion. Adding __gfp_mask for modificatio= ns > is fine with me if others think it is a good thing. With the following patches, in some cases, ac->gfp_mask is set up once and used many times. If we modify ac->gfp_mask in place, there would be side-ef= fect. > Does dequeue_huge_page_vma() need to be modified so that it will set > ac.__gfp_mask before calling dequeue_huge_page_nodemask()? Good catch! Will change! Thanks.