<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/mips/include/uapi, branch dev-4.7</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.7</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2016-05-13T12:02:21+00:00</updated>
<entry>
<title>MIPS: inst: Declare fsel_op for sel.fmt instruction</title>
<updated>2016-05-13T12:02:21+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2016-04-21T13:04:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b6d5c4eda7a771e72b3640500e026d72c4f64419'/>
<id>urn:sha1:b6d5c4eda7a771e72b3640500e026d72c4f64419</id>
<content type='text'>
Declare the opcode for the MIPSr6 sel.fmt instruction, as fsel_op in
order to match other FP op names.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: Maciej W. Rozycki &lt;macro@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;Leonid.Yegoshin@imgtec.com&gt;
Cc: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13152/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Loongson-3: Fast TLB refill handler</title>
<updated>2016-05-13T12:02:15+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2016-03-03T01:45:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=380cd582c08831217ae693c86411902e6300ba6b'/>
<id>urn:sha1:380cd582c08831217ae693c86411902e6300ba6b</id>
<content type='text'>
Loongson-3A R2 has pwbase/pwfield/pwsize/pwctl registers in CP0 (this
is very similar to HTW) and lwdir/lwpte/lddir/ldpte instructions which
can be used for fast TLB refill.

[ralf@linux-mips.org: Resolve conflict.]

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Cc: Steven J . Hill &lt;sjhill@realitydiluted.com&gt;
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12754/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Fix uapi include in exported asm/siginfo.h</title>
<updated>2016-05-13T12:02:11+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2016-02-08T18:43:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=987e5b834467c9251ca584febda65ef8f66351a9'/>
<id>urn:sha1:987e5b834467c9251ca584febda65ef8f66351a9</id>
<content type='text'>
Since commit 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime"),
MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h
directly before defining MIPS' struct siginfo, in order to get the
necessary definitions needed for the siginfo struct without the generic
copy_siginfo() hitting compiler errors due to struct siginfo not yet
being defined.

Now that the generic copy_siginfo() is moved out to linux/signal.h we
can safely include asm-generic/siginfo.h before defining the MIPS
specific struct siginfo, which avoids the uapi/ include as well as
breakage due to generic copy_siginfo() being defined before struct
siginfo.

Reported-by: Christopher Ferris &lt;cferris@google.com&gt;
Fixes: 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Petr Malat &lt;oss@malat.biz&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 4.0-
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Fix siginfo.h to use strict posix types</title>
<updated>2016-05-09T10:00:00+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2016-02-08T18:43:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5daebc477da4dfeb31ae193d83084def58fd2697'/>
<id>urn:sha1:5daebc477da4dfeb31ae193d83084def58fd2697</id>
<content type='text'>
Commit 85efde6f4e0d ("make exported headers use strict posix types")
changed the asm-generic siginfo.h to use the __kernel_* types, and
commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal
types accessible only to the kernel, but the MIPS implementation hasn't
been updated to match.

