Received: by 10.223.164.221 with SMTP id h29csp110425wrb; Fri, 3 Nov 2017 11:17:52 -0700 (PDT) X-Google-Smtp-Source: ABhQp+S4NWrs1huFoswQpmuMWlh9fYAX9lTf+WB9MKCI+4O88JwbOMoTCa8QUcHnyjI+01Blm3o9 X-Received: by 10.159.234.147 with SMTP id d19mr7530744plr.280.1509733072289; Fri, 03 Nov 2017 11:17:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509733072; cv=none; d=google.com; s=arc-20160816; b=anJXgUp0VuYfYRFopoc1S3WlMxpxu8AGVpitYqXKo8Tk5DodRqBZALaKgRcTg3ibzx C71y5UwXlrItnWGLkEGMX/5mF0X6YrbFB0U0VUsDt1gFNn5CiXVpMspilR5FZ7PzEyj0 lfngvjV981LQBELOSNhG22J9wA48DZCzvbpaIh8V8UApBMdUi4KFF3kSGGJCNz5fwmxr BJqX+7l30gAPGFLpzZqPQq5O5fc2JtlqUXj7C0k6O5K3Yf+LY4HwBRS+QJUvGNjnTZDX /fgCJiMVBtVKRgi3IM6jatnJUNOkscS65J4Wg3fLQMXMtQY4xb0Le0C1rg+KZvEt5GGv OIKw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=P238xZZEJqre9esYlUeOZ1X4TGxig4wQSw0QorkccmA=; b=gC07eAyXs6/sKbaEMqRddZD2HQP671+ceIX/7A8y57ak5VSrQmg5/ZUDar7YHUasRA 5qqPxUk/x6a3M9hijGPfec09LbFHW5ayFpqXKNLMm7+uYuqK+4eImEEawLMnPbGaU2bc PDWFntGxTQlsarV99HkYCLY6X2jmNKFTlaZsJuroz3Tq/wC23obDR4mroFS+zR2Mbl7b eby5drO+8nQL+X7f0wktb9HHq+kKgKo0VSjK1/mHz4k3O/aAj2zzcSYfyFXnB0hVrxhP /ChPpHXNiYs2dUNZx5FmhUJwulod/Jw58c0k0lJIJ7rGcXpNpVJnh8coyOkHiebb43TG 9+qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alibaba-inc.com header.s=default header.b=TC05PxKd; 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=alibaba-inc.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b184si6463556pgc.627.2017.11.03.11.17.39; Fri, 03 Nov 2017 11:17:52 -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=@alibaba-inc.com header.s=default header.b=TC05PxKd; 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=alibaba-inc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756243AbdKCSRC (ORCPT + 92 others); Fri, 3 Nov 2017 14:17:02 -0400 Received: from out0-217.mail.aliyun.com ([140.205.0.217]:36623 "EHLO out0-217.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751451AbdKCSRB (ORCPT ); Fri, 3 Nov 2017 14:17:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1509733016; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; bh=P238xZZEJqre9esYlUeOZ1X4TGxig4wQSw0QorkccmA=; b=TC05PxKdHW3zzhqG8nhxqcFPgmBYjC2mrPgise2vDZv616Rf0z/gSAFeXBT1hV007Q039/wO8+idpSSb18JIm4nVCLkNAFokxb90K5T/MpV9rVfMh2eWbtK8TXU9lOnjXjVA1JpCvbgiAOheTcYocZiPEGZ56drxINEhIMgDIFY= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R441e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03312;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---.9JX-ayR_1509733008; Received: from US-143344MP.local(mailfrom:yang.s@alibaba-inc.com ip:121.0.29.200) by smtp.aliyun-inc.com(127.0.0.1); Sat, 04 Nov 2017 02:16:51 +0800 Subject: Re: [PATCH] mm: use in_atomic() in print_vma_addr() To: Andrew Morton Cc: Michal Hocko , mingo@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joe Perches References: <1509572313-102989-1-git-send-email-yang.s@alibaba-inc.com> <20171102075744.whhxjmqbdkfaxghd@dhcp22.suse.cz> <20171103110245.7049460a05cc18c7e8a9feb2@linux-foundation.org> From: "Yang Shi" Message-ID: <39320f9c-95fd-9cf6-6bd9-e31655168d43@alibaba-inc.com> Date: Sat, 04 Nov 2017 02:16:45 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171103110245.7049460a05cc18c7e8a9feb2@linux-foundation.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/3/17 11:02 AM, Andrew Morton wrote: > On Fri, 03 Nov 2017 01:44:44 +0800 "Yang Shi" wrote: > >> I may not articulate it in the commit log > > You should have done so ;) Yes, definitely. I could done it much better. > > Here's the changelog I ended up with: > > : From: "Yang Shi" > : Subject: mm: use in_atomic() in print_vma_addr() > : > : 3e51f3c4004c9b ("sched/preempt: Remove PREEMPT_ACTIVE unmasking off > : in_atomic()") uses in_atomic() just check the preempt count, so it is not > : necessary to use preempt_count() in print_vma_addr() any more. Replace > : preempt_count() to in_atomic() which is a generic API for checking atomic > : context. > : > : in_atomic() is the preferred API for checking atomic context instead of > : preempt_count() which should be used for retrieving the preemption count > : value. > : > : If we go through the kernel code, almost everywhere "in_atomic" is used > : for such use case already, except two places: > : > : - print_vma_addr() > : - debug_smp_processor_id() > : > : Both came from Ingo long time ago before 3e51f3c4004c9b01 ("sched/preempt: > : Remove PREEMPT_ACTIVE unmasking off in_atomic()"). But, after this commit > : was merged, use in_atomic() to follow the convention. > : > : Link: http://lkml.kernel.org/r/1509572313-102989-1-git-send-email-yang.s@alibaba-inc.com > : Signed-off-by: Yang Shi > : Acked-by: Michal Hocko > : Cc: Frederic Weisbecker > : Cc: Ingo Molnar Thanks a lot for reworking the commit log. > > > > Also, checkpatch says > > WARNING: use of in_atomic() is incorrect outside core kernel code > #43: FILE: mm/memory.c:4491: > + if (in_atomic()) > > I don't recall why we did that, but perhaps this should be revisited? I think the rule for in_atomic is obsolete in checkpatch.pl. A quick grep shows in_atomic() is used by arch, drivers, crypto, even though the comment in include/linux/preempt.h says in_atomic() should be not used by drivers. However, the message could be ignored with --ignore=IN_ATOMIC. But, it sounds better to fix the wrong rule and maybe even the comment in include/linux/preempt.h since it sounds confusing. Thanks, Yang > From 1583068977036411109@xxx Fri Nov 03 18:03:44 +0000 2017 X-GM-THRID: 1582901365152158645 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread