linux-stable.git/arch/x86/include/asm, branch v3.4

x86, kvm: KVM paravirt kernels don't check for CPUID being unavailable

2012-05-14T17:49:32+00:00

We set cpuid_level to -1 if there is no CPUID instruction (only
possible on i386).

Signed-off-by: Alan Cox 
Link: http://lkml.kernel.org/r/20120514174059.30236.1064.stgit@bluebook
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=12122
Cc: Avi Kivity 
Cc: Marcelo Tosatti 
Signed-off-by: H. Peter Anvin

vfs: make word-at-a-time accesses handle a non-existing page

2012-05-03T21:01:40+00:00

It turns out that there are more cases than CONFIG_DEBUG_PAGEALLOC that
can have holes in the kernel address space: it seems to happen easily
with Xen, and it looks like the AMD gart64 code will also punch holes
dynamically.

Actually hitting that case is still very unlikely, so just do the
access, and take an exception and fix it up for the very unlikely case
of it being a page-crosser with no next page.

And hey, this abstraction might even help other architectures that have
other issues with unaligned word accesses than the possible missing next
page.  IOW, this could do the byte order magic too.

Peter Anvin fixed a thinko in the shifting for the exception case.

Reported-and-tested-by: Jana Saout 
Cc:  Peter Anvin 
Signed-off-by: Linus Torvalds

x32, siginfo: Provide proper overrides for x32 siginfo_t

2012-04-24T01:11:40+00:00

Provide the proper override macros for x32 siginfo_t.  The combination
of a special type here and an overall alignment constraint actually
ends up with all the types being properly aligned, but the hack is
needed to keep the substructures inside siginfo_t from adding padding.

Note: use __attribute__((aligned())) since __aligned() is not exported
to user space.

[ v2: fix stray semicolon ]

Reported-by: H.J. Lu 
Cc: Bruce J. Beare 
Cc: Arnd Bergmann 
Link: http://lkml.kernel.org/r/CAMe9rOqF6Kh6-NK7oP0Fpzkd4SBAWU%2BG53hwBbSD4iA2UzyxuA@mail.gmail.com
Signed-off-by: H. Peter Anvin

x32: Check ILP32 instead of LP64 for x32

2012-04-23T21:51:14+00:00

Check __LP64__ isn't a reliable way to tell if we are compiling for x32
since __LP64__ isnn't specified by x86-64 psABI.  Not all x86-64
compilers define __LP64__, which was added to GCC 3.3. The updated x32
psABI:

https://sites.google.com/site/x32abi/documents

definse _ILP32 and __ILP32__ for x32.  GCC trunk and 4.7 branch have
been updated to define _ILP32 and __ILP32__ for x32.  This patch
replaces __LP64__ check with __ILP32__.

Signed-off-by: H.J. Lu 
Signed-off-by: H. Peter Anvin

x86/platform: Remove incorrect error message in x86_default_fixup_cpu_id()

2012-04-16T18:43:43+00:00

It's only called from amd.c:srat_detect_node(). The introduced
condition for calling the fixup code is true for all AMD
multi-node processors, e.g. Magny-Cours and Interlagos. There we
have 2 NUMA nodes on one socket. Thus there are cores having
different numa-node-id but with equal phys_proc_id.

There is no point to print error messages in such a situation.

The confusing/misleading error message was introduced with
commit 64be4c1c2428e148de6081af235e2418e6a66dda ("x86: Add
x86_init platform override to fix up NUMA core numbering").

Remove the default fixup function (especially the error message)
and replace it by a NULL pointer check, move the
Numascale-specific condition for calling the fixup into the
fixup-function itself and slightly adapt the comment.

Signed-off-by: Andreas Herrmann 
Acked-by: Borislav Petkov 
Cc: 
Cc: 
Cc: 
Cc: 
Link: http://lkml.kernel.org/r/20120402160648.GR27684@alberich.amd.com
Signed-off-by: Ingo Molnar

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-04-12T22:06:07+00:00

Pull x86 fixes from Thomas Gleixner.

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86: Use correct byte-sized register constraint in __add()
  x86: Use correct byte-sized register constraint in __xchg_op()
  x86: vsyscall: Use NULL instead 0 for a pointer argument

x86: merge 32/64-bit versions of 'strncpy_from_user()' and speed it up

2012-04-11T16:41:28+00:00

This merges the 32- and 64-bit versions of the x86 strncpy_from_user()
by just rewriting it in C rather than the ancient inline asm versions
that used lodsb/stosb and had been duplicated for (trivial) differences
between the 32-bit and 64-bit versions.

While doing that, it also speeds them up by doing the accesses a word at
a time.  Finally, the new routines also properly handle the case of
hitting the end of the address space, which we have never done correctly
before (fs/namei.c has a hack around it for that reason).

Despite all these improvements, it actually removes more lines than it
adds, due to the de-duplication.  Also, we no longer export (or define)
the legacy __strncpy_from_user() function (that was defined to not do
the user permission checks), since it's not actually used anywhere, and
the user address space checks are built in to the new code.

Other architecture maintainers have been notified that the old hack in
fs/namei.c will be going away in the 3.5 merge window, in case they
copied the x86 approach of being a bit cavalier about the end of the
address space.

Cc: linux-arch@vger.kernel.org
Cc: Ingo Molnar 
Cc: Peter Anvin" 
Signed-off-by: Linus Torvalds

Make the "word-at-a-time" helper functions more commonly usable

2012-04-06T20:54:56+00:00

I have a new optimized x86 "strncpy_from_user()" that will use these
same helper functions for all the same reasons the name lookup code uses
them.  This is preparation for that.

This moves them into an architecture-specific header file.  It's
architecture-specific for two reasons:

 - some of the functions are likely to want architecture-specific
   implementations.  Even if the current code happens to be "generic" in
   the sense that it should work on any little-endian machine, it's
   likely that the "multiply by a big constant and shift" implementation
   is less than optimal for an architecture that has a guaranteed fast
   bit count instruction, for example.

 - I expect that if architectures like sparc want to start playing
   around with this, we'll need to abstract out a few more details (in
   particular the actual unaligned accesses).  So we're likely to have
   more architecture-specific stuff if non-x86 architectures start using
   this.

   (and if it turns out that non-x86 architectures don't start using
   this, then having it in an architecture-specific header is still the
   right thing to do, of course)

Signed-off-by: Linus Torvalds

x86: Use correct byte-sized register constraint in __add()

2012-04-06T16:40:07+00:00

Similar to:

 2ca052a x86: Use correct byte-sized register constraint in __xchg_op()

... the __add() macro also needs to use a "q" constraint in the
byte-sized case, lest we try to generate an illegal register.

Link: http://lkml.kernel.org/r/4F7A3315.501@goop.org
Signed-off-by: H. Peter Anvin 
Cc: Jeremy Fitzhardinge 
Cc: Leigh Scott 
Cc: Thomas Reitmayr 
Cc:  v3.3

x86: Use correct byte-sized register constraint in __xchg_op()

2012-04-06T16:39:39+00:00

x86-64 can access the low half of any register, but i386 can only do
it with a subset of registers.  'r' causes compilation failures on i386,
but 'q' expresses the constraint properly.

Signed-off-by: Jeremy Fitzhardinge 
Link: http://lkml.kernel.org/r/4F7A3315.501@goop.org
Reported-by: Leigh Scott 
Tested-by: Thomas Reitmayr 
Signed-off-by: H. Peter Anvin 
Cc:  v3.3