Switch to proper types now so that the exported asm/siginfo.h won't
produce quite so many compiler errors when included alone by a user
program.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Christopher Ferris &lt;cferris@google.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 2.6.30-
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12477/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Wire up preadv2 and pwrite2 syscalls.</title>
<updated>2016-04-03T07:41:34+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2016-04-03T07:41:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=62d8e64423adf5a044acbdffc6ca69c5b8067702'/>
<id>urn:sha1:62d8e64423adf5a044acbdffc6ca69c5b8067702</id>
<content type='text'>
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2016-03-21T02:08:56+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-03-21T02:08:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=643ad15d47410d37d43daf3ef1c8ac52c281efa5'/>
<id>urn:sha1:643ad15d47410d37d43daf3ef1c8ac52c281efa5</id>
<content type='text'>
Pull x86 protection key support from Ingo Molnar:
 "This tree adds support for a new memory protection hardware feature
  that is available in upcoming Intel CPUs: 'protection keys' (pkeys).

  There's a background article at LWN.net:

      https://lwn.net/Articles/643797/

  The gist is that protection keys allow the encoding of
  user-controllable permission masks in the pte.  So instead of having a
  fixed protection mask in the pte (which needs a system call to change
  and works on a per page basis), the user can map a (handful of)
  protection mask variants and can change the masks runtime relatively
  cheaply, without having to change every single page in the affected
  virtual memory range.

  This allows the dynamic switching of the protection bits of large
  amounts of virtual memory, via user-space instructions.  It also
  allows more precise control of MMU permission bits: for example the
  executable bit is separate from the read bit (see more about that
  below).

  This tree adds the MM infrastructure and low level x86 glue needed for
  that, plus it adds a high level API to make use of protection keys -
  if a user-space application calls:

        mmap(..., PROT_EXEC);

  or

        mprotect(ptr, sz, PROT_EXEC);

  (note PROT_EXEC-only, without PROT_READ/WRITE), the kernel will notice
  this special case, and will set a special protection key on this
  memory range.  It also sets the appropriate bits in the Protection
  Keys User Rights (PKRU) register so that the memory becomes unreadable
  and unwritable.

  So using protection keys the kernel is able to implement 'true'
  PROT_EXEC on x86 CPUs: without protection keys PROT_EXEC implies
  PROT_READ as well.  Unreadable executable mappings have security
  advantages: they cannot be read via information leaks to figure out
  ASLR details, nor can they be scanned for ROP gadgets - and they
  cannot be used by exploits for data purposes either.

  We know about no user-space code that relies on pure PROT_EXEC
  mappings today, but binary loaders could start making use of this new
  feature to map binaries and libraries in a more secure fashion.

  There is other pending pkeys work that offers more high level system
  call APIs to manage protection keys - but those are not part of this
  pull request.

  Right now there's a Kconfig that controls this feature
  (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) that is default enabled
  (like most x86 CPU feature enablement code that has no runtime
  overhead), but it's not user-configurable at the moment.  If there's
  any serious problem with this then we can make it configurable and/or
  flip the default"

* 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (38 commits)
  x86/mm/pkeys: Fix mismerge of protection keys CPUID bits
  mm/pkeys: Fix siginfo ABI breakage caused by new u64 field
  x86/mm/pkeys: Fix access_error() denial of writes to write-only VMA
  mm/core, x86/mm/pkeys: Add execute-only protection keys support
  x86/mm/pkeys: Create an x86 arch_calc_vm_prot_bits() for VMA flags
  x86/mm/pkeys: Allow kernel to modify user pkey rights register
  x86/fpu: Allow setting of XSAVE state
  x86/mm: Factor out LDT init from context init
  mm/core, x86/mm/pkeys: Add arch_validate_pkey()
  mm/core, arch, powerpc: Pass a protection key in to calc_vm_flag_bits()
  x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU
  x86/mm/pkeys: Add Kconfig prompt to existing config option
  x86/mm/pkeys: Dump pkey from VMA in /proc/pid/smaps
  x86/mm/pkeys: Dump PKRU with other kernel registers
  mm/core, x86/mm/pkeys: Differentiate instruction fetches
  x86/mm/pkeys: Optimize fault handling in access_error()
  mm/core: Do not enforce PKEY permissions on remote mm access
  um, pkeys: Add UML arch_*_access_permitted() methods
  mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys
  x86/mm/gup: Simplify get_user_pages() PTE bit handling
  ...
</content>
</entry>
<entry>
<title>mm/pkeys: Fix siginfo ABI breakage caused by new u64 field</title>
<updated>2016-03-05T14:00:06+00:00</updated>
<author>
<name>Dave Hansen</name>
<email>dave.hansen@linux.intel.com</email>
</author>
<published>2016-03-01T12:54:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=49cd53bf14aeb471c4a2682300dfc05ef2fd09f2'/>
<id>urn:sha1:49cd53bf14aeb471c4a2682300dfc05ef2fd09f2</id>
<content type='text'>
Stephen Rothwell reported this linux-next build failure:

	http://lkml.kernel.org/r/20160226164406.065a1ffc@canb.auug.org.au

