lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 3 Nov 2017 11:02:45 -0700
From:   Andrew Morton <>
To:     "Yang Shi" <>
Cc:     Michal Hocko <>,,,,
        Joe Perches <>
Subject: Re: [PATCH] mm: use in_atomic() in print_vma_addr()

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 ;)

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:
: Signed-off-by: Yang Shi <>
: Acked-by: Michal Hocko <>
: Cc: Frederic Weisbecker <>
: Cc: Ingo Molnar <>

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