[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171103110245.7049460a05cc18c7e8a9feb2@linux-foundation.org>
Date: Fri, 3 Nov 2017 11:02:45 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Yang Shi" <yang.s@...baba-inc.com>
Cc: Michal Hocko <mhocko@...nel.org>, mingo@...hat.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Joe Perches <joe@...ches.com>
Subject: Re: [PATCH] mm: use in_atomic() in print_vma_addr()
On Fri, 03 Nov 2017 01:44:44 +0800 "Yang Shi" <yang.s@...baba-inc.com> wrote:
> I may not articulate it in the commit log
You should have done so ;)
Here's the changelog I ended up with:
: From: "Yang Shi" <yang.s@...baba-inc.com>
: 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 <yang.s@...baba-inc.com>
: Acked-by: Michal Hocko <mhocko@...e.com>
: Cc: Frederic Weisbecker <fweisbec@...il.com>
: Cc: Ingo Molnar <mingo@...e.hu>
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?
Powered by blists - more mailing lists