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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <534E5741.8090908@gmail.com>
Date:	Wed, 16 Apr 2014 18:11:13 +0800
From:	Chen Gang <gang.chen.5i5j@...il.com>
To:	Michal Hocko <mhocko@...e.cz>
CC:	管雪涛 <gxt@....edu.cn>,
	Guan Xuetao <gxt@...c.pku.edu.cn>, akpm@...ux-foundation.org,
	liuj97@...il.com, rientjes@...gle.com, dhowells@...hat.com,
	mgorman@...e.de, linux-kernel@...r.kernel.org, will.deacon@....com,
	linux@....linux.org.uk, Geert Uytterhoeven <geert@...ux-m68k.org>,
	arnd@...db.de
Subject: Re: [PATCH v3] arch:unicore32:mm: add devmem_is_allowed() to support
 STRICT_DEVMEM

On 04/16/2014 05:05 PM, Michal Hocko wrote:
> On Tue 15-04-14 09:21:30, Chen Gang wrote:
> [...]
>> diff --git a/arch/unicore32/include/asm/io.h b/arch/unicore32/include/asm/io.h
>> index 39decb6..ae327e4 100644
>> --- a/arch/unicore32/include/asm/io.h
>> +++ b/arch/unicore32/include/asm/io.h
> 
> There is already quite a mess where the function is defined. We have it
> in mmap.c, init.c, mem.c and s390 defines it in page.h. Is there any
> good reason to add yet another place and pull in additional header files
> dependencies?

It is short enough to be as static inline function. It also can bypass
choosing which ".c" file contents the implementation (arm{64} declare it
in "io.h").

So recommend devmem_is_allowed() in arm{64} are also "static inline".

Hmm... is it possible to move the static inline implementation from
"io.h" to "page.h", since all other archs declare or implement in
"page.h" related header file.


> Why not follow x86 here? Or even better git rid of the code duplication
> and provide generic implementation which different arches can reuse and
> extend? arm{64}, unicore32 seem to be identical. Powepc and x86 have an
> additional test to the core one used by the above arches. Only tile
> seems to be be doing something completely different.
> 

For me, need not put it in 'asm-generic':

 - 9/29 archs need it, so at present, it is not generic enough.

 - most of them are different, which hard to find generic one.

   - frv and m32r same, but different with others.

   - arm{64} and unicore32 same, but different with others.

   - powerpc, s390, tile, and x86 are different with each other.

If we are sure most new archs will support devmem_is_allowed(), and at
least, 40% are the same, we can continue to consider about whether put
it in 'asm-generic' or not.


Altogether, for me, let the related declaration/implementation in
"page.h" or related header file will be fine, at least present, it is
not need to put it in 'asm-generic'.


[...]

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
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