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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110418123422.9341.A69D9226@jp.fujitsu.com>
Date:	Mon, 18 Apr 2011 12:34:02 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	kosaki.motohiro@...fujitsu.com, Hugh Dickins <hughd@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Russell King <linux@....linux.org.uk>
Subject: Re: mm: convert vma->vm_flags to 64bit

Hi

> On Sun, 2011-04-17 at 17:26 -0700, Hugh Dickins wrote:
> > I am surprised that
> > #define VM_EXEC         0x00000004ULL
> > does not cause trouble for arch/arm/kernel/asm-offsets.c,
> > but you tried cross-building it which I never did.
> 
> It would probably cause trouble for a big endian ARM no ? In that case
> it should offset the load by 4.

I think you are talking two thing, VM_EXEC and offsetof(vm_flags).
Therefore I'd explain my code reading result of two.

1) VM_EXEC

arch/arm/kernel/asm-offsets.c
----------------------------------------------------------------
  DEFINE(VM_EXEC,               VM_EXEC);

kbuild.h
----------------------------------------------------------------
#define DEFINE(sym, val) \
        asm volatile("\n->" #sym " %0 " #val : : "i" (val))

In this case, gcc asm() statement recognize C suffix and then
we don't see compile and/or link-time error.

2) vm_flags

arch/arm/kernel/asm-offsets.c
----------------------------------------------------------------
  DEFINE(VMA_VM_FLAGS,          offsetof(struct vm_area_struct, vm_flags));

OK, this is risky. we have to see all of users of this.


arch/arm/mm/proc-macros.S
----------------------------------------------------------------
/*
 * vma_vm_flags - get vma->vm_flags
 */
        .macro  vma_vm_flags, rd, rn
        ldr     \rd, [\rn, #VMA_VM_FLAGS]
        .endm


VMA_VM_FLAGS is only used this macro. then, we only need to see
vma_vm_flags assembler macro.

Next, 

% grep ENDIAN arch/arm/configs/*
arch/arm/configs/ixp2000_defconfig:CONFIG_CPU_BIG_ENDIAN=y
arch/arm/configs/ixp23xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y
arch/arm/configs/ixp4xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y

We only need to care the three subarch.

-----------------------------------------------------------
config ARCH_IXP23XX
        bool "IXP23XX-based"
        depends on MMU
        select CPU_XSC3
        select PCI
        select ARCH_USES_GETTIMEOFFSET
        help
          Support for Intel's IXP23xx (XScale) family of processors.

config ARCH_IXP2000
        bool "IXP2400/2800-based"
        depends on MMU
        select CPU_XSCALE
        select PCI
        select ARCH_USES_GETTIMEOFFSET
        help
          Support for Intel's IXP2400/2800 (XScale) family of processors.

config ARCH_IXP4XX
        bool "IXP4xx-based"
        depends on MMU
        select CPU_XSCALE
        select GENERIC_GPIO
        select GENERIC_CLOCKEVENTS
        select HAVE_SCHED_CLOCK
        select MIGHT_HAVE_PCI
        select DMABOUNCE if PCI
        help
          Support for Intel's IXP4XX (XScale) family of processors.
-----------------------------------------------------------

and they are CONFIG_CPU_XSCALE or CONFIG_CPU_XSC3.

arch/arm/mm/Makefile
-----------------------------------------------------------
obj-$(CONFIG_CPU_XSCALE)        += proc-xscale.o
obj-$(CONFIG_CPU_XSC3)          += proc-xsc3.o

grep -c  vma_vm_flags arch/arm/mm/proc-{xscale,xsc3}.S
arch/arm/mm/proc-xscale.S:0
arch/arm/mm/proc-xsc3.S:0


Then, current big endian user aren't harm from this change.

Of course, I might take mistake. I'm not arm expert. please correct
me if I'm misunderstand.



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

Powered by Openwall GNU/*/Linux Powered by OpenVZ