lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAAmzW4Ns_90oYH4gDduz=UZ6_krFnkm1ODPS8eitH26vc0u7zg@mail.gmail.com> Date: Wed, 12 Dec 2012 23:34:46 +0900 From: JoonSoo Kim <js1304@...il.com> To: Russell King <rmk+kernel@....linux.org.uk> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org, Joonsoo Kim <js1304@...il.com> Subject: Re: [PATCH v2 0/3] introduce static_vm for ARM-specific static mapped area 2012/12/7 JoonSoo Kim <js1304@...il.com>: > 2012/11/28 Joonsoo Kim <js1304@...il.com>: >> In current implementation, we used ARM-specific flag, that is, >> VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area. >> The purpose of static mapped area is to re-use static mapped area when >> entire physical address range of the ioremap request can be covered >> by this area. >> >> This implementation causes needless overhead for some cases. >> For example, assume that there is only one static mapped area and >> vmlist has 300 areas. Every time we call ioremap, we check 300 areas for >> deciding whether it is matched or not. Moreover, even if there is >> no static mapped area and vmlist has 300 areas, every time we call >> ioremap, we check 300 areas in now. >> >> If we construct a extra list for static mapped area, we can eliminate >> above mentioned overhead. >> With a extra list, if there is one static mapped area, >> we just check only one area and proceed next operation quickly. >> >> In fact, it is not a critical problem, because ioremap is not frequently >> used. But reducing overhead is better idea. >> >> Another reason for doing this work is for removing architecture dependency >> on vmalloc layer. I think that vmlist and vmlist_lock is internal data >> structure for vmalloc layer. Some codes for debugging and stat inevitably >> use vmlist and vmlist_lock. But it is preferable that they are used >> as least as possible in outside of vmalloc.c >> >> Changelog >> v1->v2: >> [2/3]: patch description is improved. >> Rebased on v3.7-rc7 >> >> Joonsoo Kim (3): >> ARM: vmregion: remove vmregion code entirely >> ARM: static_vm: introduce an infrastructure for static mapped area >> ARM: mm: use static_vm for managing static mapped areas >> >> arch/arm/include/asm/mach/static_vm.h | 51 ++++++++ >> arch/arm/mm/Makefile | 2 +- >> arch/arm/mm/ioremap.c | 69 ++++------- >> arch/arm/mm/mm.h | 10 -- >> arch/arm/mm/mmu.c | 55 +++++---- >> arch/arm/mm/static_vm.c | 97 ++++++++++++++++ >> arch/arm/mm/vmregion.c | 205 --------------------------------- >> arch/arm/mm/vmregion.h | 31 ----- >> 8 files changed, 208 insertions(+), 312 deletions(-) >> create mode 100644 arch/arm/include/asm/mach/static_vm.h >> create mode 100644 arch/arm/mm/static_vm.c >> delete mode 100644 arch/arm/mm/vmregion.c >> delete mode 100644 arch/arm/mm/vmregion.h >> >> -- >> 1.7.9.5 >> > > Hello, Russell. > > Could you review this patchset, please? > I send another patchset to mm community on top of this. > That one is related to this patchset, > so I want to get a review about this patchset :) > > Thanks. Hello. Is there anyone to review this patchset? Please let me know what I should do in order to take a review :) Thanks. -- 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