linux-kernel - Re: [userns:userns-always-map-user-v45 80/99] fs/namespace.c:2290:1: error: unknown type name 'atomic64

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]

Date:	Mon, 13 Aug 2012 09:13:09 -0700
From:	"Eric W. Biederman" <ebiederm@...ssion.com>
To:	Fengguang Wu <fengguang.wu@...el.com>
CC:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	kernel-janitors@...r.kernel.org, Greg Ungerer <gerg@...inux.org>,
	linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [userns:userns-always-map-user-v45 80/99] fs/namespace.c:2290:1: error: unknown type name 'atomic64_t'

Fengguang Wu <fengguang.wu@...el.com> wrote:

>On Sun, Aug 12, 2012 at 11:56:45PM -0700, Eric W. Biederman wrote:
>> Fengguang Wu <fengguang.wu@...el.com> writes:
>> 
>> > Hi Geert,
>> >
>> > This is the build error I get, on Eric's userns tree.
>> >
>> > tree:  
>git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
>userns-always-map-user-v45
>> > head:   38a0b1b84f5f613ff4e01fffda27f87d4cb2b649
>> > commit: 5ea9fc30545b658380d4794340227fe821b83701 [80/99] vfs: Add
>setns support for the mount namespace
>> > config: m68k-m5475evb_defconfig (attached as .config)
>> >
>> > All related error/warning messages:
>> >
>> > fs/namespace.c:2290:1: error: unknown type name 'atomic64_t'
>> > fs/namespace.c:2290:1: error: implicit declaration of function
>'ATOMIC64_INIT' [-Werror=implicit-function-declaration]
>> > fs/namespace.c:2290:1: error: initializer element is not constant
>> > fs/namespace.c: In function 'alloc_mnt_ns':
>> > fs/namespace.c:2299:2: error: implicit declaration of function
>'atomic64_add_return' [-Werror=implicit-function-declaration]
>> > cc1: some warnings being treated as errors
>> 
>> Fengguang is m68k the only place you are seeing build failures?
>
>Yes.
>
>> Exactly how I get a 64bit counter in that code path is not terribly
>> important.  I picked an atomic64_t because it looked simple and
>cheap.
>
>Fair enough. As long as it's not in hot code path, it definitely helps
>to use simple solutions.
>
>> If this is limited to a couple of m68k sub-arches I will let you guys
>> finish fixing this up so people can depend on atomic64_t being
>> available.  Otherwise it probably makes sense to go to with a
>different
>> abstraction.
>
>I'd suggest to fix it in m68k and make atomic64_t generally available.

Fengguang in your testing on any architechtures is atomic64_t missing on anything except some m68k subarchtechtures?

Eric

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