All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yang Shi" <yang.s@alibaba-inc.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	mingo@redhat.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [PATCH] mm: use in_atomic() in print_vma_addr()
Date: Sat, 04 Nov 2017 02:16:45 +0800	[thread overview]
Message-ID: <39320f9c-95fd-9cf6-6bd9-e31655168d43@alibaba-inc.com> (raw)
In-Reply-To: <20171103110245.7049460a05cc18c7e8a9feb2@linux-foundation.org>



On 11/3/17 11:02 AM, Andrew Morton wrote:
> On Fri, 03 Nov 2017 01:44:44 +0800 "Yang Shi" <yang.s@alibaba-inc.com> 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" <yang.s@alibaba-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@alibaba-inc.com>
> : Acked-by: Michal Hocko <mhocko@suse.com>
> : Cc: Frederic Weisbecker <fweisbec@gmail.com>
> : Cc: Ingo Molnar <mingo@elte.hu>

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
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Yang Shi" <yang.s@alibaba-inc.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	mingo@redhat.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [PATCH] mm: use in_atomic() in print_vma_addr()
Date: Sat, 04 Nov 2017 02:16:45 +0800	[thread overview]
Message-ID: <39320f9c-95fd-9cf6-6bd9-e31655168d43@alibaba-inc.com> (raw)
In-Reply-To: <20171103110245.7049460a05cc18c7e8a9feb2@linux-foundation.org>



On 11/3/17 11:02 AM, Andrew Morton wrote:
> On Fri, 03 Nov 2017 01:44:44 +0800 "Yang Shi" <yang.s@alibaba-inc.com> 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" <yang.s@alibaba-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@alibaba-inc.com>
> : Acked-by: Michal Hocko <mhocko@suse.com>
> : Cc: Frederic Weisbecker <fweisbec@gmail.com>
> : Cc: Ingo Molnar <mingo@elte.hu>

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
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-11-03 18:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 21:38 [PATCH] mm: use in_atomic() in print_vma_addr() Yang Shi
2017-11-01 21:38 ` Yang Shi
2017-11-02  7:57 ` Michal Hocko
2017-11-02  7:57   ` Michal Hocko
2017-11-02 17:44   ` Yang Shi
2017-11-02 17:44     ` Yang Shi
2017-11-03  8:29     ` Michal Hocko
2017-11-03  8:29       ` Michal Hocko
2017-11-03 18:02     ` Andrew Morton
2017-11-03 18:02       ` Andrew Morton
2017-11-03 18:16       ` Yang Shi [this message]
2017-11-03 18:16         ` Yang Shi
2017-11-03 20:09       ` Bart Van Assche
2017-11-03 20:09         ` Bart Van Assche
2017-11-05  8:19         ` Michal Hocko
2017-11-05  8:19           ` Michal Hocko
2017-11-06 10:05           ` Peter Zijlstra
2017-11-06 10:05             ` Peter Zijlstra
2017-11-06 10:43             ` Michal Hocko
2017-11-06 10:43               ` Michal Hocko
2017-11-06 10:56               ` Michal Hocko
2017-11-06 10:56                 ` Michal Hocko
2017-11-06 12:00               ` Peter Zijlstra
2017-11-06 12:00                 ` Peter Zijlstra
2017-11-06 12:12                 ` Michal Hocko
2017-11-06 12:12                   ` Michal Hocko
2017-11-06 13:40                   ` [PATCH] mm: do not rely on preempt_count in print_vma_addr (was: Re: [PATCH] mm: use in_atomic() in print_vma_addr()) Michal Hocko
2017-11-06 13:40                     ` Michal Hocko
2017-11-06 14:19                     ` [PATCH] mm: do not rely on preempt_count in print_vma_addr Vlastimil Babka
2017-11-06 14:19                       ` Vlastimil Babka
2017-11-06 14:28                       ` Michal Hocko
2017-11-06 14:28                         ` Michal Hocko
2017-11-06 16:16                     ` Yang Shi
2017-11-06 16:16                       ` Yang Shi
2017-11-06 16:24                       ` Michal Hocko
2017-11-06 16:24                         ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39320f9c-95fd-9cf6-6bd9-e31655168d43@alibaba-inc.com \
    --to=yang.s@alibaba-inc.com \
    --cc=akpm@linux-foundation.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.