[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAmzW4McRv5c4gVi7Ltn72jq7Kcmu8OSKLmcw-3iVKtb_PXejQ@mail.gmail.com>
Date: Thu, 1 Nov 2012 00:01:50 +0900
From: JoonSoo Kim <js1304@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/5] mm, highmem: remove useless pool_lock
Hello, Andrew.
2012/10/31 Andrew Morton <akpm@...ux-foundation.org>:
> On Mon, 29 Oct 2012 04:12:53 +0900
> Joonsoo Kim <js1304@...il.com> wrote:
>
>> The pool_lock protects the page_address_pool from concurrent access.
>> But, access to the page_address_pool is already protected by kmap_lock.
>> So remove it.
>
> Well, there's a set_page_address() call in mm/page_alloc.c which
> doesn't have lock_kmap(). it doesn't *need* lock_kmap() because it's
> init-time code and we're running single-threaded there. I hope!
>
> But this exception should be double-checked and mentioned in the
> changelog, please. And it's a reason why we can't add
> assert_spin_locked(&kmap_lock) to set_page_address(), which is
> unfortunate.
set_page_address() in mm/page_alloc.c is invoked only when
WANT_PAGE_VIRTUAL is defined.
And in this case, set_page_address()'s definition is not in highmem.c,
but in include/linux/mm.h.
So, we don't need to worry about set_page_address() call in mm/page_alloc.c
> The irq-disabling in this code is odd. If ARCH_NEEDS_KMAP_HIGH_GET=n,
> we didn't need irq-safe locking in set_page_address(). I guess we'll
> need to retain it in page_address() - I expect some callers have IRQs
> disabled.
As Minchan described, if we don't disable irq when we take a lock for pas->lock,
it would be deadlock with page_address().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists