Received: by 10.223.185.116 with SMTP id b49csp5339377wrg; Wed, 7 Mar 2018 10:04:42 -0800 (PST) X-Google-Smtp-Source: AG47ELsxKAtRZaZLBBGhdVTmFA7QfmYkPx+9lPpJNYQ+6CAgMWsrCXuprr5dZzoSwhI45WKGsgWa X-Received: by 2002:a17:902:8541:: with SMTP id d1-v6mr21048018plo.54.1520445882034; Wed, 07 Mar 2018 10:04:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520445881; cv=none; d=google.com; s=arc-20160816; b=T3mwZ6LESISHyAVY1RG1iR0JnLw45TKMiN67r5/hi59WZM67rGXKLFVfmpkBuSObEa R+iuajLehKipktK7HU2PV+MgcoYOevhwW2nB1MAKD/ygFbycVCFZdAjCn2zlpi8HUAsb xNzx4gyGV9d4IqrwUJSngI+Z/mr4GGwtlfA5nwCp/Oug6cXtzK4zIDJYPwjVYUJR+n7B fyJvYz4scoVhX1zEznFomv/4jCnIfsImc3rt9dLB/qvcekrrOhtVTeNX6NQG1/ZRXaza nt8wunPUQUTo2vtX5XU+MDeOIFQfEMeblg7j467rrqgOpB7E0ZEOVVHU+D71PiVP7/r8 8K2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=RT7sVTkKsr6HUluZZSKBXtRpDvYudeghWhU3GaeJZr0=; b=EuLtwMRNKsg/PSS53t+XcZ7ku3lTWbFqOT2osSwVf1JgSEaZ9Ob2BF8Nx9LVsGMKxT QRfM/heTDoALyi+rkJlH125TTPye2t1+XkVK8yPuUfey4rddkqbO8ToztWOHfvO/xVHq 4n+Eu9xx2S6cj9Va/7qfk0zWwXDojNn7GKEQ3wCOXzbNqtK0fsTqQuhGRWuj5wM4mXUU 6dOja7do19WPDchmeZgFaSKmkuvfwRpDKyMa61ClulR3K8GpWajo/5H1+7A77QI7fUGa vG2ZQ2NU9ct8IoHfo2F1fyJynVxqR/kAsWXSj/n0qzUumIcn4mYiaT6jJi3b+t4+Rnx2 5XoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=dfiY6p8q; 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 d21si14261073pfk.328.2018.03.07.10.04.26; Wed, 07 Mar 2018 10:04:41 -0800 (PST) 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=dfiY6p8q; 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 S1754491AbeCGSBy (ORCPT + 99 others); Wed, 7 Mar 2018 13:01:54 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:54458 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751211AbeCGSBu (ORCPT ); Wed, 7 Mar 2018 13:01:50 -0500 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 w27I1had168490 for ; Wed, 7 Mar 2018 18:01:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : in-reply-to : references : from : date : message-id : subject : to : cc : content-type; s=corp-2017-10-26; bh=RT7sVTkKsr6HUluZZSKBXtRpDvYudeghWhU3GaeJZr0=; b=dfiY6p8qEDkR5yf4GDX5tHDhTdy6h1Euczuib4maaqenvzC7P9xRUl09rjT6e3h1o1yZ ziSYBZ8V3U9BwrZllYKM1Ea1HFJVcq0cjIvrkGyYhd4IWj5n40qK7CvbXUg66lUSQtuQ yHNSYtMYgBHnoH85vj5Pe0Iap9/T6lFIGsY/8cgQLowGunwQ+WwCysI4TxZbV33aoG4H 2Adk+FT1VkkNs/3DE+pPgGwNN/mgs+5+KRStbcodi5Hg5vXc+6GPPrbUbKZFvZqK8xid 24oyfgmR4qVf8PjHwlSyQtZMPtEjkZhTDLdzVK8R5xRxzP9x/FMrWZosyY0Mbk4GzrUb rA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2gjka28n69-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 07 Mar 2018 18:01:47 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w27I1YgD019927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 7 Mar 2018 18:01:34 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w27I1YSQ030783 for ; Wed, 7 Mar 2018 18:01:34 GMT Received: from mail-ot0-f171.google.com (/74.125.82.171) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Mar 2018 10:01:34 -0800 Received: by mail-ot0-f171.google.com with SMTP id t2so2889421otj.4 for ; Wed, 07 Mar 2018 10:01:33 -0800 (PST) X-Gm-Message-State: AElRT7G9Ji6JYOcfpR7rZKMaxzWwVprzyabPgw7YEssTPVYFzmsfH294 04CKRsTKO54BZK+13fn51GLWnzfF+jYxLQxOaA== X-Received: by 10.157.17.199 with SMTP id y7mr17152079oty.298.1520445693410; Wed, 07 Mar 2018 10:01:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.189.143 with HTTP; Wed, 7 Mar 2018 10:01:32 -0800 (PST) In-Reply-To: <33e3a3ff-0318-1a07-3c57-6be638046c87@suse.cz> References: <20180306224004.25150-1-pasha.tatashin@oracle.com> <33e3a3ff-0318-1a07-3c57-6be638046c87@suse.cz> From: Pavel Tatashin Date: Wed, 7 Mar 2018 13:01:32 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] mm: might_sleep warning To: Vlastimil Babka Cc: Steve Sistare , Daniel Jordan , m.mizuma@jp.fujitsu.com, Andrew Morton , Michal Hocko , Catalin Marinas , AKASHI Takahiro , Gioh Kim , Heiko Carstens , baiyaowei@cmss.chinamobile.com, Wei Yang , Paul Burton , Miles Chen , Mel Gorman , Johannes Weiner , Linux Kernel Mailing List , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8825 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=672 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803070205 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Hi, > > I've noticed that this function first disables the on-demand > initialization, and then runs the kthreads. Doesn't that leave a window > where allocations can fail? The chances are probably small, but I think > it would be better to avoid it completely, rare failures suck. > > Fixing that probably means rethinking the whole synchronization more > dramatically though :/ > > Vlastimil Hi Vlastimil, You are right, there is a window, it is short, and probably not possible to reproduce, as it happens before user threads are started, and after init calls done by smp_init() are finished. The only way it can happen, as far as I can see, is if some device fires an interrupt, and interrupt handler decides to allocate a large chunk of memory. The small allocations will succeed, as zone grow function growth more than strictly requested, and also there are zones without deferred pages. I will, however, think some more how to solve this problem to be future proof. Thank you, Pavel