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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B35CCC43219 for ; Tue, 8 Nov 2022 02:48:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233143AbiKHCsY (ORCPT ); Mon, 7 Nov 2022 21:48:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233084AbiKHCsG (ORCPT ); Mon, 7 Nov 2022 21:48:06 -0500 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FF052EF28 for ; Mon, 7 Nov 2022 18:48:05 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id k5so12498353pjo.5 for ; Mon, 07 Nov 2022 18:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=cb+qNTf4zZw7M49/6HjMGiu6w5l1+cn6hrjaUdr0DHU=; b=3hhW4zT1sCYAOPA96ae3wbs82Byb/dVx1bVdVIfMX6vZCuBfxtEJQu9+4MfFDDLc6O 4/xG4ynRn8sMpO5Kho4YSJ7IhrrPYEDAF2Ccm/mY3H3wU+nD04ZPFKRa9VKJr5xU+hke qn0d/TwtZQ8GcT8eGv/ob/7xcGTQC+u/8OrqGaY6ZixXcqj13v1GMJ6leMG3qH1Us+I+ +eTJMMetsZv5/S0aHE1PJyzU+4bo3LsHV1KxPxbN+CSEidENJCNA5beDEJkP1jXxKLRo wPpkHa6m9oGoQcBCxkEW2K7asp5ctT+jKl0+rlyjVKj/WVOYgOmKKlCYcL4EWjxJ8R9y Fe+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cb+qNTf4zZw7M49/6HjMGiu6w5l1+cn6hrjaUdr0DHU=; b=ImRaQjzTVmBIpskuxo4bIHd6fhxUpuqu5hg+/twxtJD7fwJ4XsxKXsJuO7XuTPT42+ FEH0yjqRY4Ra0lTmfvMnZ57Zpg6iS6JCBiqqc6iV92OrSxO7ATFOhz/xY6IZC7kYVHdp sXoaBb4Sp3ESLHSQZxibCIA/DoLFtvBpdCkP/Ktuc9tURDGqNHQDsPKXcLgP5UfGrPpb PuOpNksLeXyLjVU+XBTcLqJCm/3U9+ny+//wFVAXHn2ELx7y/2pQpKdIoKusA3duutEk ZhiuOFGRtu3dLtlxWTkZx/sRxgEdJji0A/b7vG5c+4x9Qe40cTciHChsWN8bjJKSXTd5 kh1Q== X-Gm-Message-State: ACrzQf2dqK6FOW/q25zeY5I1S3DG+O/3K4Tli7RxhlNwBhzX3iT+hEm3 n68b+DBNAAX6IKXZSxuEi17MMg== X-Google-Smtp-Source: AMsMyM7BbG3pWsplO2ijPGakSOF6da3rpSXH6xgjk9w0ZQAiCfSjkEhQDkKZzWadc75CnndQoDi2Dw== X-Received: by 2002:a17:903:284:b0:186:bb2c:b041 with SMTP id j4-20020a170903028400b00186bb2cb041mr53044475plr.36.1667875684569; Mon, 07 Nov 2022 18:48:04 -0800 (PST) Received: from [10.255.93.192] ([139.177.225.251]) by smtp.gmail.com with ESMTPSA id v6-20020aa799c6000000b0056ee49d6e95sm3837717pfi.86.2022.11.07.18.48.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Nov 2022 18:48:04 -0800 (PST) Message-ID: <0fd0c72d-badc-ad75-f0fe-91bc148820f2@bytedance.com> Date: Tue, 8 Nov 2022 10:47:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH] mm: fix unexpected changes to {failslab|fail_page_alloc}.attr Content-Language: en-US To: Jason Gunthorpe Cc: dvyukov@google.com, willy@infradead.org, akinobu.mita@gmail.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, stable@vger.kernel.org References: <20221107033109.59709-1-zhengqi.arch@bytedance.com> <4736d199-7e70-6bc3-30e6-0f644c81a10c@bytedance.com> From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/11/8 00:26, Jason Gunthorpe wrote: > On Mon, Nov 07, 2022 at 11:05:42PM +0800, Qi Zheng wrote: >> >> >> On 2022/11/7 20:42, Jason Gunthorpe wrote: >>> On Mon, Nov 07, 2022 at 11:31:09AM +0800, Qi Zheng wrote: >>> >>>> @@ -31,9 +33,9 @@ bool __should_failslab(struct kmem_cache *s, gfp_t gfpflags) >>>> return false; >>>> if (gfpflags & __GFP_NOWARN) >>>> - failslab.attr.no_warn = true; >>>> + flags |= FAULT_NOWARN; >>> >>> You should add a comment here about why this is required, to avoid >>> deadlocking printk >> >> I think this comment should be placed where __GFP_NOWARN is specified >> instead of here. What do you think? :) > > NOWARN is clear what it does, it is this specifically that is very > subtle about avoiding deadlock aginst allocations triggered by > printk/etc code. Oh, maybe I understand your concern. Some people may think that this is just a print of fault injection information, not a warning. I'll add a comment explaining why in some cases there must be no printing. Thanks, Qi > > Jason -- Thanks, Qi