Messages in this thread | | | Date | Wed, 27 Mar 2019 14:17:18 +0100 | From | Michal Hocko <> | Subject | Re: [PATCH v4] kmemleak: survive in a low-memory situation |
| |
On Wed 27-03-19 09:05:31, Qian Cai wrote: > On 3/27/19 7:44 AM, Michal Hocko wrote> What? Normal spin lock implementation > doesn't disable interrupts. So > > either I misunderstand what you are saying or you seem to be confused. > > the thing is that in_atomic relies on preempt_count to work properly and > > if you have CONFIG_PREEMPT_COUNT=n then you simply never know whether > > preemption is disabled so you do not know that a spin_lock is held. > > irqs_disabled on the other hand checks whether arch specific flag for > > IRQs handling is set (or cleared). So you would only catch irq safe spin > > locks with the above check. > > Exactly, because kmemleak_alloc() is only called in a few call sites, slab > allocation, neigh_hash_alloc(), alloc_page_ext(), sg_kmalloc(), > early_amd_iommu_init() and blk_mq_alloc_rqs(), my review does not yield any of > those holding irq unsafe spinlocks.
I do not understand. What about a regular kmalloc(GFP_NOWAIT) callers with a simple spinlock held?
-- Michal Hocko SUSE Labs
| |