... caused by the Memory Protection Keys patches from the tip tree triggering
a newly introduced build-time sanity check on an ARM build, because they changed
the ABI of siginfo in an unexpected way.

If u64 has a natural alignment of 8 bytes (which is the case on most mainstream
platforms, with the notable exception of x86-32), then the leadup to the
_sifields union matters:

typedef struct siginfo {
        int si_signo;
        int si_errno;
        int si_code;

        union {
	...
        } _sifields;
} __ARCH_SI_ATTRIBUTES siginfo_t;

Note how the first 3 fields give us 12 bytes, so _sifields is not 8
naturally bytes aligned.

Before the _pkey field addition the largest element of _sifields (on
32-bit platforms) was 32 bits. With the u64 added, the minimum alignment
requirement increased to 8 bytes on those (rare) 32-bit platforms. Thus
GCC padded the space after si_code with 4 extra bytes, and shifted all
_sifields offsets by 4 bytes - breaking the ABI of all of those
remaining fields.

On 64-bit platforms this problem was hidden due to _sifields already
having numerous fields with natural 8 bytes alignment (pointers).

To fix this, we replace the u64 with an '__u32'.  The __u32 does not
increase the minimum alignment requirement of the union, and it is
also large enough to store the 16-bit pkey we have today on x86.

Reported-by: Stehen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Acked-by: Stehen Rothwell &lt;sfr@canb.auug.org.au&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Dave Hansen &lt;dave@sr71.net&gt;
Cc: Helge Deller &lt;deller@gmx.de&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-next@vger.kernel.org
Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
Link: http://lkml.kernel.org/r/20160301125451.02C7426D@viggo.jf.intel.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: Facility to report route quality of connected sockets</title>
<updated>2016-02-26T03:01:22+00:00</updated>
<author>
<name>Tom Herbert</name>
<email>tom@herbertland.com</email>
</author>
<published>2016-02-24T18:02:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a87cb3e48ee86d29868d3f59cfb9ce1a8fa63314'/>
<id>urn:sha1:a87cb3e48ee86d29868d3f59cfb9ce1a8fa63314</id>
<content type='text'>
This patch add the SO_CNX_ADVICE socket option (setsockopt only). The
purpose is to allow an application to give feedback to the kernel about
the quality of the network path for a connected socket. The value
argument indicates the type of quality report. For this initial patch
the only supported advice is a value of 1 which indicates "bad path,
please reroute"-- the action taken by the kernel is to call
dst_negative_advice which will attempt to choose a different ECMP route,
reset the TX hash for flow label and UDP source port in encapsulation,
etc.

This facility should be useful for connected UDP sockets where only the
application can provide any feedback about path quality. It could also
be useful for TCP applications that have additional knowledge about the
path outside of the normal TCP control loop.

Signed-off-by: Tom Herbert &lt;tom@herbertland.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>signals, ia64, mips: Update arch-specific siginfos with pkeys field</title>
<updated>2016-02-18T08:32:42+00:00</updated>
<author>
<name>Dave Hansen</name>
<email>dave@sr71.net</email>
</author>
<published>2016-02-17T18:17:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b376cd0256f86db3078409dc51963b315c7843d8'/>
<id>urn:sha1:b376cd0256f86db3078409dc51963b315c7843d8</id>
<content type='text'>
ia64 and mips have separate definitions for siginfo from the
generic one.  Patch them to have the pkey fields.

Note that this is exactly what we did for MPX as well.

[ This fixes a compile error that Ingo was hitting with MIPS when the
  x86 pkeys patch set is applied. ]

Signed-off-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: Dave Hansen &lt;dave@sr71.net&gt;
Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Petr Malat &lt;oss@malat.biz&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: linux-ia64@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20160217181703.E99B6656@viggo.jf.intel.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Wire up copy_file_range syscall.</title>
<updated>2016-02-05T16:15:42+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2016-02-05T16:15:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e6c058f9b2700a720d3fad0f6caad1d030c533ee'/>
<id>urn:sha1:e6c058f9b2700a720d3fad0f6caad1d030c533ee</id>
<content type='text'>
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
</feed>
