Re: [PATCH] mm: use in_atomic() in print_vma_addr()

[Yang Shi]

On 11/2/17 12:57 AM, Michal Hocko wrote:
> On Thu 02-11-17 05:38:33, Yang Shi wrote:
> > commit 3e51f3c4004c9b01f66da03214a3e206f5ed627b
> > ("sched/preempt: Remove PREEMPT_ACTIVE unmasking off in_atomic()") makes
> > 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.
>
> But why? Is there some general work to get rid of the direct preempt_count
> usage outside of the generic API?

I may not articulate it in the commit log, I would say "in_atomic" is 
*preferred* API for checking atomic context instead of preempt_count() 
which should be used for retrieving the preemption count value.

I would say there is not such general elimination work undergoing right 
now, but 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 commit 
3e51f3c4004c9b01f66da03214a3e206f5ed627b ("sched/preempt: Remove 
PREEMPT_ACTIVE unmasking off in_atomic()"). But, after this commit was 
merged, I don't see why *not* use in_atomic() to follow the convention.

Thanks,
Yang

> > Signed-off-by: Yang Shi <yang.s@xxxxxxxxxxxxxxx>
> > ---
> >   mm/memory.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index a728bed..19b684e 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -4460,7 +4460,7 @@ void print_vma_addr(char *prefix, unsigned long ip)
> >   	 * Do not print if we are in atomic
> >   	 * contexts (in exception stacks, etc.):
> >   	 */
> > -	if (preempt_count())
> > +	if (in_atomic())
> >   		return;
> >   
> >   	down_read(&mm->mmap_sem);
> > --
> > 1.8.3.1